Re: advance local xmin more aggressively

On 12/10/2014 08:35 PM, Robert Haas wrote:
> On Wed, Dec 10, 2014 at 12:57 PM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> Clever. Could we use that method in ResourceOwnerReleaseInternal and
>> ResourceOwnerDelete, too? Might be best to have a
>> ResourceOwnerWalk(resowner, callback) function for walking all resource
>> owners in a tree, instead of one for walking the snapshots in them.
>
> Sure. It would be a little more complicated there since you want to
> stop when you get back to the starting point, but not too bad. But is
> that solving any actual problem?

I thought that a transaction commit or abort in some special
circumstances might call ResourceOwnerReleaseInternal on the top level,
but I can't make it happen. The machinery in xact.c is too clever, and
always releases the resource owners from the bottom up. And I can't find
a way to create a deep resource owner tree in any other way. So I guess
it's fine as it is.

MemoryContextCheck and MemoryContextPrint also recurse, however.
MemoryContextCheck is only enabled with --enable-cassert, but
MemoryContextPrint is called when you run out of memory. That could turn
a plain "out of memory" error into a stack overrun, triggering a server
crash and restart.

>> It occurs to me that the pairing heap I just posted in another thread
>> (http://www.postgresql.org/message-id/54886BB8.9040000@vmware.com) would be
>> a good fit for this. It's extremely cheap to insert to and to find the
>> minimum item (O(1)), and the delete operation is O(log N), amortized. I
>> didn't implement a delete operation, for removing a particular node, I only
>> did delete-min, but it's basically the same code. Using a pairing heap for
>> this might be overkill, but if we have that implementation anyway, the code
>> in snapmgr.c to use it would be very simple, so I see little reason not to.
>> It might even be simpler than your patch, because you wouldn't need to have
>> the heuristics on whether to attempt updating the xmin; it would be cheap
>> enough to always try it.
>
> Care to code it up?

Here you are.

- Heikki