On Mon, 8 Apr 2019 at 02:36, David Rowley <david.row...@2ndquadrant.com> wrote: > > LockMethodLocalHash is special in that it predictably goes to empty > > at the end of every transaction, so that de-bloating at that point > > is a workable strategy. I think we'd probably need something more > > robust if we were trying to fix this generally for all hash tables. > > But if we're going to go with the one-off hack approach, we should > > certainly try to keep that hack as simple as possible. > > As cheap as possible sounds good, but I'm confused at why you think > the table will always be empty at the end of transaction. It's my > understanding and I see from debugging that session level locks remain > in there. If I don't copy those into the new table they'll be lost.
Or we could just skip the table recreation if there are no session-levels. That would require calling hash_get_num_entries() on the table again and just recreating the table if there are 0 locks. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
