On Wed, Feb 13, 2019 at 6:05 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@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. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
