Robert Haas <robertmh...@gmail.com> wrote: > While taking a look at the existing documentation for pg_locks I > came across the following paragraph: > > <para> > When the <structname>pg_locks</structname> view is accessed, > the internal lock manager data structures are momentarily > locked, and a copy is made for the view to display. This > ensures that the view produces a consistent set of results, > while not blocking normal lock manager operations longer than > necessary. Nonetheless there could be some impact on database > performance if this view is frequently accessed. > </para> > > AFAICS, this is no longer quite true. The view of the data from > the main lock manager will be self-consistent, and the view of the > data from the predicate lock manager will be self-consistent, but > they need not be consistent with each other. I don't think that's > a problem we need to fix, but we probably ought to make the > documentation match the behavior. It remains true that the heavyweight locking structures are momentarily locked to capture a consistent view of those, and it is also true that the predicate locking structures are momentarily locked to get a consistent view of that data. Both are not covered by some over-arching lock, but that's true at *all* times -- SIReadLock entries can disappear mid-transaction (for READ ONLY transactions) and can persist past transaction completion (if there are overlapping transactions with which the completed transaction can still form a dangerous structure). So there is never a very close tie between the timing of the appearance or disappearance for SIRead locks versus any heavyweight locks. That is covered to some degree in the section on serializable transactions: http://developer.postgresql.org/pgdocs/postgres/transaction-iso.html#XACT-SERIALIZABLE Any thoughts on what else the docs need to be more clear? -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
