On Tue, Feb 15, 2005 at 02:00:20PM -0500, Christopher Browne wrote:
> As has been noted by others, this is an artifact of the JDBC driver
> holding onto a stored query plan. And it's somewhat worth noting that
> this is not unique to Slony-I...
(Yes, I'm behind on reading mail lists.)
Actually,
In an attempt to throw the authorities off his trail, [EMAIL PROTECTED] (John
Sidney-Woollett) transmitted:
> MAKE SURE YOU STOP YOUR APPLICATION RUNNING AGAINST YOUR MASTER
> DATABASE WHEN REMOVING THE WHOLE SLONY CLUSTER, or at least re-cycle
> all your open connections after the event!
>
> The
It doesn't make sense to me either. The error was always for the same OID.
Like you I assumed that removing slony would not cause any problems to a
running app.
Hopefully someone more involved in Slony will be able to explain why my
pl/pgsql functions all got broken after uninstalling slony, eve
n Sidney-Woollett
>Sent: Tuesday, February 15, 2005 7:03 AM
>To: Richard Huxton
>Cc: postgres general; [EMAIL PROTECTED]
>Subject: [Slony1-general] Re: [GENERAL] Slony uninstall info/warning
>
>Thanks for the info, Richard.
>
>I didn't think that it was a slony issue per se
Richard Huxton wrote:
> Hmm - not sure you could do this without a savepoint to catch the
> error.
> However, it might be possible to add track dependencies with the
> function (as with views). Then you'd have to issue a CASCADE to alter
> the table.
If you use Oracle and drop and recreate a table
Hi all,
It's just marginally relevant to the issue at hand: in our code we drop
the connection on any error we cannot map to an expected condition. This
would eventually recycle all connections on such unexpected problems
after just one error per connection. Of course if the error surfaces as
a co
John Sidney-Woollett wrote:
Thanks for the info, Richard.
I didn't think that it was a slony issue per se, but that a note should
be added to the slony docs warning to recycle connections after making
substantive changes to the schema.
You're right, we use both (java) prepared statements and pl/
Thanks for the info, Richard.
I didn't think that it was a slony issue per se, but that a note should
be added to the slony docs warning to recycle connections after making
substantive changes to the schema.
You're right, we use both (java) prepared statements and pl/pgsql functions.
The data lo
John Sidney-Woollett wrote:
Hopefully this will prevent data loss or problems for others using slony
1.0.5 and pg 7.4.6...
We just got bitten by something we didn't foresee when completely
uninstalling a slony replication cluster from the master and slave...
MAKE SURE YOU STOP YOUR APPLICATION
Hopefully this will prevent data loss or problems for others using slony
1.0.5 and pg 7.4.6...
We just got bitten by something we didn't foresee when completely
uninstalling a slony replication cluster from the master and slave...
MAKE SURE YOU STOP YOUR APPLICATION RUNNING AGAINST YOUR MASTER
10 matches
Mail list logo
