| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info> |
| Subject: | Re: Conflict Detection and Resolution |
| Date: | 2024-06-13 13:30:33 |
| Message-ID: | 202406131330.nsisiap4jram@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2024-Jun-07, Tomas Vondra wrote:
> On 6/3/24 09:30, Amit Kapila wrote:
> > On Sat, May 25, 2024 at 2:39 AM Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
> >> How is this going to deal with the fact that commit LSN and timestamps
> >> may not correlate perfectly? That is, commits may happen with LSN1 <
> >> LSN2 but with T1 > T2.
> But as I wrote, I'm not quite convinced this means there are not other
> issues with this way of resolving conflicts. It's more likely a more
> complex scenario is required.
Jan Wieck approached me during pgconf.dev to reproach me of this
problem. He also said he had some code to fix-up the commit TS
afterwards somehow, to make the sequence monotonically increasing.
Perhaps we should consider that, to avoid any problems caused by the
difference between LSN order and TS order. It might be quite
nightmarish to try to make the system work correctly without
reasonable constraints of that nature.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-06-13 13:38:24 | Re: RFC: adding pytest as a supported test framework |
| Previous Message | Peter Eisentraut | 2024-06-13 12:45:50 | Re: Conflict Detection and Resolution |