Re: Collation versioning

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Douglas Doole <dougdoole(at)gmail(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation versioning
Date: 2020-09-07 03:17:41
Message-ID: 20200907031741.GK2455@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 14, 2020 at 11:02:35AM +0200, Julien Rouhaud wrote:
> On Fri, Aug 14, 2020 at 04:37:46PM +0900, Michael Paquier wrote:
>> + /*
>> + * XXX For deterministic transaction, se should only track the
>> version
>> + * if the AM relies on a stable ordering.
>> + */
>> + if (determ_colls)
>> + {
>> + /* XXX check if the AM relies on a stable ordering */
>> + recordDependencyOnCollations(&myself, determ_colls, true);
>> Some cleanup needed here? Wouldn't it be better to address the issues
>> with stable ordering first?
>
> Didn't we just agreed 3 mails ago to *not* take care of that in this patch, and
> add an extensible solution for that later? I kept the XXX comment to make it
> extra clear that this will be addressed.

FWIW, I tend to prefer the approach where we put in place the
necessary infrastructure first, and then have a feature rely on what
we think is the most correct. This way, we avoid having any moment in
the code history where we have something that we know from the start
is not covered.

The patch set needs a rebase. There are conflicts coming at least
from pg_depend.c where I switched the code to use multi-INSERTs for
catalog insertions.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-09-07 03:34:51 Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation
Previous Message Noah Misch 2020-09-07 03:14:21 Re: Spurious "apparent wraparound" via SimpleLruTruncate() rounding