Re: Collation versioning

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Douglas Doole <dougdoole(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Christoph Berg <myon(at)debian(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation versioning
Date: 2019-11-04 03:58:08
Message-ID: CA+hUKGKOEu0BSURXFG=uREu1yjRXEfNj7yYmAgp-OmZm6H-Zxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 1, 2019 at 2:21 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> Are you planning to continue working on it? For the record, that's
> something needed to be able to implement a filter in REINDEX command
> [1].

Bonjour Julien,

Unfortunately I haven't had time to work on it seriously, but here's a
quick rebase to get the proof-of-concept back into working shape.
It's nice to see progress in other bits of the problem-space. I hope
to have time to look at this patch set again soon, but if you or
someone else would like hack on or think about it too, please feel
free!

Yes indeed this is exactly the same problem that you're trying to
solve, approached from a different starting point.

Here are some problems to think about:

* We'd need to track dependencies on the default collation once we
have versioning for that (see
https://www.postgresql.org/message-id/flat/5e756dd6-0e91-d778-96fd-b1bcb06c161a%402ndquadrant.com).
That is how most people actually consume collations out there in real
life, and yet we don't normally track dependencies on the default
collation and I don't know if that's simply a matter of ripping out
all the code that looks like "xxx != DEFAULT_COLLATION_ID" in the
dependency analysis code or if there's more to it.
* Andres mentioned off-list that pg_depend rows might get blown away
and recreated in some DDL circumstances. We need to look into that.
* Another is that pg_upgrade won't preserve pg_depend rows, so you'd
need some catalog manipulation (direct or via new DDL) to fix that.
* Some have expressed doubt that pg_depend is the right place for
this; let's see if any counter-proposals appear.

> # reindex table t1;
> WARNING: 01000: index "t1_val_idx" depends on collation 13330 version
> "a153.97.35.8", but the current version is "153.97.35.8"
> DETAIL: The index may be corrupted due to changes in sort order.
> HINT: REINDEX to avoid the risk of corruption.
> LOCATION: index_check_collation_version, index.c:1263

Duh. Yeah, that's stupid and needs to be fixed somehow.

Attachment Content-Type Size
0001-Remove-pg_collation.collversion-v2.patch application/octet-stream 21.2 KB
0002-Add-pg_depend.refobjversion-v2.patch application/octet-stream 10.3 KB
0003-Track-collation-versions-for-indexes-v2.patch application/octet-stream 10.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2019-11-04 04:20:05 Re: Allow superuser to grant passwordless connection rights on postgres_fdw
Previous Message Tom Lane 2019-11-04 03:53:00 TAP tests aren't using the magic words for Windows file access