|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Thomas Munro <thomas(dot)munro(at)gmail(dot)com>|
|Cc:||pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com>|
|Subject:||Re: old_snapshot_threshold vs indexes|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> OK I started writing a patch and realised there were a few ugly
> problems that I was about to report here... but now I wonder if, based
> on the comment for RelationHasUnloggedIndex(), we shouldn't just nuke
> all this code. We don't actually support unlogged indexes on
> permanent tables (there is no syntax to create them, and
> RelationHasUnloggedIndex() will never return true in practice because
> RelationNeedsWAL() will always return false first).
Oh! That explains why the code coverage report shows clearly that
RelationHasUnloggedIndex never returns true ;-)
> This is a locking
> protocol violation and a performance pessimisation in support of a
> feature we don't have. If we add support for that in some future
> release, we can figure out how to do it properly then, no?
+1. That fix is also back-patchable, which adding fields to relcache
entries would not be.
It's not really apparent to me that unlogged indexes on logged tables
would ever be a useful combination, so I'm certainly willing to nuke
poorly-thought-out code that putatively supports it. But perhaps
we should add some comments to remind us that this area would need
work if anyone ever wanted to support that. Not sure where.
regards, tom lane
|Next Message||Thomas Munro||2019-08-27 02:09:17||Re: gharial segfaulting on REL_12_STABLE only|
|Previous Message||Tom Lane||2019-08-27 01:48:01||Re: gharial segfaulting on REL_12_STABLE only|