Re: Get memory contexts of an arbitrary backend process

On 2020-10-28 15:32, torikoshia wrote:
> On 2020-10-23 13:46, Kyotaro Horiguchi wrote:

>> I think we might need to step-back to basic design of this feature
>> since this patch seems to have unhandled corner cases that are
>> difficult to find.

I've written out the basic design below and attached
corresponding patch.

   # Communication flow between the dumper and the requester
   - (1) When REQUESTING memory context dumping, the dumper adds an entry 
to the shared memory. The entry manages the dump state and it is set to 
'REQUESTING'.
   - (2) The dumper sends the signal to the dumper and wait on the latch.
   - (3) The dumper looks into the corresponding shared memory entry and 
changes its state to 'DUMPING'.
   - (4) When the dumper completes dumping, it changes the state to 
'DONE' and set the latch.
   - (5) The dumper reads the dump file and shows it to the user. 
Finally, the dumper removes the dump file and reset the shared memory 
entry.

   # Query cancellation
   - When the requestor cancels dumping, e.g. signaling using ctrl-C, the 
requestor changes the status of the shared memory entry to 'CANCELING'.
   - The dumper checks the status when it tries to change the state to 
'DONE' at (4), and if the state is 'CANCELING', it removes the dump file 
and reset the shared memory entry.

   # Cleanup dump file and the shared memory entry
   - In the normal case, the dumper removes the dump file and resets the 
shared memory entry as described in (5).
   - When something like query cancellation or process termination 
happens on the dumper after (1) and before (3), in other words, the 
state is 'REQUESTING', the requestor does the cleanup.
   - When something happens on the dumper or the requestor after (3) and 
before (4), in other words, the state is 'DUMPING', the dumper does the 
cleanup. Specifically, if the requestor cancels the query, it just 
changes the state to 'CANCELING' and the dumper notices it and cleans up 
things later. OTOH, when the dumper fails to dump, it cleans up the dump 
file and deletes the entry on the shared memory.
   - When something happens on the requestor after (4), i.e., the state 
is 'DONE', the requestor does the cleanup.
   - In the case of receiving SIGKILL or power failure, all dump files 
are removed in the crash recovery process.


Although there was a suggestion that shared memory hash
table should be changed to more efficient structures,
I haven't done it in this patch.
I think it can be treated separately, I'm going to work
on that later.


On 2020-11-11 00:07, Georgios Kokolatos wrote:
> Hi,
> 
> I noticed that this patch fails on the cfbot.
> For this, I changed the status to: 'Waiting on Author'.
> 
> Cheers,
> //Georgios
> 
> The new status of this patch is: Waiting on Author

Thanks for your notification and updated the patch.
Changed the status to: 'Waiting on Author'.

Regards,

--
Atsushi Torikoshi