Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );

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

In response to

Browse pgsql-hackers by date

  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