On 23 March 2017 at 00:13, Simon Riggs <simon.riggs@2ndquadrant.com> wrote:
> On 22 March 2017 at 08:53, Craig Ringer <craig@2ndquadrant.com> wrote:
>
>> I'm splitting up the rest of the decoding on standby patch set with
>> the goal of getting minimal functionality for creating and managing
>> slots on standbys in, so we can maintain slots on standbys and use
>> them when the standby is promoted to master.
>>
>> The first, to send catalog_xmin separately to the global xmin on
>> hot_standby_feedback and store it in the upstream physical slot's
>> catalog_xmin, is attached.
>>
>> These are extracted directly from the logical decoding on standby
>> patch, with comments by Petr and Andres made re the relevant code
>> addressed.
>
> I've reduced your two patches back to one with a smaller blast radius.
>
> I'll commit this tomorrow morning, barring objections.
This needs rebasing on top of
commit af4b1a0869bd3bb52e5f662e4491554b7f611489
Author: Simon Riggs <simon@2ndQuadrant.com>
Date: Wed Mar 22 16:51:01 2017 +0000
Refactor GetOldestXmin() to use flags
Replace ignoreVacuum parameter with more flexible flags.
Author: Eiji Seki
Review: Haribabu Kommi
That patch landed up using PROCARRAY flags directly as flags to
GetOldestXmin, so it doesn't make much sense to add a flag like
PROCARRAY_REPLICATION_SLOTS . There won't be any corresponding PROC_
flag for PGXACT->vacuumFlags, replication slot xmin and catalog_xmin
are global state not tracked in individual proc entries.
Rather than add some kind of "PROC_RESERVED" flag in proc.h that would
never be used and only exist to reserve a bit for use for
PROCARRAY_REPLICATION_SLOTS, which we'd use a flag to GetOldestXmin, I
added a new argument to GetOldestXmin like the prior patch did.
If preferred I can instead add
proc.h:
#define PROC_RESERVED 0x20
procarray.h:
#define PROCARRAY_REPLICATION_SLOTS 0x20
and then test for (flags & PROCARRAY_REPLICATION_SLOTS)
but that's kind of ugly to say the least, I'd rather just add another argument.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
