Обсуждение: remembering locks and dynahash.c

Currently the resource owner does not remember what locks it holds.
When a resource owner wants to release its locks or reassign them to
its parent, it just digs through the backends entire
LockMethodLocalHash table.  When that table is very large, but the
current owner owns only a small fraction of them, this leads to
performance problems.  The only place I know of where this happens is
pg_dump.

I am working on making resource owner remember a limited number of
locks, so it can reassign them more efficiently.

Currently I'm having resowner.c remember the LOCALLOCKTAG, because I
thought that that was the only handle I could use.  But now I'm
wondering if I should remember the LOCALLOCK * instead.  I don't see
any instructions in dynahash about how long a pointer is valid for,
and looking through the code it seems like it should be valid until
the entry is removed or the hash table is destroyed.  Even across a
table expansion I think the pointers stay put, it i just the
dynahash-private pointers to those pointers that change.

So, any advice on whether it is possible, or advisable, to remember
the LOCALLOCK * rather than the LOCALLOCKTAG?

Cheers,

Jeff

Jeff Janes <jeff.janes@gmail.com> writes:
> I am working on making resource owner remember a limited number of
> locks, so it can reassign them more efficiently.

Check, per previous discussion.

> Currently I'm having resowner.c remember the LOCALLOCKTAG, because I
> thought that that was the only handle I could use.  But now I'm
> wondering if I should remember the LOCALLOCK * instead.

I was envisioning LOCALLOCK *.  dynahash will never move an existing
entry, and if the entry can be deleted while the resowner still holds a
pointer to it then you've got a logic bug.
        regards, tom lane