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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. );
Date: 2015-04-06 03:53:41
Message-ID: 20150406035341.GB4369@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabrízio de Royes Mello wrote:

> Ok guys. The attached patch refactor the reloptions adding a new field
> "lockmode" in "relopt_gen" struct and a new method to determine the
> required lock level from an option list.
>
> We need determine the appropriate lock level for each reloption:

I don't think AccessShareLock is appropriate for any option change. You
should be using a lock level that's self-conflicting, as a minimum
requirement, to avoid two processes changing the value concurrently. (I
would probably go as far as ensuring that the lock level specified in
the table DoLockModesConflict() with itself in an Assert somewhere.)

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2015-04-06 03:57:36 pg_rewind and log messages
Previous Message Fabrízio de Royes Mello 2015-04-06 03:31:13 Re: [HACKERS] GSoC 2015 proposal: Improve the performance of “ALTER TABLE .. SET LOGGED / UNLOGGED” statement