|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Andres Freund <andres(at)anarazel(dot)de>|
|Cc:||Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2019-05-02 11:41:28 -0400, Tom Lane wrote:
>>> But don't we need to worry about resetting relfrozenxid?
>> Indexes don't have that though? We couldn't do it for pg_class itself,
>> but that's not a problem here.
> Hmm. Again, that seems like the sort of assumption that could bite
> us later. But maybe we could add some assertions that the new values
> match the old? I'll experiment.
Huh, this actually seems to work. The attached is a quick hack for
testing. It gets through check-world straight up and with
xxx_FORCE_RELEASE, and I've verified reindexing pg_class works with
CLOBBER_CACHE_ALWAYS, but it'll be a few hours before I have a full CCA
One interesting thing that turns up in check-world is that if wal_level
is minimal, we have to manually force an XID to be assigned, else
reindexing pg_class fails with "cannot commit a transaction that deleted
files but has no xid" :-(. Perhaps there's some other cleaner place to
If we go this path, we should remove RelationSetIndexList altogether
(in HEAD), but I've not done so here. The comments likely need more
I have to go out and do some errands for the next few hours, so I can't
push this forward any more right now.
regards, tom lane
|Next Message||Andres Freund||2019-05-02 17:28:51||Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6|
|Previous Message||Fabien COELHO||2019-05-02 16:35:57||Re: pgbench - add option to show actual builtin script code|