| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Petr Jelinek <petr(dot)jelinek(at)enterprisedb(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-15 03:54:13 |
| Message-ID: | CAA4eK1J_ga6zW6BzQtiwEX-1KZMz-YeoEg0Yd3+1hie136mEwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Feb 13, 2021 at 10:23 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> On 2021-02-13 17:37:29 +0100, Petr Jelinek wrote:
>
> > 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, ...).
>
We are already using origins in apply-worker to guarantee that and
with each commit, the origin's lsn location is also WAL-logged. That
helps us to send the start location for a slot after the restart. As
far as I understand this is how it works from the apply-worker side. I
am not sure if I am missing something here?
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2021-02-15 04:39:53 | Re: 64-bit XIDs in deleted nbtree pages |
| Previous Message | Thomas Munro | 2021-02-15 03:28:08 | Re: Default wal_sync_method on FreeBSD |