The slony log trigger saves execution plans, so any given connection
that has been used with a slony schema installed will have cached OIDs
referring to the sl_log_1 table. When you drop the schema, those OIDs
obviously go away. When you re-create the schema, and try to use the old
connection, it s
Thanks!
>-Original Message-
>From: Simon Riggs [mailto:[EMAIL PROTECTED]
>Sent: Friday, May 27, 2005 11:45 AM
>To: David Parker
>Cc: pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] logging sql from JDBC
>
>On Wed, 2005-05-25 at 12:03 -0400, David Parker
e area of the source where this decision gets made, and/or how difficult
it would be to enable this logging?
Thanks!
-
DAP----------David
Parker Tazz Networks (401)
709-5130
Will this make it into 8.1?
>-Original Message-
>From: Tom Lane [mailto:[EMAIL PROTECTED]
>Sent: Thursday, January 27, 2005 7:38 PM
>To: Kenneth Lareau
>Cc: David Parker; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and
&
Yes, thanks very much!
- DAP
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Lareau
>Sent: Thursday, January 27, 2005 8:10 PM
>To: Tom Lane
>Cc: Kenneth Lareau; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Strange issue with initdb on
d n o t ".., 30)
= 30
/home/dparkerwrite(2, " / h o m e / d p a r k e".., 13) = 13
": write(2, " " : ", 3)= 3
Operation not applicablewrite(2, " O p e r a t i o n n o".., 24)
= 24
- DAP
>-Original Message-
>Fro
Coincidentally I JUST NOW built 8.0 on Solaris 9, and ran into the same
problem. As they say, "this used to work".
We build databases as part of the build of our product, and I'm looking
into what we need to do to upgrade from 7.4.5, and this was the first
thing I ran into. I hadn't gotten as
me line IS handy, however
- DAP
>-Original Message-
>From: Bruce Momjian [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, December 01, 2004 11:18 AM
>To: Simon Riggs
>Cc: David Parker; [EMAIL PROTECTED]
>Subject: Re: [HACKERS] Increasing the length of
>
>Simon Rig
I've been using "log_min_duration_statement = 0" to get durations on all
SQL statements for the purposes of performance tuning, because this logs
the duration on the same line as the statement. My reading of this TODO
is that now log_min_duration_statement = 0 would give me the statements
but no to
I am not currently working on z/OS, and don't have access to a z/OS
environment, but I did a little work with getting OpenLDAP ported to
z/OS at my previous company. I assume you mean Unix System Services
(USS) under z/OS, rather than zLinux. Since zLinux is essentially Suse
ported to the Z archite
10 matches
Mail list logo