Re: pgsql: Allow group access on PGDATA - Mailing list pgsql-committers

From Stephen Frost
Subject Re: pgsql: Allow group access on PGDATA
Date
Msg-id 20180407221259.GA27724@tamriel.snowman.net
Whole thread Raw
In response to Re: pgsql: Allow group access on PGDATA  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-committers
Peter,

* Peter Geoghegan (pg@bowt.ie) wrote:
> On Sat, Apr 7, 2018 at 2:46 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > Allow group access on PGDATA
> >
> > Allow the cluster to be optionally init'd with read access for the
> > group.
>
> Looks like this broke prion and culicidae. On culicidae, clearly the
> problem is here:

The error on prion is pretty clearly unrelated and has to do with
postgres_fdw plan instability, as discussed elsewhere recently..

> """
> Upgrade Complete
> ----------------
> Optimizer statistics are not transferred by pg_upgrade so,
> once you start the new server, consider running:
>     ./analyze_new_cluster.sh
>
> Running this script will delete the old cluster's data files:
>     ./delete_old_cluster.sh
> + find /home/andres/build/buildfarm-culicidae/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/data
> -type f ! -perm 640
> + wc -l
> + [ 1778 -ne 0 ]
> + echo files in PGDATA with permission != 640
> files in PGDATA with permission != 640
> + exit 1
> + rm -rf /tmp/pg_upgrade_check-h6epmk
> make: *** [Makefile:40: check] Error 1
> """

Yes, that's the error, the question is what's different about that
member from the others where things are working as expected.

I was a bit nervous that the test here might be overly optimistic about
what it can expect on buildfarm members.  Chatting with David about it
currently.

Thanks!

Stephen

Attachment

pgsql-committers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Allow group access on PGDATA
Next
From: David Rowley
Date:
Subject: Re: pgsql: Support partition pruning at execution time