Re: make async slave to wait for lsn to be replayed

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Ivan Kartyshov <i(dot)kartyshov(at)postgrespro(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Thom Brown <thom(at)linux(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: make async slave to wait for lsn to be replayed
Date: 2017-03-21 17:17:47
Message-ID: CA+Tgmob-aG3Lqh6OpvMDYTNR5eyq94VugyEejyk7pLhE9uwnyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 12, 2017 at 10:20 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2017-03-21 17:19:00 Re: Patch: Write Amplification Reduction Method (WARM)
Previous Message Bruce Momjian 2017-03-21 17:17:27 Re: Patch: Write Amplification Reduction Method (WARM)