Horton
Menu

Re: Support for REINDEX CONCURRENTLY

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Fujii Masao <masao.fujii@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-28T01:34:06Z
Lists: pgsql-hackers 
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.

Greetings,

Andres Freund

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.