Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted. - Mailing list pgsql-committers

From Tom Lane
Subject Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.
Date
Msg-id 25505.1488831808@sss.pgh.pa.us
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup asparallel-restricted.  (David Steele <david@pgmasters.net>)
Responses Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup asparallel-restricted.
Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.
List pgsql-committers
David Steele <david@pgmasters.net> writes:
> On 3/6/17 12:48 PM, Robert Haas wrote:
>> This issue also exists in 9.6, but we obviously can't do anything
>> about 9.6 clusters that already exist.  Possibly this could be
>> back-patched so that future 9.6 clusters would come out OK, or
>> possibly we should back-patch some other fix, but that would need more
>> discussion.

> I think it would be worth back-patching the catalog fix for future 9.6
> clusters as a start.

Yes, I think it's rather silly not to do so.  We have made comparable
backpatched fixes multiple times in the past.  What is worth discussing is
whether there are *additional* things we ought to do in 9.6 to prevent
misbehavior in installations initdb'd pre-9.6.3.

If there's a cheap way of testing "AmInParallelWorker", I'd be in favor of
adding a quick-n-dirty test and ereport(ERROR) to these functions in the
9.6 branch, so that at least you get a clean error and not some weird
misbehavior.  Not sure if there's anything more we can do than that.

            regards, tom lane


pgsql-committers by date:

Previous
From: David Steele
Date:
Subject: Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup asparallel-restricted.
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup asparallel-restricted.