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 />