Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-04 Thread Michael Paquier
On Wed, Aug 5, 2015 at 11:47 AM, Noah Misch wrote: > On Tue, Aug 04, 2015 at 07:35:43AM +0100, Simon Riggs wrote: >> On 4 August 2015 at 05:56, Michael Paquier wrote: >> > The thing is that, as mentioned by Alvaro and Andres on this thread, >> > we have no guarantee that the different relation lo

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-04 Thread Noah Misch
On Tue, Aug 04, 2015 at 07:35:43AM +0100, Simon Riggs wrote: > On 4 August 2015 at 05:56, Michael Paquier wrote: > > The thing is that, as mentioned by Alvaro and Andres on this thread, > > we have no guarantee that the different relation locks compared have a > > monotone hierarchy and we may fin

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-04 Thread Michael Paquier
On Wed, Aug 5, 2015 at 3:05 AM, Robert Haas wrote: > On Tue, Aug 4, 2015 at 2:41 AM, Michael Paquier > wrote: >> Yep, true as things stand now. But this would get broken if we add a >> new lock level between ShareRowExclusiveLock and AccessExclusiveLock >> that does not respect the current monoto

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-04 Thread Michael Paquier
On Wed, Aug 5, 2015 at 2:23 AM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Tue, Aug 4, 2015 at 2:43 PM, Alvaro Herrera wrote: >> Now, let's take for example this case with locks A, B, C, D: >> - Lock A conflicts with ACD >> - B with BCD >> - C with itself >> - D with itself >> What would

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-04 Thread Robert Haas
On Tue, Aug 4, 2015 at 2:41 AM, Michael Paquier wrote: > Yep, true as things stand now. But this would get broken if we add a > new lock level between ShareRowExclusiveLock and AccessExclusiveLock > that does not respect the current monotone hierarchy between those. But we're probably not going t

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-04 Thread Alvaro Herrera
Michael Paquier wrote: > On Tue, Aug 4, 2015 at 2:43 PM, Alvaro Herrera > wrote: > > Maybe the solution to this is to add the concept of "addition" of two > > lock modes, where the result is another lock mode that conflicts with > > any lock that would conflict with either of the two operand loc

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-03 Thread Michael Paquier
On Tue, Aug 4, 2015 at 3:35 PM, Simon Riggs wrote: > Please provide the link to the discussion of this. I don't see a problem > here right now that can't be solved by saying Thread: http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com Particular

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-03 Thread Simon Riggs
On 4 August 2015 at 05:56, Michael Paquier wrote: > Hi all, > > As mentioned in the thread related to lowering locks of autovacuum > reloptions in ALTER TABLE SET > ( > http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com > ), > I have noticed th

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-03 Thread Michael Paquier
On Tue, Aug 4, 2015 at 2:43 PM, Alvaro Herrera wrote: > Michael Paquier wrote: > >> As mentioned in the thread related to lowering locks of autovacuum >> reloptions in ALTER TABLE SET >> (http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com), >> I

Re: [HACKERS] tablecmds.c and lock hierarchy

2015-08-03 Thread Alvaro Herrera
Michael Paquier wrote: > As mentioned in the thread related to lowering locks of autovacuum > reloptions in ALTER TABLE SET > (http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com), > I have noticed the following code in > AlterTableGetLockLevel@t

[HACKERS] tablecmds.c and lock hierarchy

2015-08-03 Thread Michael Paquier
Hi all, As mentioned in the thread related to lowering locks of autovacuum reloptions in ALTER TABLE SET (http://www.postgresql.org/message-id/cafcns+ox7jvenc_3i54fdq3ibmogmknc2tmevdsmvojbsxg...@mail.gmail.com), I have noticed the following code in AlterTableGetLockLevel@tablecmds.c: