Minor tweaks to docs
Merge branch 'master' of ssh://git.postgresql.org/slony1-engine
Bug #281 - improve documentation on performance implications of PATHs

Add in material describing the effects of having fully versus less-fully connected path networks
Only include the libpq header directory OR the server header directory but not both

This addresses bug 315 where a debian install had libpq-dev 9.3 installed
and postgresql-server-dev 8.4 installed.  The libpq headers are in /usr/include/postgresql
but the server headers are in /usr/lib/postgresql/8.4/server.

configure checks were failing because we were pulling in a mixutre of headers
from both versions.  The only slony component that needs the server
headers are the backend functions and they shouldn't need to use libpq headers.

This patch sets CPPFLAGS as approriate for one or the other but not both
Note that upgrade process implies an application outage
The UPDATE FUNCTIONS upgrade from a 2.1.x (or 2.0.x) Slony to 2.2.0 does not
create the no_failed column in sl_node.
Fix for endless restart loop on FAILOVER (bug 318).

If the backup node is not the most advanced, function
failedNode() will trigger a slon restart even if it
did not make any changes to the configuration because
of a missing WHERE clause.
adding in tests for bug 318
Fix for bug 319, dereferencing of NULL pointers.

The "provider" pointer at that point in the code is
always NULL due to the for() loop above. The query can
only fail if the connection to the backend is lost in
that very moment.
bug 322 allow CLONE PREPARE processing to deal with an earlier STORE PATH

If a node sees a STORE PATH  event before it sees the CLONE PREPARE
that creates a node involved in that path then the CLONE PREPARE
event was failing because the node was already in sl_node.

Check for the existance for rows and update them instead

Conflicts:
	src/slon/remote_worker.c
Additional changes for bug322.

cloneNodePrepare() and many other places need to grab
the central config lock. They heavily rely on checking
things via "not found", which inherently has a race
condition.

Conflicts:
	src/slon/remote_worker.c
note: removed src/slon/remote_worker.c changes from
the cherry-picked patch they aren't actually part of 322
From fccfb06687588c6155f0f77665be358837dd47e1 Mon Sep 17 00:00:00 2001
From: Steve Singer <ssinger@ca.afilias.info>
Date: Thu, 24 Oct 2013 21:29:32 -0400
Subject: [PATCH] fixing the failover unit test.

It is sometimes possible for node 4 to get unsubscribed from
set 1 because it doesn't have a subscription to set 2 but
might be the farthest ahead node (but it isn't a failover candidate)

Resubscribed node 4 before continuing on with the next test
Disable the "not expect lag" check from disorder ExecuteScript.
"Apparent" lag of 10 seconds can happen, the way confirm
messages propagate back to the origin.
add a regression test for EXECUTE SCRIPT using a non-provider event node
bug 321 - Stop reconnecting to providers

Event origins that are not set origins will have
multiple  li_origin/li_receiver pairs in sl_listen
we listen for events from these origins from multiple
sources.   This means a node such as node 2 might
receive an event from ev_origin=1 via event provider 1
then receive the next event with ev_origin=1 from
event provider 2.  Slon keeps connecting and
disconnecting from these providers.

Instead keep of dropping the connections to
event providers we keep them around unless
a reconfiguration has taken place.  This lets
us use the connection for the event_provider
we received the event from.
bug 321 - fix to the previous patch for when we have multiple real providers

If the provider list contains multiple providers that actually provide
a set (set_head != NULL) then we want to use those providers and
not skip them
Folding slon.stop() and coordinator.join(slon) into one loop.

Stopping the slons and joining their processes in separate
loops apparently can cause the regression test to hang under
some rare race conditions.
Disable the "known failing" disorder tests.
Merge branch 'master' of ssh://git.postgresql.org/slony1-engine