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

From Andres Freund
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id 20200410210641.5cub2minmnciydvv@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2020-04-10 16:29:39 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I don't think a function is a good idea - it'll cause a snapshot to be
> > held while waiting. Which in turn will cause hot_standby_feedback to not
> > be able to report an increased xmin up. And it will possibly hit
> > snapshot recovery conflicts.
>
> Good point, but we could address that by making it a procedure no?

Probably. Don't think we have great infrastructure for builtin
procedures yet though? We'd presumably not want to use plpgsql.

ISTM that we can make it BEGIN AFTER 'xx/xx' or such, which'd not
require any keywords, it'd be easier to use than a procedure.

With a separate procedure, you'd likely need more roundtrips / complex
logic at the client. You either need to check first if the procedure
errored ou, and then send the BEGIN, or send both together and separate
out potential errors.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: pg_basebackup, manifests and backends older than ~12
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed