pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Kartyshov Ivan <i.kartyshov@postgrespro.ru>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: Fri, 06 Mar 2020 15:21:49 +0300
Message-ID: <195e2d07ead315b1620f1a053313f490@postgrespro.ru> (raw)

On 2020-03-06 08:54, Kyotaro Horiguchi wrote:
> The syntax seems getting confused. What happens if we typed in the
> command "WAIT FOR TIMESTAMP '...' UNTIL TIMESTAMP '....'"?  It seems
> to me the options is useles.  Couldn't the TIMEOUT option be a part of
> event?  I know gram.y doesn't accept that syntax but it is not
> apparent from the description above.

I`ll fix the doc file.

Synopsis
==========
      WAIT FOR [ANY | SOME | ALL] event [, event ...]
      and event is:
          LSN value [options]
          TIMESTAMP value

      and options is:
          TIMEOUT delay
          UNTIL TIMESTAMP timestamp

> As I read through the previous thread, one of the reason for this
> feature implemented as a syntax is it was inteded to be combined into
> BEGIN statement.  If there is not any use case for the feature midst
> of a transaction, why don't you turn it into a part of BEGIN command?

It`s seem to have some limitations on hot standbys. I`ll take few days
to make a prototype.

>> Description
>> ==========
>> WAIT FOR - make to wait statements (that are beneath) on sleep until
>> event happens (Don’t process new queries until an event happens).
> ...
>> Notice: WAIT FOR will release on PostmasterDeath or Interruption
>> events
>> if they come earlier then LSN or timeout.
> 
> I think interrupts ought to result in ERROR.
> 
> wait.c adds a fair amount of code and uses proc-array based
> approach. But Thomas suggested queue-based approach and I also think
> it is better.  We already have a queue-based mechanism that behaves
> almost the same with this feature in the comit code on master-side. It
> avoids spurious backend wakeups. Couldn't we extend SyncRepWaitForLSN
> or share a part of the code/infrastructures so that this feature can
> share the code?

I`ll take a look on.

Thank you for your review.

Rebased patch is attached.
-- 
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company





view thread (216+ messages)  latest in thread

Message-ID: <195e2d07ead315b1620f1a053313f490@postgrespro.ru>
Permalink:  ../195e2d07ead315b1620f1a053313f490@postgrespro.ru/
Also on:    postgresql.org/message-id/195e2d07ead315b1620f1a053313f490@postgrespro.ru

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: i.kartyshov@postgrespro.ru, horikyota.ntt@gmail.com
  Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
  In-Reply-To: <195e2d07ead315b1620f1a053313f490@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox