Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Fujii Masao <masao.fujii@gmail.com>

View thread
From: Fujii Masao <masao.fujii@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael.paquier@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Date: 2013-03-28T13:12:26Z
Lists: pgsql-hackers 
On Thu, Mar 28, 2013 at 10:34 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2013-03-28 10:18:45 +0900, Michael Paquier wrote:
>> On Thu, Mar 28, 2013 at 3:12 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> Since we call relation_open() with lockmode, ISTM that we should also call
>> > relation_close() with the same lockmode instead of NoLock. No?
>> >
>> Agreed on that.
>
> That doesn't really hold true generally, its often sensible to hold the
> lock till the end of the transaction, which is what not specifying a
> lock at close implies.

You're right. Even if we release the lock there, the lock is taken again soon
and hold till the end of the transaction. There is no need to release the lock
there.

Regards,

-- 
Fujii Masao

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Background worker processes

  2. Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.

  3. Work around unportable behavior of malloc(0) and realloc(NULL, 0).

  4. Properly set relpersistence for fake relcache entries.