Re: Using ProcSignal to get memory context stats from a running backend

From: Maksim Milyutin <milyutinma(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using ProcSignal to get memory context stats from a running backend
Date: 2017-12-27 10:30:35
Message-ID: d23870b3-87d3-f733-a57a-20d4f82caa16@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27.12.2017 10:44, Craig Ringer wrote:

> On 22 December 2017 at 23:19, Maksim Milyutin <milyutinma(at)gmail(dot)com
> <mailto:milyutinma(at)gmail(dot)com>> wrote:
>
> Noticing the interest in the calling some routines on the remote
> backend through signals, in parallel thread[1] I have proposed the
> possibility to define user defined signal handlers in extensions.
> There is a patch taken from pg_query_state module.
>
> 1.
> https://www.postgresql.org/message-id/3f905f10-cf7a-d4e0-64a1-7fd9b8351592%40gmail.com
> <https://www.postgresql.org/message-id/3f905f10-cf7a-d4e0-64a1-7fd9b8351592%40gmail.com>
>
>
> Haven't read the patch, but the idea seems useful if a bit hairy in
> practice. It'd be done on a "use at your own risk, and if it breaks
> you get to keep the pieces" basis, where no guarantees are made by Pg
> about how and when the function is called so it must be utterly
> defensive. The challenge there being that you can't always learn
> enough about the state of the system without doing things that might
> break it, so lots of things you could do would be fragile.

Yes, I agree with your thesis that the state of the system have to be
checked/rechecked before starting its manipulation in signal handler.
And the responsibility is down to developer of extension to provide the
necessary level of defensive. Perhaps, it makes sense to add try-catch
block around signal handler to interrupt potential errors therefrom.

--
Regards,
Maksim Milyutindefe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2017-12-27 11:07:35 Re: Tracking of page changes for backup purposes. PTRACK [POC]
Previous Message Andres Freund 2017-12-27 10:08:15 Re: Postgres with pthread