Re: [HACKERS] make async slave to wait for lsn to be replayed - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id CA+Tgmob-aG3Lqh6OpvMDYTNR5eyq94VugyEejyk7pLhE9uwnyA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
On Sun, Mar 12, 2017 at 10:20 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Maybe someone can think of a clever way for an extension to insert a
> wait for a user-supplied LSN *before* acquiring a snapshot so it can
> work for the higher levels, or maybe the hooks should go into core
> PostgreSQL so that the extension can exist as an external project not
> requiring a patched PostgreSQL installation, or maybe this should be
> done with new core syntax that extends transaction commands.  Do other
> people have views on this?

IMHO, trying to do this using a function-based interface is a really
bad idea for exactly the reasons you mention.  I don't see why we'd
resist the idea of core syntax here; transactions are a core part of
PostgreSQL.

There is, of course, the question of whether making LSNs such a
user-visible thing is a good idea in the first place, but that's a
separate question from issue of what syntax for such a thing is best.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)