From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Fabrízio Mello <fabriziomello(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Date: | 2015-08-04 01:14:00 |
Message-ID: | CAB7nPqQ-wVjUvrgKnL3Om=G-i4hsiUwsP+264duC3fGKW0rTcw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 4, 2015 at 9:12 AM, Fabrízio de Royes Mello
<fabriziomello(at)gmail(dot)com> wrote:
> Are you sure we need to do all this changes just to check the highest
> locklevel based on the reloptions?
Well, by looking at the code that's what it looks as. That's a large
change not that straight-forward.
> Or I misunderstood the whole thing?
No I think we are on the same page.
> Maybe we just check the DoLockModeConflict in the new method
> GetReloptionsLockLevel and if true then fallback to AccessExclusiveLock (as
> Michael suggested in a previous email).
Honestly that's what I would suggest for this patch, and also fix the
existing problem of tablecmds.c that does the same assumption. It
seems saner to me for now than adding a whole new level of routines
and wrappers, and your patch has IMO great value when each ALTER
COMMAND is kicked individually.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-04 01:19:34 | Re: buffer locking fix for lazy_scan_heap |
Previous Message | Robert Haas | 2015-08-04 00:56:27 | Re: max_worker_processes on the standby |