This is easily reproducible when systemd is not used to manage postgres
lifetime. So, yes, quite easy to reproduce and verify if a fix is valid or
not.
On Mon., Mar. 25, 2019, 09:25 Christian Ehrhardt , <
<email address hidden>> wrote:
> Yeah Michael,
> Making just the commit [1] an SRU where needed would have been my thought
> as well. But since it is assigned to Mario I wanted to know if he is still
> (or again) working on this to avoid doing the work twice - also they might
> as well have ended up with discussions somewhere completely else so getting
> feedback from him was the obvious next step.
>
> @Dmitrii a few things to confirm, to get the ball rolling in case Mario
> won't respond.
> - are you hitting that at all in regard to pgsql "through ressource agent"
> or are you deploying just postgresql alone (to decide which package(s)
> actually need fixes)?
> - If we would provide a PPA do you have an environment to easily
> test/verify them?
>
> [1]: https://github.com/ClusterLabs/resource-
> agents/pull/1102/commits/00d888c00651eb178dc3a97d50359571963b5d44
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1749283
>
> Title:
> configured stats_temp_directory does not get created after reboot
>
> Status in postgresql-common package in Ubuntu:
> Won't Fix
> Status in resource-agents package in Ubuntu:
> In Progress
> Status in postgresql-common source package in Xenial:
> Won't Fix
> Status in resource-agents source package in Xenial:
> New
> Status in postgresql-common source package in Artful:
> Won't Fix
> Status in resource-agents source package in Artful:
> Invalid
> Status in postgresql-common source package in Bionic:
> Won't Fix
> Status in resource-agents source package in Bionic:
> New
> Status in postgresql-common package in Debian:
> Fix Released
>
> Bug description:
> Default postgres installation in Ubuntu (and Debian) configures
> stats_temp_directory inside /var/run/postgresql:
>
> $ grep stats_temp /etc/postgresql/10/main/postgresql.conf
> stats_temp_directory = '/var/run/postgresql/10-main.pg_stat_tmp'
>
> However, this directory is not created after reboot.
>
> In most cases this is not a problem as systemd starts postgres via
> pg_ctlcluster, a "multiversion/cluster aware pg_ctl wrapper", and
> pg_ctlcluster will create missing directories before starting
> postgres.
>
> But in cases where systemd is not starting postgres this is a problem.
> Specifically, when postgres is controlled by pacemaker (using postgres
> resource agent for pacemaker) it is started using pg_ctl wrapper. pg_ctl
> won't create missing directories and therefore postgres fails to start.
>
> The simplest solution for this issue is to have systemd recreate
> missing directories via /usr/lib/tmpfiles.d/postgresql.conf file.
>
> Currently only /var/run/postgresql and /var/log/postgresql are created
> using systemd-tmpfiles.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/postgresql-common/+bug/1749283/+subscriptions
>
This is easily reproducible when systemd is not used to manage postgres
lifetime. So, yes, quite easy to reproduce and verify if a fix is valid or
not.
On Mon., Mar. 25, 2019, 09:25 Christian Ehrhardt , <
<email address hidden>> wrote:
> Yeah Michael, /github. com/ClusterLabs /resource- pull/1102/ commits/ 00d888c00651eb1 78dc3a97d503595 71963b5d44 /bugs.launchpad .net/bugs/ 1749283 directory does not get created after reboot directory inside /var/run/ postgresql: /10/main/ postgresql. conf directory = '/var/run/ postgresql/ 10-main. pg_stat_ tmp' cluster aware pg_ctl wrapper", and tmpfiles. d/postgresql. conf file. /bugs.launchpad .net/ubuntu/ +source/ postgresql- common/ +bug/1749283/ +subscriptions
> Making just the commit [1] an SRU where needed would have been my thought
> as well. But since it is assigned to Mario I wanted to know if he is still
> (or again) working on this to avoid doing the work twice - also they might
> as well have ended up with discussions somewhere completely else so getting
> feedback from him was the obvious next step.
>
> @Dmitrii a few things to confirm, to get the ball rolling in case Mario
> won't respond.
> - are you hitting that at all in regard to pgsql "through ressource agent"
> or are you deploying just postgresql alone (to decide which package(s)
> actually need fixes)?
> - If we would provide a PPA do you have an environment to easily
> test/verify them?
>
> [1]: https:/
> agents/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> configured stats_temp_
>
> Status in postgresql-common package in Ubuntu:
> Won't Fix
> Status in resource-agents package in Ubuntu:
> In Progress
> Status in postgresql-common source package in Xenial:
> Won't Fix
> Status in resource-agents source package in Xenial:
> New
> Status in postgresql-common source package in Artful:
> Won't Fix
> Status in resource-agents source package in Artful:
> Invalid
> Status in postgresql-common source package in Bionic:
> Won't Fix
> Status in resource-agents source package in Bionic:
> New
> Status in postgresql-common package in Debian:
> Fix Released
>
> Bug description:
> Default postgres installation in Ubuntu (and Debian) configures
> stats_temp_
>
> $ grep stats_temp /etc/postgresql
> stats_temp_
>
> However, this directory is not created after reboot.
>
> In most cases this is not a problem as systemd starts postgres via
> pg_ctlcluster, a "multiversion/
> pg_ctlcluster will create missing directories before starting
> postgres.
>
> But in cases where systemd is not starting postgres this is a problem.
> Specifically, when postgres is controlled by pacemaker (using postgres
> resource agent for pacemaker) it is started using pg_ctl wrapper. pg_ctl
> won't create missing directories and therefore postgres fails to start.
>
> The simplest solution for this issue is to have systemd recreate
> missing directories via /usr/lib/
>
> Currently only /var/run/postgresql and /var/log/postgresql are created
> using systemd-tmpfiles.
>
> To manage notifications about this bug go to:
>
> https:/
>