Skip site navigation (1) Skip section navigation (2)


From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Date: 2012-10-09 09:11:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 6 October 2012 00:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 1.  These operations think they can use ordinary heap_update operations
> to change pg_index entries when they don't have exclusive lock on the
> parent table.  The lack of ex-lock means that another backend could be
> currently loading up its list of index OIDs for the table --- and since
> it scans pg_index with SnapshotNow to do that, the heap_update could
> result in the other backend failing to see this index *at all*.  That's
> okay if it causes the other backend to not use the index for scanning...
> but not okay if it causes the other backend to fail to make index
> entries it is supposed to make.
> I think this could possibly be fixed by using nontransactional
> update-in-place when we're trying to change indisvalid and/or
> indisready, but I've not really thought through the details.

Only solution there is to fix SnapshotNow, as we discussed last
Christmas. I'll dig out my patch for that, which IIRC I was nervous of
committing at last minute into 9.2.

> 2.  DROP INDEX CONCURRENTLY doesn't bother to do
> TransferPredicateLocksToHeapRelation until long after it's invalidated
> the index.  Surely that's no good?  Is it even possible to do that
> correctly, when we don't have a lock that will prevent new predicate
> locks from being taken out meanwhile?

No idea there. Input appreciated.

 Simon Riggs         
 PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Sébastien LardièreDate: 2012-10-09 09:28:53
Subject: Re: Truncate if exists
Previous:From: Simon RiggsDate: 2012-10-09 09:09:13
Subject: Re: Truncate if exists

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group