Gregory Stark <stark@enterprisedb.com> writes:
>> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>>> AFAICS, the whole indcreatexid and validForTxn business is a waste of
>>> code. By the time CREATE INDEX CONCURRENTLY is ready to set indisvalid,
>>> surely any transactions that could see the broken HOT chains are gone.
> In answer to the real question you were actually asking, I believe you're
> correct that CREATE INDEX CONCURRENTLY should never need to set indcreatexid.
> Only regular non-concurrent CREATE INDEX needs to protect against that
> problem.
Argh, I'd momentarily gotten concurrent and nonconcurrent cases backwards.
I would still desperately like to get rid of indcreatexid, though,
because the patch's existing mechanism for clearing it is junk.
There's no guarantee that it will get cleared before it wraps around,
because the clearing is attached to vacuuming of the wrong table.
Maybe you could make it work by special-casing vacuuming of pg_index
itself, but the whole thing's a crock anyway.
[ thinks some more ... ] Hmm, maybe instead of an explicit XID stored in
the pg_index row proper, we could use the xmin of the pg_index row
itself? That's already got a working mechanism for getting frozen.
regards, tom lane
