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?)
|
Список | 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 по дате отправления: