Re: old_snapshot_threshold vs indexes

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
Date: 2019-08-27 01:54:46
Message-ID: 3396.1566870886@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
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