Re: Temporary tables versus wraparound... again - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Temporary tables versus wraparound... again
Date
Msg-id CAM-w4HNyZYKDWjd9DSbiqwpmg-g8Lqv6VdGC3b3r9ivSYdFYgw@mail.gmail.com
Whole thread Raw
In response to Re: Temporary tables versus wraparound... again  (Greg Stark <stark@mit.edu>)
Responses Re: Temporary tables versus wraparound... again
List pgsql-hackers
Hm, in an optimized build using kernel perf I see this. But I don't
know how to find what the call sites are for LWLockAcquire/Release. If
it's the locks on pgproc that would be kind of bad.

I wonder if I should be gathering horizons once in the
PrecommitActions and then just using those for every temp table
somehow. Perhaps only actually doing an update if the relfrozenxid is
actually at least vacuum_freeze_table_age old.

   3.98%  postgres     LWLockAcquire
   3.51%  postgres     LWLockRelease
   3.18%  postgres     hash_search_with_hash_value
   2.20%  postgres     DropRelationLocalBuffers
   1.80%  [kernel]     check_preemption_disabled
   1.52%  postgres     hash_bytes
   1.27%  postgres     LockAcquireExtended
   0.97%  postgres     _bt_compare
   0.95%  [kernel]     kmem_cache_alloc

I still think we should be applying the vacuum warning messages to
stable and probably backpatching. I've actually heard from other users
who have faced the same surprise wraparound shutdown.



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Compression dictionaries for JSONB
Next
From: Robert Haas
Date:
Subject: constants for tar header offsets