Re: Conflict Detection and Resolution

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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>
Subject: Re: Conflict Detection and Resolution
Date: 2024-06-16 22:48:13
Message-ID: e4cdb849-d647-4acf-aabe-7049ae170fbf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/14/24 13:29, Amit Kapila wrote:
> On Fri, Jun 14, 2024 at 12:10 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>
>> On Thu, May 23, 2024 at 2:37 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>>> c) update_deleted: The row with the same value as that incoming
>>> update's key does not exist. The row is already deleted. This conflict
>>> type is generated only if the deleted row is still detectable i.e., it
>>> is not removed by VACUUM yet. If the row is removed by VACUUM already,
>>> it cannot detect this conflict. It will detect it as update_missing
>>> and will follow the default or configured resolver of update_missing
>>> itself.
>>
>> I think this design is categorically unacceptable. It amounts to
>> designing a feature that works except when it doesn't. I'm not exactly
>> sure how the proposal should be changed to avoid depending on the
>> timing of VACUUM, but I think it's absolutely not OK to depend on the
>> timing of VACUUm -- or, really, this is going to depend on the timing
>> of HOT-pruning, which will often happen almost instantly.
>>
>
> Agreed, above Tomas has speculated to have a way to avoid vacuum
> cleaning dead tuples until the required changes are received and
> applied. Shveta also mentioned another way to have deads-store (say a
> table where deleted rows are stored for resolution) [1] which is
> similar to a technique used by some other databases. There is an
> agreement to not rely on Vacuum to detect such a conflict but the
> alternative is not clear.

I'm not sure I'd say I "speculated" about it - it's not like we don't
have ways to hold off cleanup for a while for various reasons
(long-running query, replication slot, hot-standby feedback, ...).

How exactly would that be implemented I don't know, but it seems like a
far simpler approach than inventing a new "dead store". It'd need logic
to let the vacuum to cleanup the stuff no longer needed, but so would
the dead store I think.

> Currently, we are thinking to consider such
> a conflict type as update_missing (The row with the same value as that
> incoming update's key does not exist.). This is how the current HEAD
> code behaves and LOGs the information (logical replication did not
> find row to be updated ..).
>

I thought the agreement was we need both conflict types to get sensible
behavior, so proceeding with just the update_missing (mostly because we
don't know how to detect these conflicts reliably) seems like maybe not
be the right direction ...

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2024-06-16 22:57:35 Re: Using LibPq in TAP tests via FFI
Previous Message Andres Freund 2024-06-16 22:38:30 Re: Using LibPq in TAP tests via FFI