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 perspective
On Wed, Dec 5, 2012 at 7:08 AM, Filip Rembiałkowski
filip.rembialkow...@gmail.com 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
On 2012-12-05 17:05:41 -0500, Robert Haas wrote:
On Wed, Dec 5, 2012 at 7:08 AM, Filip Rembiałkowski
filip.rembialkow...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 5, 2012 at 7:08 AM, Filip RembiaÅkowski
filip.rembialkow...@gmail.com 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
On Thu, Nov 8, 2012 at 3:45 AM, Filip Rembiałkowski
filip.rembialkow...@gmail.com 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
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
