From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi> |
Subject: | Re: logical decoding and replication of sequences, take 2 |
Date: | 2023-03-18 15:19:53 |
Message-ID: | 18d207e1-ad9f-c2b7-dcb9-8c9707966e61@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/18/23 06:35, Amit Kapila wrote:
> On Sat, Mar 18, 2023 at 3:13 AM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>>
>> ...
>>
>> Clearly, for sequences we can't quite rely on snapshots/slots, we need
>> to get the LSN to decide what changes to apply/skip from somewhere else.
>> I wonder if we can just ignore the queued changes in tablesync, but I
>> guess not - there can be queued increments after reading the sequence
>> state, and we need to apply those. But maybe we could use the page LSN
>> from the relfilenode - that should be the LSN of the last WAL record.
>>
>> Or maybe we could simply add pg_current_wal_insert_lsn() into the SQL we
>> use to read the sequence state ...
>>
>
> What if some Alter Sequence is performed before the copy starts and
> after the copy is finished, the containing transaction rolled back?
> Won't it copy something which shouldn't have been copied?
>
That shouldn't be possible - the alter creates a new relfilenode and
it's invisible until commit. So either it gets committed (and then
replicated), or it remains invisible to the SELECT during sync.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-03-18 15:24:09 | Re: proposal: psql: psql variable BACKEND_PID |
Previous Message | Alexander Lakhin | 2023-03-18 15:00:01 | Re: BF mamba failure |