| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Petr Jelinek <petr(dot)jelinek(at)enterprisedb(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Markus Wanner <markus(dot)wanner(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Ajin Cherian <itsajin(at)gmail(dot)com>, Simon Riggs <simon(at)enterprisedb(dot)com> |
| Subject: | Re: repeated decoding of prepared transactions |
| Date: | 2021-02-13 16:53:23 |
| Message-ID: | 20210213165323.7ri3f5wrgxjrpjum@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-02-13 17:37:29 +0100, Petr Jelinek wrote:
> Agreed, if we relied purely on flush location of a slot, there would
> be no need for origins to track the lsn.
And we would be latency bound replicating transactions, which'd not be
fun for single-insert ones for example...
> AFAIK this is exactly why origins are Wal logged along with
> transaction, it allows us to guarantee never getting anything that has
> beed durably written.
I think you'd need something like origins in that case, because
something could still go wrong before the other side has received the
flush (network disconnect, primary crash, ...).
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2021-02-13 17:19:34 | Re: Some regular-expression performance hacking |
| Previous Message | Petr Jelinek | 2021-02-13 16:37:29 | Re: repeated decoding of prepared transactions |