Re: Logical decoding on standby - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Logical decoding on standby
Date
Msg-id CAMsr+YEg9ZNvKp56jRpirG38XgtM4b4unh2k2yUN6U=hcB6-EA@mail.gmail.com
Whole thread Raw
In response to Re: Logical decoding on standby  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Logical decoding on standby  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Hi all

Here's the final set of three patches on top of what's already committed.

The first is catalog_xmin logging, which is unchanged from the prior post.

The 2nd is support for conflict with recovery, with changes that
should address Andres's concerns there.

The 3rd actually enables decoding on standby. Unlike the prior
version, no attempt is made to check the walsender configuration for
slot use, etc. The ugly code to try to mitigate races is also removed.
Instead, if wal_level is logical the catalog_xmin sent by
hot_standby_feedback is now the same as the xmin if there's no local
slot holding it down. So we're always sending a catalog_xmin in
feedback and we should always expect to have a valid local
oldestCatalogXmin once hot_standby_feedback kicks in. This makes the
race in slot creation no worse than the existing race between
hot_standby_feedback establishment and the first queries run on a
downstream, albeit with more annoying consequences. Apps can still
ensure a slot created on standby is guaranteed safe and conflict-free
by having a slot on the master first.

I'm much happier with this. I'm still fixing some issues in the tests
for 03 and tidying them up, but 03 should allow 01 and 02 to be
reviewed in their proper context now.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: background sessions
Next
From: Craig Ringer
Date:
Subject: Re: Logical decoding on standby