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

From: Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, a(dot)korotkov(at)postgrespro(dot)ru, i(dot)kartyshov(at)postgrespro(dot)ru, amit(dot)kapila16(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: 2020-04-14 09:52:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2020-04-11 00:44, Andres Freund wrote:
> I think there's also some advantages of having it in a single statement
> for poolers. If a pooler analyzes BEGIN AFTER 'xx/xx' it could
> e.g. redirect the transaction to a node that's caught up far enough,
> instead of blocking. But that can't work even close to as easily if
> it's
> something that has to be executed before transaction begin.

I think that's a good point.

Also, I'm not sure how we'd expect a wait-for-LSN procedure to work
inside a single-snapshot transaction. Would it throw an error inside a
RR transaction block? Would it give a warning?

Anna Akenteva
Postgres Professional:
The Russian Postgres Company

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2020-04-14 10:10:50 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Pavel Stehule 2020-04-14 09:45:39 Re: Display of buffers for planning time show nothing for second run