Re: advance local xmin more aggressively
От | Robert Haas |
---|---|
Тема | Re: advance local xmin more aggressively |
Дата | |
Msg-id | CA+TgmoZscKbs32pBQAny5DO+nOiv1zgVwmOVQQCLpF2+x+DbVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: advance local xmin more aggressively (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: advance local xmin more aggressively
(Heikki Linnakangas <hlinnakangas@vmware.com>)
|
Список | pgsql-hackers |
On Mon, Dec 8, 2014 at 9:31 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Dec 8, 2014 at 4:56 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> I don't immediately see the problem either, but I have to say that >> grovelling through all the resource owners seems ugly anyway. Resource >> owners are not meant to be traversed like that. And there could be a lot of >> them, and you have to visit every one of them. That could get expensive if >> there are a lot of resource owners. > > 1. I don't really see why resource owners shouldn't be traversed like > that. They are clearly intended to form a hierarchy, and there's > existing code that recurses through the hierarchy from a given level > downward. What's ugly about that? Here's a patch. I looked at the issue of tracking parent-less resource owners a bit more closely. It turns out that resource owners are always created in TopMemoryContext "since they should only be freed explicitly" (cf. resowner.c). I was a bit worried about that, because it would be bad to keep a list of all parent-less resource owners if list elements could vanish in a context reset. But that doesn't seem to be a concern. So I stole the nextchild links of parent-less resource owners, which are not used for anything currently, to keep a list of such resource owners. It occurred to me that there's probably not much value in recomputing xmin when the active snapshot stack is non-empty. It's not impossible that a PL/pgsql function could close a cursor with an old xmin and then do lots of other work (or just sleep for a long time) before returning to the top-level, but it is pretty unlikely. So the attached patch only considers recomputing the advertised xmin when the active snapshot stack is empty. That'll happen at the end of each statement, which seems soon enough. Upthread, I suggested keeping a tally of the number of snapshots with the advertised xmin and recomputing the xmin to advertise only when it reaches 0. This patch doesn't implementation that optimization, but it does have code that aborts the traversal of the resource owner hierarchy as soon as we see an xmin that will preclude advancing our advertised xmin. Releasing N resource owners could therefore cost O(N^2) in the worst case, but note that releasing N resource owners is *already* an O(N^2) operation in the worst case, because the list of children of a particular parent resource owner is singly linked, and thus deleting a resource owner is O(N). It's been that way for an awfully long time without anyone complaining, probably because (a) it's not particularly common to have large numbers of cursors open simultaneously and (b) even if you do have that, the constant factor is pretty low. Following Heikki's previous suggestion, the patch contains checks to make sure that we find exactly the number of registered snapshots that we expect to find. We could consider demoting these to asserts or something, but this is more likely to catch bugs if there are any. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: