Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Are we somehow not going through ExecOpenIndices? > >> I dunno. I just did a quick black-box test: >> >> [ begin; insert; without commit ] >> >> No foo_pkey anywhere. > > That proves nothing, as we don't keep such locks after the query > (and there's no reason to AFAICS). See ExecCloseIndices.
OK. I had seen that no locks were held after the insert and wasn't aware that we acquired and then released them for each insert within a transaction. On the other hand, we acquire locks on all indexes even for a HOT UPDATE which uses a seqscan, and hold those until end of transaction. Is there a reason for that? I suppose that since a concurrent refresh is very likely to lock all these indexes with RowExclusiveLock anyway, as a result of the DELETE, UPDATE and INSERT statements subsequently issued through SPI, I might was well acquire that lock when I look at the definition, and not release it -- so that the subsequent locks are local to the backend, and therefore faster. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
