Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Date
Msg-id CA+TgmoYtU0F_twcy9ZzcY4kAuzETontzMxn1Hncfbd-27G3QJw@mail.gmail.com
Whole thread Raw
In response to Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
List pgsql-hackers
On Sun, Jun 10, 2012 at 5:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Jun 10, 2012 at 4:19 PM, Noah Misch <noah@leadboat.com> wrote:
>>> Agreed.  We now have $OLD_SUBJECT, but this is a win independently.  I have
>>> reviewed the code that runs between the old and new call sites, and I did not
>>> identify a hazard of moving it as you describe.
>
>> I looked at this when we last discussed it and didn't see a problem
>> either, so I tend to agree that we ought to go ahead and do this,
>
> +1, as long as you mean in 9.3 not 9.2.  I don't see any risk either,
> but the time for taking new risks in 9.2 is past.
>
> Noah, please add this patch to the upcoming CF, if you didn't already.

I re-reviewed this and committed it.

Is RESOURCE_RELEASE_AFTER_LOCKS actually used for anything?  Is it
just for extensions?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Next
From: Robert Haas
Date:
Subject: Re: Backup docs