| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: logical decoding and replication of sequences, take 2 |
| Date: | 2023-01-11 20:28:51 |
| Message-ID: | 20230111202851.nrqybwypzk4k5bwg@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-01-11 15:23:18 -0500, Robert Haas wrote:
> Yeah, I meant if #1 had committed and then #2 started to do its thing.
> I was worried that decoding might reach the nextval operations in
> transaction #2 before it replayed #1.
>
> This worry may be entirely based on me not understanding how this
> actually works. Do we always apply a transaction as soon as we see the
> commit record for it, before decoding any further?
Yes.
Otherwise we'd have a really hard time figuring out the correct historical
snapshot to use for subsequent transactions - they'd have been able to see the
catalog modifications made by the committing transaction.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-01-11 20:33:29 | Re: Exposing the lock manager's WaitForLockers() to SQL |
| Previous Message | Andres Freund | 2023-01-11 20:27:02 | Re: Minimal logical decoding on standbys |