Re: On-demand running query plans using auto_explain and signals

On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
> 2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr <
> oleksandr(dot)shulgin(at)zalando(dot)de>:
>
>>
>> I have a radical proposal to remove the need for locking: make the
>> CmdStatusSlot struct consist of a mere dsm_handle and move all the required
>> metadata like sender_pid, request_type, etc. into the shared memory segment
>> itself.
>>
>> If we allow the only the requesting process to update the slot (that is
>> the handle value itself) this removes the need for locking between sender
>> and receiver.
>>
>> The sender will walk through the slots looking for a non-zero dsm handle
>> (according to dsm_create() implementation 0 is considered an invalid
>> handle), and if it finds a valid one, it will attach and look inside, to
>> check if it's destined for this process ID. At first that might sound
>> strange, but I would expect 99% of the time that the only valid slot would
>> be for the process that has been just signaled.
>>
>> The sender process will then calculate the response message, update the
>> result_code in the shared memory segment and finally send the message
>> through the queue. If the receiver has since detached we get a detached
>> result code and bail out.
>>
>> Clearing the slot after receiving the message should be the requesting
>> process' responsibility. This way the receiver only writes to the slot and
>> the sender only reads from it.
>>
>> By the way, is it safe to assume atomic read/writes of dsm_handle
>> (uint32)? I would be surprised if not.
>>
>
> I don't see any reason why it should not to work - only few processes will
> wait for data - so lost attach/detach shm operations will not be too much.
>

Please see attached for implementation of this approach. The most
surprising thing is that it actually works :)

One problem still remains with the process requesting information when the
target process exits before it can have a chance to handle the signal. The
requesting process then waits forever, because nobody attaches/detaches the
queue. We've discussed this before and looks like we need to introduce a
timeout parameter to pg_cmdstatus()...

--
Alex