paul cannon wrote:
> So I guess the slony stored procedures were being cached or something,
> or updates do not become visible in parallel connections? That's an area
> of postgres about which I know very little.
>
> All in all, it may be a good idea for people upgrading to slony to
> reconnect any applications which submit data
That absolutely makes sense; it is common for some classes of
applications (I *know* it to be true for JDBC-based ones; can't speak
definitively beyond that) to cache query plans, and we've seen this
"bite" us in the evidently similar-enough context of where you drop out
replication.

There's a FAQ entry on the case we'd seen:
<http://linuxfinances.info/info/faq.html#AEN45582>

The issue isn't particularly a Slony-I one; it would affect any scenario
of changing stored procedures/triggers.

It's on the ToDo list:  <http://www.postgresql.org/docs/faqs.TODO.html>

Add RESET CONNECTION command to reset all session state

This would include resetting of all variables (RESET ALL), dropping of
temporary tables, removing any NOTIFYs, cursors, open transactions,
prepared queries, currval()s, etc. This could be used for connection
pooling. We could also change RESET ALL to have this functionality. The
difficult of this features is allowing RESET ALL to not affect changes
made by the interface driver for its internal use. One idea is for this
to be a protocol-only feature. Another approach is to notify the
protocol when a RESET CONNECTION command is used.
http://archives.postgresql.org/pgsql-patches/2006-04/msg00192.php


I will make note in the documentation that this can happen...

I'm *very* pleased that restarting the apps cleared that up for you;
thanks very much for tracking that down.