Re: pg_dump restore time and Foreign Keys - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: pg_dump restore time and Foreign Keys
Date
Msg-id 1212860515.12046.78.camel@ebony.site
Whole thread Raw
In response to Re: pg_dump restore time and Foreign Keys  (Robert Treat <xzilla@users.sourceforge.net>)
Responses Re: pg_dump restore time and Foreign Keys  (Andrew Dunstan <andrew@dunslane.net>)
Re: pg_dump restore time and Foreign Keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, 2008-06-07 at 13:08 -0400, Robert Treat wrote:
> On Thursday 05 June 2008 08:56:35 Simon Riggs wrote:
> > On Thu, 2008-06-05 at 07:57 -0400, Andrew Dunstan wrote:

> Heh, I would have argued that the idea should go the other way and
> just make this part of the normal syntax.  Oracle DBA's have been
> doing this for years (MS SQL supports it too actually) and it really
> helps working around having to hold locks on large relations for
> lengthy periods of times. Heck, I'd like to see a no check option for
> all constraints really. 

Interesting that SQL Server does it also.

Holding the lock for a long period is just one more problem. :-)

I'm always torn between the I-know-what-Im-doing-so-give-me-the-option
viewpoint and the some-dumbass-will-abuse-it viewpoint. I see the
results of both viewpoints daily.

Perhaps we need a GUC that says expert_mode = on. In expert_mode we are
allowed to do a range of things that are normally avoided - there would
be an explicit list. Managers can then take a single considered decision
as to whether the situation warrants extreme action and their DBA is
good enough to handle it. That might resolve our continued angst about
whether our users our smart enough to avoid the gotchas, or just smart
enough to win a DBA's Darwin Award. 

The UNIX philosophy has always been to allow the power to exist, yet
seek to minimise the number of people who exercise it. Another idea
might be to make such command options superuser only, to ensure the
power is available, yet only in the hands of, by-definition, the trusted
few.

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



pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: pg_dump restore time and Foreign Keys
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_dump restore time and Foreign Keys