Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
Дата
Msg-id CA+TgmoYtU0F_twcy9ZzcY4kAuzETontzMxn1Hncfbd-27G3QJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: WIP patch for Todo Item : Provide fallback_application_name in contrib/pgbench, oid2name, and dblink
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Backup docs