On Wed, 2010-09-29 at 21:57 -0500, Karl Denninger wrote:
> That's actually ok - the update itself is a legitimate statement on the
> master, posted to that table on a reply, and is part of a transaction.
Even if it's part of a transaction, you still have a race condition,
unless you're using a serializable transcation isolation level.
> I thought logshipping like this over TCP would present the actual WAL
> changes (e.g. page changes) and was quite surprised when I saw what look
> very much like actual statements in the logfile. A process status also
> shows no postgres processes.
9.0-style replication only ships WAL. Those UPDATE statements are _not_
coming from the 9.0-style log shipping replication.
> All of the real application connections are on a machine 1200 miles away
> and behind pgpool, so if there WAS a connection it would be persistent.
> It's not there (never mind that the clients don't have an entry in
> pg_hba that would work, nor could they cross the firewall since there is
> no port forwarding in the firewall to allow it.)
>
Aha, you're using pgpool. The statements are probably coming from there
-- it's got a lot of options and it may be misconfigured.
Turn on some extended logging information that includes the client IP
address. That will probably give you some better insight.
Regards,
Jeff Davis