Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> 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...
>
> ...but they could be, if we were so inclined.
Yes.
> What we actually do is acquire all of the lock manager locks,
> snapshot the state, release those locks, then get the predicate
> lock manager locks and SerializableXactHashLock, snapshot the
> state over there, release those locks, and then dump everything
> out. Since we don't do that, it's possible that "select * from
> pg_locks" could see a state that never really existed.
>
> For example, it's possible that, after doing GetLockStatusData()
> but before doing GetPredicateLockStatusData(), some backend might
> commit a transaction, releasing a heavyweight lock, begin a new
> transaction, and acquire a predicate lock. Now, the backend
> looking at the lock table is going to see both of those locks held
> at the same time even though in reality that never happened.
That's a fair point.
> What I think we should do is replace the existing paragraph with
> something along these lines:
>
> The <structname>pg_locks<structname> view displays data from both
> the regular lock manager and the predicate lock manager, which are
> separate systems. When this view is accessed, the internal data
> structures of each lock manager are momentarily locked, and copies
> are made for the view to display. Each lock manager will
> therefore produce a consistent set of results, but as we do not
> lock both lock managers simultaneously, it is possible for locks
> to be taken or released after we interrogate the regular lock
> manager and before we interrogate the predicate lock manager.
> Each lock manager is only locked for the minimum possible time so
> as to reduce the performance impact of querying this view, but
> there could nevertheless be some impact on database performance if
> it is frequently accessed.
I agree that it's probably better to document it than to increase
the time that both systems are locked. If we get complaints about
it, we can always revisit the issue in a later release.
The above wording looks fine to me.
-Kevin