Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?)
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?) |
| Дата | |
| Msg-id | 20664.1339364270@sss.pgh.pa.us обсуждение |
| Ответ на | Re: unlink for DROPs after releasing locks (was Re: Should I implement DROP INDEX CONCURRENTLY?) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: unlink for DROPs after releasing locks (was Re: Should
I implement DROP INDEX CONCURRENTLY?)
|
| Список | pgsql-hackers |
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.
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера