Re: pg_dump restore time and Foreign Keys

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Decibel! <decibel(at)decibel(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump restore time and Foreign Keys
Date: 2008-06-09 16:37:47
Message-ID: 200806091237.49153.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday 09 June 2008 11:59:27 Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Mon, 2008-06-09 at 11:33 -0400, Tom Lane wrote:
> >> No, we are running a large query to which the user *thinks* he knows the
> >> answer. There are any number of reasons why he might be wrong.
> >
> > Of course. I should have said "to which we already know the answer" to
> > indicate I'm passing on others' criticisms of us.
>
> [ shrug... ] We don't know the answer either, and anyone who says
> we do is merely betraying his ignorance of the number of ways to load
> a foot-gun.
>

I think the more realistic scenario (based on the FK idea) is that you want to
prevent any future rows from coming without validating the FK, and you're
willing to clean up any violators after the fact, since you can make that
an "out of the critical path" operation.

if you extend this to a more general "create constraint concurrently" (to
handle normal constraint, not null constraints, etc...), it would certainly
be a big win, and i think most would see it as a reasonable compromise.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2008-06-09 17:09:37 Re: proposal: new contrib module - session variables
Previous Message Simon Riggs 2008-06-09 16:26:32 Re: Strange issue with GiST index scan taking far too long