Robert Haas <robertmhaas@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
