From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #9371: pg_dump acquiring ROW EXCLUSIVE locks on tables |
Date: | 2014-03-06 19:47:24 |
Message-ID: | 30660.1394135244@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | dylan-pgsql | 2014-03-06 21:18:36 | BUG #9457: replace materialized view? |
Previous Message | martin | 2014-03-06 19:04:53 | BUG #9455: Subtracting an IPv6 /64 network() from its broadcast() results in an out of range error |