[bitnami/postgresql] Enable override the archive_command value in postgresql containers

[Alvaro-Campesino]

Description of the change

This changes enables overriding the value of archive_command int the postgresql.conf when POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR is defined as an environment variable

Default value: /bin/true
Value when overrided: cp %p ${POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR}/%f

Benefits

Now it is possible to store incremental backups in an additional volume. Increasing restore capabilities.

Possible drawbacks

Applicable issues

• fixes [bitnami/postgresql*] Not posible to define archive_command for incremental backup  #51871

Additional information

[javsalgar]

Hi!

Thank you so much for the PR! Could you fix the DCO issue?

[Alvaro-Campesino]

@javsalgar DCO issue was fixed. PR is ready for review

[fmulero]

Thanks a lot Alvaro for your contribution.

As general comment, could you apply your changes in just one asset (postgresql for example)? That will help us to test your changes, don't worry about the other assets, once the PR is approved, we will apply the changes to all of them.

I also left some comments, could you take them a glance?

[fmulero]

Thanks a lot @Alvaro-Campesino

Please implement the changes in only one container, use postgresql container for example and remove changes in postgresql-repmgr and supabase-postgres . That will help us to review and test the changes. Please also fix the DCO, we can't not merge changes if they are not properly signed.

Also I left a little comment, please take it a look.

[Alvaro-Campesino]

Thanks @fmulero I will do as requested.

[fmulero]

Hi @Alvaro-Campesino

Thanks a lot for applying the changes only to postgresql container.

About my comment here I was wrong, if we use a separate volume to store the files, is not needed to create the folders and permissions. Sorry to point you in the wrong direction. Maybe adding a validation to ensure the directory exists would be a good idea in this case.

[fmulero]

If we use a separate volume to store the backups, this piece of code can be removed. Adding a validation in postgresql_validate could be a good idea

[Alvaro-Campesino]

I have been thinking about this and even if it is a separate volume , I think it is a good idea to use ensure_dir_exists as for example when using variables you can set the final path in a variable (which is my current setup), in order to have each pods WAL files in a separate folder.

    - name: POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR
      value: /backup/$(MY_POD_NAME)

What do you think?

[fmulero]

In that case everything will work smoothly and I agree that's a good idea, you can have a shared backup volume and each container will write in its own folder.

Now if you have this set up (POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR directly points to the volume):

version: '2'

services:
  postgresql:
    image: bitnami/postgresql:debug
    build: .
    ports:
      - '5432:5432'
    volumes:
      - 'postgresql_data:/bitnami/postgresql'
      - 'postgresql_backup:/backups/postgresql'
    environment:
      - 'ALLOW_EMPTY_PASSWORD=yes'
      - 'POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR=/backups/postgresql'

volumes:
  postgresql_data:
    driver: local
  postgresql_backup:
    driver: local

The container will fail because the code below will try to change volume permissions:

debian-11-postgresql-1  | postgresql 08:17:40.12 INFO  ==> Loading custom pre-init scripts...
debian-11-postgresql-1  | postgresql 08:17:40.13 INFO  ==> Initializing PostgreSQL database...
debian-11-postgresql-1  | chmod: changing permissions of '/backups/postgresql': Operation not permitted
debian-11-postgresql-1 exited with code 1

[fmulero]

Please include here some information about the use of a separate volume to store these backup files.

[fmulero]

Hi @Alvaro-Campesino, I left some comments

Please take them a glance and fix DCO.

Regards

[fmulero]

In that case everything will work smoothly and I agree that's a good idea, you can have a shared backup volume and each container will write in its own folder.

Now if you have this set up (POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR directly points to the volume):

version: '2'

services:
  postgresql:
    image: bitnami/postgresql:debug
    build: .
    ports:
      - '5432:5432'
    volumes:
      - 'postgresql_data:/bitnami/postgresql'
      - 'postgresql_backup:/backups/postgresql'
    environment:
      - 'ALLOW_EMPTY_PASSWORD=yes'
      - 'POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR=/backups/postgresql'

volumes:
  postgresql_data:
    driver: local
  postgresql_backup:
    driver: local

The container will fail because the code below will try to change volume permissions:

debian-11-postgresql-1  | postgresql 08:17:40.12 INFO  ==> Loading custom pre-init scripts...
debian-11-postgresql-1  | postgresql 08:17:40.13 INFO  ==> Initializing PostgreSQL database...
debian-11-postgresql-1  | chmod: changing permissions of '/backups/postgresql': Operation not permitted
debian-11-postgresql-1 exited with code 1

[fmulero]

Due to the issue mentioned above, something like this could be worth.

Suggested change

	is_empty_value "$POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR" || chmod u+rw "$POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR"
	is_empty_value "$POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR" || ! is_file_writable "$POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR" || chmod u+rw "$POSTGRESQL_WAL_ARCHIVE_COMMAND_DIR"

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.