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

From Robert Haas
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id CA+Tgmoa4g93c7haMviwox5L7jx3ZYDNb7BNK4QDcGrbPDw1yZw@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  (Atri Sharma <atri.jiit@gmail.com>)
Re: ALTER TABLE lock strength reduction patch is unsafe  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Tue, Mar 4, 2014 at 6:57 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The main impact I see is that this would block VACUUM while pg_dump runs.
>
> But then, while pg_dump runs VACUUM is ineffective anyway so perhaps
> that is no bad thing.

Well, a vacuum that's already running when pg_dump starts up may be
doing a lot of good, so it would be a shame to see pg_dump kill them
all off.

Also, this would put us in the surprising situation that you can't run
two simultaneous dumps of overlapping sets of tables, which doesn't
strike me as a great thing.

I'd really like to see us find a way to apply some version of this
patch.  I was in favor of the concept 3 years ago when we did this the
first time, and I've subsequently done quite a bit of work (viz., MVCC
catalog snapshots) to eliminate the main objection that was raised at
that time.  But it's really hard to reason about what might happen
with lowered lock levels, and convince yourself that there's
absolutely nothing that can ever go wrong.  I don't know what to do
about that tension, but I think even modest improvements in this area
stand to benefit an awful lot of users.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Performance Improvement by reducing WAL for Update Operation
Next
From: Pavel Stehule
Date:
Subject: Re: patch: option --if-exists for pg_dump