Re: locks in CREATE TRIGGER, ADD FK - Mailing list pgsql-hackers

From Andrew - Supernews
Subject Re: locks in CREATE TRIGGER, ADD FK
Date
Msg-id slrnd9lufl.1d3v.andrew+nonews@trinity.supernews.net
Whole thread Raw
In response to locks in CREATE TRIGGER, ADD FK  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
On 2005-05-30, Neil Conway <neilc@samurai.com> wrote:
> On Wed, 2005-03-23 at 10:04 -0500, Tom Lane wrote:
>> I think last night's discussion makes it crystal-clear why I felt that
>> this hasn't been sufficiently thought through.  Please revert until the
>> discussion comes to a conclusion.
>
> Are there any remaining objections to reapplying this patch?

I've run into a few questions recently that might be relevent to the
issue of DDL locking in general and therefore possibly this change in
particular.

The most significant one is to do with the pg_get_*def functions and
their consistency, or otherwise, with explicit scans of the system
catalogs. The problem here of course is that the pg_get_*def functions
mostly (but not exclusively) use the syscache and therefore see data
relative to SnapshotNow, whereas the queries that are invoking them
are likely to be doing explicit scans of the catalog tables within the
transaction's active snapshot (and for a long-running serializable
transaction such as pg_dump, these may be some way apart).

The obvious place to look for failure modes is to see whether pg_dump
can be made to fail by deleting something (index, perhaps?) that it is
expecting to find, and see whether it chokes (pg_get_indexdef will elog
if the index doesn't exist in SnapshotNow). Dropping a view might be
another case where this can be made to fail.

-- 
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: compiling postgres with Visual Age compiler on
Next
From: Michael Glaesemann
Date:
Subject: Interval->day proposal