Re: BUG #9371: pg_dump acquiring ROW EXCLUSIVE locks on tables - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #9371: pg_dump acquiring ROW EXCLUSIVE locks on tables
Date
Msg-id 30660.1394135244@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #9371: pg_dump acquiring ROW EXCLUSIVE locks on tables  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-bugs
Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> Here's a patch for HEAD along those lines.

> I've tested it on our production data and confirmed that with this
> patch pg_dump no longer acquires exclusive locks. I think this should
> be back-patched, since we do promise that pg_dump does not block other
> readers or writers.

I think this patch looks generally sane, and I agree that the excess
locking is a bug worthy of being back-patched.  But is anyone concerned
about changing the signature of AcquireRewriteLocks() in back branches?
I can't immediately think of a reason why extensions might be calling it,
but ...

We could avoid a signature change in back branches by making
AcquireRewriteLocks() into a wrapper around some new function.
But I don't want to do it like that in HEAD, so this would create
a divergence between HEAD and back branches.

I'm inclined to think a signature change is OK.  Objections?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #9398: DELETE refering to a materialized view produces "cannot lock rows in materialized view" error
Next
From: martin@antibodymx.net
Date:
Subject: BUG #9455: Subtracting an IPv6 /64 network() from its broadcast() results in an out of range error