Magnus Hagander <magnus@hagander.net> writes: > And while at it, what would in this particular case have been even more > useful to the OP would be to actually identify that there is a temp table > *and which xid it's blocking at*. For regular transactions we can look at > backend_xid, but IIRC that doesn't work for temp tables (unless they are > inside a transaction). Maybe we can find a way to expose that type of > relevant information at a similar level while poking around that code?
Maybe I'm confused, but doesn't the table's pg_class row tell you what you need to know? You can't look inside another session's temp table, but you don't need to.
I believe it does, yes.
But that doesn't make for a way to conveniently go "what is it that's causing waparound problems", since due to pg_class being per database, you have to loop over all your databases to find that query. Having that information available in a way that's easy for monitoring to get at (much as the backend_xid field in pg_stat_activity can help you wrt general snapshots) would be useful.
