[Bizgres-general] [ENG] Re: Statement Queuing take II - Resource Scheduling

[Mark Kirkwood]

Mark Kirkwood wrote:
>> My suggestion will be to not add a counter to the named portal *name* (like
>> unnamed_portal_count) at creation time - that will lead to a chain of other
>> problems during the following cursor operations, and extra code to get
>> around it. One idea would be to add a new field to struct PortalData in
>> portal.h that can be your counter/id field. Unnamed portals could be always
>> assigned some default number such as 0 or anything that works for you
>> keeping in mind that there can only be one unnamed portal at a time. Named
>> portals can each have a unique id. It's always possible to iterate through
>> all the currently existing portals by poking at the portal hash table. This
>> is done for almost each function in portalmem.c, see for example
>> AtCommit_Portals().
>>
>>   
>>     
> Great - this is pretty much what I was considering!
>   
>

This works fine - and solves original problem (multiple cursors losing 
proclocks at close), but breaks the lock wakeup :-(.

It is obvious in hindsight - changing the granularity from queue to 
(queue, statement id) means that the wakeup routine also needs to 
change, it must look at waiters on *all* locks for the same queue now... 
I'm investigating this, but I'm unsure if can be made to work sensibly - 
if not I'll need to leave proclocks alone and devise another data 
structure to track (process, queue, statement).

Cheers

Mark