pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndquadrant.com>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Robert Treat <xzilla@users.sourceforge.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Decibel! <decibel@decibel.org>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: pg_dump restore time and Foreign Keys
Date: Tue, 10 Jun 2008 01:14:25 +0100
Message-ID: <1213056865.12046.167.camel@ebony.site> (raw)
In-Reply-To: <20080609180728.GA10034@alvh.no-ip.org>
References: <1212647003.19964.19.camel@ebony.site>
	<1213026485.12046.123.camel@ebony.site>
	<20406.1213027167@sss.pgh.pa.us>
	<200806091237.49153.xzilla@users.sourceforge.net>
	<1213034097.12046.150.camel@ebony.site>
	<20080609180728.GA10034@alvh.no-ip.org>


On Mon, 2008-06-09 at 14:07 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> 
> > If we break down the action into two parts.
> > 
> > ALTER TABLE ... ADD CONSTRAINT foo FOREIGN KEY ... NOVALIDATE;
> > which holds exclusive lock, but only momentarily
> > After this runs any new data is validated at moment of data change, but
> > the older data has yet to be validated.
> > 
> > ALTER TABLE ... VALIDATE CONSTRAINT foo
> > which runs lengthy check, though only grabs lock as last part of action
> 
> The problem I see with this approach in general (two-phase FK creation)
> is that you have to keep the same transaction for the first and second
> command, but you really want concurrent backends to see the tuple for
> the not-yet-validated constraint row.

Well, they *must* be in separate transactions if we are to avoid holding
an AccessExclusiveLock while we perform the check. Plus the whole idea
is to perform the second part at some other non-critical time, though we
all agree that never performing the check at all is foolhardy.

Maybe we say that you can defer the check, but after a while autovacuum
runs it for you if you haven't done so. It would certainly be useful to
run the VALIDATE part as a background task with vacuum wait enabled.

> Another benefit that could arise from this is that the hypothetical
> VALIDATE CONSTRAINT step could validate more than one constraint at a
> time, possibly processing all the constraints with a single table scan.

Good thought, though not as useful for FK checks.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support




view thread (36+ messages)  latest in thread

Message-ID: <1213056865.12046.167.camel@ebony.site>
Permalink:  ../1213056865.12046.167.camel@ebony.site/
Also on:    postgresql.org/message-id/1213056865.12046.167.camel@ebony.site

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: simon@2ndquadrant.com, alvherre@commandprompt.com, xzilla@users.sourceforge.net, tgl@sss.pgh.pa.us, decibel@decibel.org, andrew@dunslane.net
  Subject: Re: pg_dump restore time and Foreign Keys
  In-Reply-To: <1213056865.12046.167.camel@ebony.site>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox