Robert Haas writes:
> On Wed, Dec 5, 2012 at 7:08 AM, Filip RembiaÅkowski
> wrote:
>> 3. I made a naive test of simply changing AccessExclusiveLock to
>> ExclusiveLock, and seeing how many regression tests it breaks. It
>> breaks none :-)
> Sure. You could probably downgrade it quite a bit fur
On 2012-12-05 17:05:41 -0500, Robert Haas wrote:
> On Wed, Dec 5, 2012 at 7:08 AM, Filip Rembiałkowski
> wrote:
> > Robert, thank you for the answer.
> >
> > 1. "need exclusive lock anyway to add triggers".
> > Why adding a trigger needs exclusive lock?
> > Someone would say blocking reads is not
On Wed, Dec 5, 2012 at 7:08 AM, Filip Rembiałkowski
wrote:
> Robert, thank you for the answer.
>
> 1. "need exclusive lock anyway to add triggers".
> Why adding a trigger needs exclusive lock?
> Someone would say blocking reads is not needed (since possible trigger
> events are: Insert/Update/Del
Robert, thank you for the answer.
1. "need exclusive lock anyway to add triggers".
Why adding a trigger needs exclusive lock?
Someone would say blocking reads is not needed (since possible trigger
events are: Insert/Update/Delete/Truncate).
2. "will create a risk of deadlock".
From user perspect
On Thu, Nov 8, 2012 at 3:45 AM, Filip Rembiałkowski
wrote:
> maybe this is a better group for this question?
>
> I can't see why creating foreign key on table A referencing table B,
> generates an AccessExclusiveLock on B.
> It seems (to a layman :-) ) that only writes to B should be blocked.
>
>
Hi,
maybe this is a better group for this question?
I can't see why creating foreign key on table A referencing table B,
generates an AccessExclusiveLock on B.
It seems (to a layman :-) ) that only writes to B should be blocked.
I'm really interested if this is either expected effect or any open
