On 11/7/2005 3:40 PM, Christopher Browne wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
On E, 2005-11-07 at 07:29 -0500, Jan Wieck wrote:
On 11/7/2005 4:11 AM, Hannu Krosing wrote:
> On L, 2005-11-05 at 12:48 +0000, Dave Page wrote:
>> It doesn't :-(
>
> What are the issues ?
>
> Is anybody working on it ?
The issue is a change in a backend internal interface function to
LISTEN/NOTIFY, that we use to cleanup stale pg_listener entries after a
postmaster crash. I do have a plan and am working on it. Fixes will be
applied to HEAD and 1_1_STABLE soon.
Would it be worthwhile to change postgresql (too late for 8.1 but
maybe for 8.2 if LISTEN/NOTIFY is not completely rewritten there) by
adding "TRUNACTE PG_LISTENER;" to postgresql's startup code and also
in cleanup after kill -9 initiated restarts ?
That seems overly aggressive, and I'm not sure it would work anyways.
The upcoming problem is that pg_listener won't be tracking PIDs the
same way, and we use the PIDs at present to detect whether a
particular node is "claimed" by a slon process yet.
This isn't entirely accurate.
The current problem is just that the call to Async_Unlisten() lost its
pid argument, so one backend cannot remove stale entries from another
one any more via this call. As a quick workaround we could have done a
DELETE FROM pg_listener ... instead, but since we can already foresee
that we're going to get into trouble with that again as soon as the 8.2
rewrite of LISTEN/NOTIFY removes that relation eventually, I think it is
better to reimplement our interlock together with the underlying
information for terminating all node connections on failover completely
right now.
Jan
Truncating pg_listener is beside the point; the problem is that, in
8.1, we lose the "interlock" where pg_listener is used to have each
node uniquely claim its node.
By 8.2, I don't think we'll be using LISTEN/NOTIFY the way we are at
present...
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
