Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Daniel Farina <daniel(at)heroku(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)
Date: 2012-03-20 16:48:25
Message-ID: 27331.1332262105@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Well, I'm not sure it would save anything meaningful to read the PID
> after releasing the lock even if it were safe, so I'd be inclined to
> keep things simple. But on further reflection I had us using the PID
> to find the target PGPROC in the first place, so we don't need to
> "remember" a value that we already know; that step is simply
> redundant.

I'm confused. If the premise is that PID is untrustworthy as a process
ID, how does searching PGPROC make it more trustworthy? The
hypothetical new owner of the PID could have gotten into PGPROC before
you begin to look.

What would make sense to me is to search PGPROC for some *other*
identifying property (and then set bit, remember PID, unlock, send
signal). But it seems like the key point here is what are we going
to use as an identifying property.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2012-03-20 16:57:01 Re: Regarding column reordering project for GSoc 2012
Previous Message Robert Haas 2012-03-20 16:38:36 Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)