Re: Support for REINDEX CONCURRENTLY
От | Michael Paquier |
---|---|
Тема | Re: Support for REINDEX CONCURRENTLY |
Дата | |
Msg-id | CAB7nPqS_o6-x161BQ8tvJ3k6Y6dnY0h66G7UVho8YitH2uD5UA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Support for REINDEX CONCURRENTLY (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sat, Dec 8, 2012 at 2:01 AM, Tom Lane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span>wrote:<br /><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:00 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Um, I don't think you can swap in a new toast indexOID without taking<br /> exclusive lock on the parent table at some point.<br /><br /> One sticking point is the needto update pg_class.reltoastidxid. I<br /> wonder how badly we need that field though --- could we get rid of it<br />and treat toast-table indexes just the same as normal ones? (Whatever<br /> code is looking at the field could perhapsinstead rely on<br /> RelationGetIndexList.)<br /></blockquote>Yes. reltoastidxid refers to the index of the toasttable so it is necessary to take a lock on the parent relation in this case. I haven't thought of that. I also do notreally know how far this is used by the toast process, but just by thinking safety taking a lock on the parent relationwould be better.<br /> For a normal index, locking the parent table is not necessary as we do not need to modifyanything in the parent relation entry in pg_class.<br clear="all" /></div>-- <br />Michael Paquier<br /><a href="http://michael.otacoo.com"target="_blank">http://michael.otacoo.com</a><br />
В списке pgsql-hackers по дате отправления: