On Fri, May 22, 2020 at 7:48 AM Mike Klaas <mike@superhuman.com> wrote:
> It's my understanding that these locks should be cleared when there are no conflicting transactions. These locks had
existedfor > 1 week and we have no transactions that last more than a few seconds (the oldest transaction in
pg_stat_activityis always < 1minute old).
> Why would a transaction that is finished continue accumulating locks over time?
Predicate locks are released by ClearOldPredicateLocks(), which
releases SERIALIZABLEXACTs once they are no longer interesting. It
has a conservative idea of what is no longer interesting: it waits
until the lowest xmin across active serializable snapshots is >= the
transaction's finishedBefore xid, which was the system's next xid (an
xid that hasn't been used yet*) at the time the SERIALIZABLEXACT
committed. One implication of this scheme is that SERIALIZABLEXACTs
are cleaned up in commit order. If you somehow got into a state where
a few of them were being kept around for a long time, but others
committed later were being cleaned up (which I suppose must be the
case or your system would be complaining about running out of
SERIALIZABLEXACTs), that might imply that there is a rare leak
somewhere in this scheme. In the past I have wondered if there might
be a problem with wraparound in the xid tracking for finished
transactions, but I haven't worked out the details (transaction ID
wraparound is both figuratively and literally the Ground Hog Day of
PostgreSQL bug surfaces).
*Interestingly, it takes an unlocked view of that value, but that
doesn't seem relevant here; it could see a value that's too low, not
too high.
