Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id CA+U5nMJNg3aHfXiestbSA0fst_3bEVo4To1J+nwTkEqG9rjrRw@mail.gmail.com
Whole thread Raw
In response to Re: ALTER TABLE lock strength reduction patch is unsafe  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: ALTER TABLE lock strength reduction patch is unsafe  (Vik Fearing <vik.fearing@dalibo.com>)
List pgsql-hackers
On 5 March 2014 09:28, Simon Riggs <simon@2ndquadrant.com> wrote:

> So that returns us to solving the catalog consistency problem in
> pg_dump and similar applications.

No answer, guys, and time is ticking away here.

I'd like to get a communal solution to this rather than just punting
the whole patch.

If we have to strip it down to the bar essentials, so be it. For me,
the biggest need here is to make VALIDATE CONSTRAINT take only a
ShareUpdateExclusiveLock while it runs. Almost everything else needs a
full AccessExclusiveLock anyway, or doesn't run for very long so isn't
a critical problem. (Perhaps we can then wrap ADD CONSTRAINT ... NOT
VALID and VALIDATE into a single command using the CONCURRENTLY
keyword so it runs two transactions to complete the task).

Validating FKs on big tables can take hours and it really isn't
acceptable for us to lock out access while we do that. FKs are
*supposed* to be a major reason people use RDBMS, so keeping them in a
state where they are effectively unusable is a major debilitating
point against adoption of PostgreSQL.

If there are issues with pg_dump we can just document them.

Guide me with your thoughts.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: jsonb and nested hstore
Next
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore