Re: [HACKERS] make async slave to wait for lsn to be replayed

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: ibrar(dot)ahmad(at)gmail(dot)com
Cc: i(dot)kartyshov(at)postgrespro(dot)ru, a(dot)pervushina(at)postgrespro(dot)ru, a(dot)akenteva(at)postgrespro(dot)ru, a(dot)korotkov(at)postgrespro(dot)ru, amit(dot)kapila16(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: 2021-03-22 05:05:10
Message-ID: 20210322.140510.419001276411171108.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 18 Mar 2021 18:57:15 +0500, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com> wrote in
> On Thu, Jan 21, 2021 at 1:30 PM Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
> wrote:
>
> > Hello.
> >
> > At Wed, 18 Nov 2020 15:05:00 +0300, a(dot)pervushina(at)postgrespro(dot)ru wrote in
> > > I've changed the BEGIN WAIT FOR LSN statement to core functions
> > > pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait.
> > > Currently the functions work inside repeatable read transactions, but
> > > waitlsn creates a snapshot if called first in a transaction block,
> > > which can possibly lead the transaction to working incorrectly, so the
> > > function gives a warning.
> >
> > According to the discuttion here, implementing as functions is not
> > optimal. As a Poc, I made it as a procedure. However I'm not sure it
> > is the correct implement as a native procedure but it seems working as
> > expected.
> >
> > > Usage examples
> > > ==========
> > > select pg_waitlsn(‘LSN’, timeout);
> > > select pg_waitlsn_infinite(‘LSN’);
> > > select pg_waitlsn_no_wait(‘LSN’);
> >
> > The first and second usage is coverd by a single procedure. The last
> > function is equivalent to pg_last_wal_replay_lsn(). As the result, the
> > following procedure is provided in the attached.
> >
> > pg_waitlsn(wait_lsn pg_lsn, timeout integer DEFAULT -1)
> >
> > Any opinions mainly compared to implementation as a command?
> >
> > regards.
> >
> > --
> > Kyotaro Horiguchi
> > NTT Open Source Software Center
> >
>
> The patch (pg_waitlsn_v10_2_kh.patch) does not compile successfully and has
> compilation errors. Can you please take a look?
>
> https://cirrus-ci.com/task/6241565996744704
>
> xlog.c:45:10: fatal error: commands/wait.h: No such file or directory
> #include "commands/wait.h"
> ^~~~~~~~~~~~~~~~~
> compilation terminated.
> make[4]: *** [<builtin>: xlog.o] Error 1
> make[4]: *** Waiting for unfinished jobs....
> make[3]: *** [../../../src/backend/common.mk:39: transam-recursive] Error 2
> make[2]: *** [common.mk:39: access-recursive] Error 2
> make[1]: *** [Makefile:42: all-backend-recurse] Error 2
> make: *** [GNUmakefile:11: all-src-recurse] Error 2
>
> I am changing the status to "Waiting on Author"

Anna is the autor. The "patch" was just to show how we can implement
the feature as a procedure. (Sorry for the bad mistake I made.)

The patch still applies to the master. So I resend just rebased
version as v10_2, and attached the "PoC" as *.txt which applies on top
of the patch.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
pg_waitlsn_v10_2.patch text/x-patch 16.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2021-03-22 05:07:43 Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
Previous Message Shinya11.Kato 2021-03-22 05:03:19 RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.