Using homebrew for minor updates breaks existing clusters

[zabrador]

I just ran homebrew upgrade on petere/postgresql@11 (11.0 -> 11.1) and petere/[email protected] (9.4.19 -> 19.4.20). I had one existing cluster for each, both of which were broken after the upgrade with the following error message (11 was similar, except for the version number):

❯ pg_ctlcluster 9.4 meundies restart
The PostgreSQL server failed to start. Please check the log output:
LOG:  could not open configuration directory "/usr/local/etc/postgresql/9.4/meundies/conf.d": No such file or directory
FATAL:  configuration file "/usr/local/etc/postgresql/9.4/meundies/postgresql.conf" contains errors

It sounds like, by default, postgres expects conf.d to exist. Manually creating the directory for both clusters fixed the issue. Is this expected behavior, or is it possible to have the formulae handle this for us? I'd love to help with the solution, although I must admit I'm not very familiar with the structure of homebrew formulae and might need some direction.

[zabrador]

Just a quick update: simply adding conf.d does not appear to have solved the problem. Dropping and then recreating the cluster did, however.

[TimFletcher]

I have the same issue. I'm not sure whether it's updating brew or what but something on my system removes conf.d in each cluster, breaking it. I have to remove and recreate the cluster (and then re-import databases for each project) to fix it.

# This worked last week...
$ pg_ctlcluster 9.6 gcp start
The PostgreSQL server failed to start. Please check the log output:
LOG:  could not open configuration directory "/usr/local/etc/postgresql/9.6/gcp/conf.d": No such file or directory
FATAL:  configuration file "/usr/local/etc/postgresql/9.6/gcp/postgresql.conf" contains errors

[TimFletcher]

As part of installing an unrelated package via brew yesterday (which I believe ran brew update) all my PG installations are broken again because conf.d gets deleted.

ls /usr/local/etc/postgresql/9.6/gcp -al

$ ls -al
total 96
drwxr-xr-x  8 tim  staff    256 18 Mar 17:10 .
drwxr-xr-x  3 tim  admin     96 30 Jan 11:34 ..
-rw-r--r--  1 tim  staff    315 30 Jan 11:34 environment
-rw-r--r--  1 tim  staff    143 30 Jan 11:34 pg_ctl.conf
-rw-r-----  1 tim  staff   4453 30 Jan 11:34 pg_hba.conf
-rw-r-----  1 tim  staff   1636 30 Jan 11:34 pg_ident.conf
-rw-r--r--  1 tim  staff  22443 30 Jan 11:34 postgresql.conf
-rw-r--r--  1 tim  staff    317 30 Jan 11:34 start.conf

I'll create a backup of them this time.

[skplunkerin]

This just happened to me. Guess I'll try dropping/recreating each of my clusters.

It looks like #49 is similar to this problem