| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | Robert Sjöblom <robert(dot)sjoblom(at)fortnox(dot)se> |
| Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Logical Replication Sync Validation |
| Date: | 2023-04-18 10:48:49 |
| Message-ID: | 1D023CFA-64F5-45BA-B9BC-8985813040C2@thebuild.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On Apr 18, 2023, at 03:45, Robert Sjöblom <robert(dot)sjoblom(at)fortnox(dot)se> wrote:
> I'm aware of that. But you can, however, do something like:
>
> SELECT * FROM FOO WHERE CTID = (SELECT MAX(CTID) FROM FOO);
>
> on both sides. The idea being that if I change FOO, the CTID of the changed row will not be the same on both sides, but the CTID will point to the changed row on both sides. Or am I not understanding it correctly?
CTIDs are not monotonically increasing; they're locator in the file that holds the table data. There's no reason to believe that a record on the subscriber will happen to land in any particular position.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2023-04-18 14:30:11 | Re: Request for information about postgres version 15.2 stability |
| Previous Message | John Howroyd | 2023-04-18 09:52:55 | Re: Guidance on INSERT RETURNING order |