On 2006.08.31 at 00:09:56 +0200, Peter Eisentraut wrote:
Victor B. Wagner wrote:
First one is useful if for some reason some ciphers supported by
OpenSSL is not permitted to use in the particular network, or if
there is need to use ciphersuites which are not included into default
Peter Eisentraut wrote:
Victor B. Wagner wrote:
First one is useful if for some reason some ciphers supported by
OpenSSL is not permitted to use in the particular network, or if
there is need to use ciphersuites which are not included into default
ciphersuite list, now compiled into PostgreSQL.
Victor B. Wagner [EMAIL PROTECTED] writes:
One example which can be tested with stock OpenSSL without national
cryptography modules is - usage of NULL ciphers. They are not enabled by
default, but use of them provides cryptographically strong
authentication with client certificates and data
On 2006.08.31 at 08:52:08 +0100, Gregory Stark wrote:
Victor B. Wagner [EMAIL PROTECTED] writes:
One example which can be tested with stock OpenSSL without national
cryptography modules is - usage of NULL ciphers. They are not enabled by
default, but use of them provides
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out. What is all the stuff about
handling multiple base rels?
Am Donnerstag, 31. August 2006 11:29 schrieb Stefan Kaltenbrunner:
this is btw. something that is available in most daemons utilizing
openssl - one can disable weak ciphers (which might not even be known as
weak at the time the defaults where set) or ciphers not authorized for
certain usage
On 2006.08.31 at 10:34:02 +0200, Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 11:29 schrieb Stefan Kaltenbrunner:
this is btw. something that is available in most daemons utilizing
openssl - one can disable weak ciphers (which might not even be known as
weak at the time the
Huh, it's a over-optimization by icc on Itanium. With -00 or -02 there is no any
problem, only -O2 produces such effect. The problem is in code at lines 125-172
in ginutils.c:
static bool needUnique = false;
int cmpFunc(...) {
...
if (...) needUnique = true;
...
}
...
--On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a
With time, it becomes ever clearer to me that prepared SQL statements are just
a really bad idea. On some days, it seems like half the performance problems
in PostgreSQL-using systems are because a bad plan was cached somewhere. I'd
say, in the majority of cases the time you save parsing and
On Thu, Aug 31, 2006 at 01:56:29PM +0200, Peter Eisentraut wrote:
With time, it becomes ever clearer to me that prepared SQL statements are
just
a really bad idea. On some days, it seems like half the performance problems
in PostgreSQL-using systems are because a bad plan was cached
- Redefine prepared to mean parsed rather than parsed and planned.
How about prepared means really prepared... in the sense of parsed,
analyzed all sensible plans, and save a meta-plan which based on current
statistics and parameter values chooses one of the considered (and
cached) plans ?
That
Peter Eisentraut wrote:
With time, it becomes ever clearer to me that prepared SQL statements are just
a really bad idea. On some days, it seems like half the performance problems
in PostgreSQL-using systems are because a bad plan was cached somewhere. I'd
say, in the majority of cases the
Am Donnerstag, 31. August 2006 14:11 schrieb Csaba Nagy:
How about prepared means really prepared... in the sense of parsed,
analyzed all sensible plans, and save a meta-plan which based on current
statistics and parameter values chooses one of the considered (and
cached) plans ?
I don't
Simple illustration:
#include stdio.h
#include stdlib.h
static char SI = 0;
static int
cmp(const void *a, const void *b) {
puts(CALL cmp);
if ( *(int*)a == *(int*)b ) {
puts(SET SI = 1);
SI = 1;
return 0;
}
return ( *(int*)a *(int*)b ) ? 1 : -1;
}
int
On Thu, 2006-08-31 at 14:32, Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 14:11 schrieb Csaba Nagy:
How about prepared means really prepared... in the sense of parsed,
analyzed all sensible plans, and save a meta-plan which based on current
statistics and parameter values chooses
On 8/31/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
With time, it becomes ever clearer to me that prepared SQL statements are just
a really bad idea. On some days, it seems like half the performance problems
in PostgreSQL-using systems are because a bad plan was cached somewhere. I'd
say, in
hello everyone ,
i has been add to you guys' mail list by accident, i don't how to
refuse to receive your mails, would you please help me to remove my mail
address form mail group [EMAIL PROTECTED]
i appreciatewhat you will do for me. (my mail address:
[EMAIL PROTECTED])
thanks .
On Thu, August 31, 2006 18:56, Peter Eisentraut wrote:
With time, it becomes ever clearer to me that prepared SQL statements are
just
a really bad idea. On some days, it seems like half the performance
problems
in PostgreSQL-using systems are because a bad plan was cached somewhere.
Is
Peter Eisentraut wrote:
With time, it becomes ever clearer to me that prepared SQL statements are
just
a really bad idea. On some days, it seems like half the performance problems
in PostgreSQL-using systems are because a bad plan was cached somewhere. I'd
say, in the majority of cases
Am Donnerstag, 31. August 2006 15:05 schrieb Merlin Moncure:
The proposal to supply hints to statements and functions has been
voted down several times due to the argument that it is better to fix
the planner. I think supplying hints does fix the planner, and is a
balanced solution.
Planner
Am Donnerstag, 31. August 2006 15:06 schrieb Jeroen T. Vermeulen:
Is there any kind of pattern at all to this problem? Anything
recognizable? A few typical pitfalls?
If data is not distributed evenly, then any old WHERE foo = $1 is prone to be
the wrong plan for half of the possible values
Am Donnerstag, 31. August 2006 14:52 schrieb Csaba Nagy:
So for the like query case you could save 2 plans, one for the indexable
case, one for the not indexable case. Then at runtime you choose the
proper one based on the pattern value.
OK, why don't you work out an example. Let's look at
Merlin Moncure wrote:
On 8/31/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
With time, it becomes ever clearer to me that prepared SQL statements
are just
a really bad idea. On some days, it seems like half the performance
problems
in PostgreSQL-using systems are because a bad plan was
Am Donnerstag, 31. August 2006 15:18 schrieb Andreas Pflug:
Not to mention problems with outdated plans after schema changes. Using
views unplanned (replanned) when used in joins could lead to improved
resulting plans (e.g. if the view contains outer joins itself).
Views don't contain
How about prepared means really prepared... in the sense of
parsed, analyzed all sensible plans, and save a meta-plan which
based
on current statistics and parameter values chooses one of the
considered (and cached) plans ?
I don't think this could solve one particularly frequent
On Thu, 2006-08-31 at 15:19, Peter Eisentraut wrote:
OK, why don't you work out an example. Let's look at this query:
SELECT * FROM t1 WHERE a LIKE $1;
What two plans would you prepare?
if substring($1 from 1 for 1) != '%' then
use plan 1 (see below);
else
use plan 2 (see below);
end
This doesn't look right to me:
postgres=# set work_mem='1GB';
SET
postgres=# show work_mem;
work_mem
--
1MB
(1 row)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill
Am Donnerstag, 31. August 2006 15:36 schrieb Csaba Nagy:
On Thu, 2006-08-31 at 15:19, Peter Eisentraut wrote:
OK, why don't you work out an example. Let's look at this query:
SELECT * FROM t1 WHERE a LIKE $1;
What two plans would you prepare?
if substring($1 from 1 for 1) != '%' then
On Thu, 2006-08-31 at 15:49, Peter Eisentraut wrote:
Note that plan 1 can only be created if you know the actual value for $1.
Why would that be so ? The plan can contain functions of $1 (both
constants in plan 1 are a function of $1).
Cheers,
Csaba
---(end of
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out.
But later SQL
On Aug 31, 2006, at 8:52 , Csaba Nagy wrote:
This of course would need a lot more preparation time than just
prepare
one plan, but that's why you want to do it upfront and then cache the
results. A central plan repository mentioned in other posts would fit
nicely here... and you could use
What's up there? It has been down all week.
We're trying to get the Slony-I 1.2 release out, so we can then
migrate over to pgFoundry. But that doesn't working terribly well
when gBorg's down...
--
let name=cbbrowne and tld=acm.org in String.concat @ [name;tld];;
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
I'm unclear as to why you've got DO INSTEAD NOTHING rules in there ---
You need to have one unconditional rule if you have a bunch of
conditional ones. The system does not see through the fact that the
conditional ones cover all
On Thu, Aug 31, 2006 at 08:06:57PM +0700, Jeroen T. Vermeulen wrote:
On Thu, August 31, 2006 18:56, Peter Eisentraut wrote:
With time, it becomes ever clearer to me that prepared SQL
statements are just a really bad idea. On some days, it seems like
half the performance problems in
Am Donnerstag, 31. August 2006 16:09 schrieb Theo Schlossnagle:
I don't chime in very often, but I do think the refusal to
incorporate hints into the planner system is fantastically stubborn
and nonsensical.
What is actually fantastically nonsensical about this is that the issues I
outlined
On Aug 31, 2006, at 9:25 AM, Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 15:05 schrieb Merlin Moncure:
The proposal to supply hints to statements and functions has been
voted down several times due to the argument that it is better to fix
the planner. I think supplying hints does
Am Donnerstag, 31. August 2006 16:26 schrieb Andrew Dunstan:
Cached plans etc. might have an impact, but please do not overlook the
benefits of parameterized queries in avoiding SQL injection attacks, as
well as often being much cleaner to code.
That might be part of the confusion. Composing
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
The proposed WITH CHECK OPTION implementation is unworkable for exactly
this reason --- it will give the wrong answers in the presence of
volatile functions such as nextval().
I'm not sure why
Am Donnerstag, 31. August 2006 15:43 schrieb stark:
This doesn't look right to me:
postgres=# set work_mem='1GB';
SET
postgres=# show work_mem;
work_mem
--
1MB
(1 row)
Fixed.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 14:52 schrieb Csaba Nagy:
So for the like query case you could save 2 plans, one for the indexable
case, one for the not indexable case. Then at runtime you choose the
proper one based on the pattern value.
OK, why don't you work out an
On Thu, Aug 31, 2006 at 03:36:25PM +0200, Csaba Nagy wrote:
On Thu, 2006-08-31 at 15:19, Peter Eisentraut wrote:
OK, why don't you work out an example. Let's look at this query:
SELECT * FROM t1 WHERE a LIKE $1;
What two plans would you prepare?
if substring($1 from 1 for 1) != '%' then
Also people trying to download slony have to do some
hunting to find things. The source only tar is not
available on pgfoundry.
one of them,
elein
On Thu, Aug 31, 2006 at 10:33:36AM -0400, Chris Browne wrote:
What's up there? It has been down all week.
We're trying to get the Slony-I 1.2
On Thu, Aug 31, 2006 at 10:09:10AM -0400, Theo Schlossnagle wrote:
There are many databases out there with better planners than
PostgreSQL -- likely there will always be. Even those databases have
query planner hints. Why? Because the authors of those database had
the humility to
Peter Eisentraut [EMAIL PROTECTED] writes:
With time, it becomes ever clearer to me that prepared SQL statements
are just a really bad idea.
That's an overstatement, but I'll agree that they have strong
limitations.
I'd wish that we reconsider when and how prepared statements are used. The
On Aug 31, 2006, at 11:18 , [EMAIL PROTECTED] wrote:
I'm attempting to understand why prepared statements would be used for
long enough for tables to change to a point that a given plan will
change from 'optimal' to 'disastrous'.
Wouldn't this require that the tables are completely
Tom Lane wrote:
As noted downthread, we've confused out-of-line parameter value shipping
with prepared statements. It might be worth rejiggering the FE/BE
protocol to separate those things better.
Well, that's surely not going to happen in a hurry, is it? Maybe a quick
fix would be
On 2006-08-31, Tom Lane [EMAIL PROTECTED] wrote:
I'd wish that we reconsider when and how prepared statements are used. The
JDBC interface and PL/pgSQL are frequently noticed perpetrators, but the
problem is really all over the place.
AFAIK those are the only two places where preparation
On Thu, Aug 31, 2006 at 11:36:36AM -0400, AgentM wrote:
On Aug 31, 2006, at 11:18 , [EMAIL PROTECTED] wrote:
I'm attempting to understand why prepared statements would be used for
long enough for tables to change to a point that a given plan will
change from 'optimal' to 'disastrous'.
AgentM [EMAIL PROTECTED] writes:
On Aug 31, 2006, at 11:18 , [EMAIL PROTECTED] wrote:
I'm attempting to understand why prepared statements would be used for
long enough for tables to change to a point that a given plan will
change from 'optimal' to 'disastrous'.
Scenario: A web application
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
As noted downthread, we've confused out-of-line parameter value shipping
with prepared statements. It might be worth rejiggering the FE/BE
protocol to separate those things better.
Well, that's surely not going to happen in a hurry,
Neither of these problems have anything to do with statistics getting
stale.
... and the second one would benefit from a meta-plan facility which
puts some meta-plan nodes on top of specific plans to dispatch based
on parameter values at runtime.
Incidentally, the dispatch could check the
On Aug 31, 2006, at 12:04 , Tom Lane wrote:
The two major complaints that I've seen are
snip
Neither of these problems have anything to do with statistics getting
stale.
Not stats-- plans. Plan invalidation has been discussed before, no?
-M
---(end of
On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote:
I'd wish that we reconsider when and how prepared statements are used. The
JDBC interface and PL/pgSQL are frequently noticed perpetrators, but the
problem is really all over the place.
AFAIK those are the only two places where
Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote:
I'd wish that we reconsider when and how prepared statements are used. The
JDBC interface and PL/pgSQL are frequently noticed perpetrators, but the
problem is really all over the place.
AFAIK those are
Lukas Kahwe Smith wrote:
Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 11:27:18AM -0400, Tom Lane wrote:
I'd wish that we reconsider when and how prepared statements are
used. The JDBC interface and PL/pgSQL are frequently noticed
perpetrators, but the problem is really all over the
AgentM wrote:
On Aug 31, 2006, at 12:04 , Tom Lane wrote:
The two major complaints that I've seen are
snip
Neither of these problems have anything to do with statistics
getting stale.
Not stats-- plans. Plan invalidation has been discussed before, no?
Plan invalidation helps with
[EMAIL PROTECTED] (Tom Lane) writes:
Chris Browne [EMAIL PROTECTED] writes:
If I touch preproc.y and pgc.l, the .c files get regenerated, and all
is well.
If I don't, they get left alone, and I see compilation errors.
It seems to me you need to rebuild the C files and commit them.
No,
[EMAIL PROTECTED] (elein) writes:
Also people trying to download slony have to do some
hunting to find things. The source only tar is not
available on pgfoundry.
The source tarball for version 1.1.5 is now in place:
http://pgfoundry.org/frs/download.php/1063/slony1-1.1.5.tar.bz2
We may as
Hi,
now that you're reviewing the updatable view patch, i think we must
decide what you're position will be about if the updatable view should
inherit the base table default values... or if we want to create
default values for every view if we want they match with the base
table ones... (fwiw,
On Thu, Aug 31, 2006 at 06:34:45PM +0200, Lukas Kahwe Smith wrote:
BTW: PDO has gotten a switch to force client side placeholder
replacement in favor of using server side prepared statements due to the
fact that prepared statements side-step the MySQL query cache.
Perl DBD:Pg also has a
On 8/31/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Donnerstag, 31. August 2006 15:05 schrieb Merlin Moncure:
The proposal to supply hints to statements and functions has been
voted down several times due to the argument that it is better to fix
the planner. I think supplying hints does
Peter Eisentraut [EMAIL PROTECTED] writes:
- Redefine prepared to mean parsed rather than parsed and planned.
Then you would be going very much against the user's expectations.
Driver interfaces expose very clearly to the user an explicit interface to
prepare and execute a query separately.
Also people trying to download slony have to do some hunting
to find things. The source only tar is not available on pgfoundry.
All gborg *downloads* are available on:
http://www.postgresql.org/ftp/projects/gborg/
Seems Slony hasn't released files using the gborg file release system,
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
No, because those derived files are not in CVS at all. What you
are describing sounds to me like a clock skew problem. Is your
machine's system clock showing the correct date?
Odd, odd. NOT a clock problem. The
Gregory Stark wrote:
Then you would be going very much against the user's expectations.
Driver interfaces expose very clearly to the user an explicit
interface to prepare and execute a query separately. What your
proposing is to go behind the user's back and do what he's gone out
of his way
On Thu, Aug 31, 2006 at 06:43:38PM +0100, Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
- Redefine prepared to mean parsed rather than parsed and planned.
Then you would be going very much against the user's expectations.
Driver interfaces expose very clearly to the
Tom Lane wrote:
Chris Browne [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Tom Lane) writes:
No, because those derived files are not in CVS at all. What you
are describing sounds to me like a clock skew problem. Is your
machine's system clock showing the correct date?
Martijn van Oosterhout wrote:
On Thu, Aug 31, 2006 at 06:43:38PM +0100, Gregory Stark wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
- Redefine prepared to mean parsed rather than parsed and planned.
Then you would be going very much against the user's expectations.
Driver
Bruce Momjian [EMAIL PROTECTED] writes:
OK, here is a much nicer patch. The fix is to do no rounding, but to
find the number of days before applying the factor adjustment.
You have forgotten the problem of the factor not being exactly
representable (eg, things like '10 days' * 0.1 not giving
Peter Eisentraut [EMAIL PROTECTED] writes:
In that case I'd expect to edit some central openssl configuration file to
turn off the offending methods in one central place.
I concur with this in the abstract: it would be better design to submit
something to the OpenSSL project to allow setting
On Thu, 2006-08-31 at 10:09 -0400, Theo Schlossnagle wrote:
On Aug 31, 2006, at 9:25 AM, Peter Eisentraut wrote:
Am Donnerstag, 31. August 2006 15:05 schrieb Merlin Moncure:
The proposal to supply hints to statements and functions has been
voted down several times due to the argument that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, here is a much nicer patch. The fix is to do no rounding, but to
find the number of days before applying the factor adjustment.
You have forgotten the problem of the factor not being exactly
representable (eg, things like '10
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Driver interfaces expose very clearly to the user an explicit
interface to prepare and execute a query separately.
The JDBC documentation merely contains statements of the sort A SQL
statement with or without IN parameters can
On Thu, Aug 31, 2006 at 02:58:48PM -0400, Tom Lane wrote:
The protocol does let you use OOL parameters without retaining a
prepared plan, thanks to the hack introduced later to not plan the
unnamed statement at Parse time, but that's definitely a bit of a wart
on the original protocol design.
On Thu, Aug 31, 2006 at 02:16:32PM -0400, Andrew Dunstan wrote:
According to the docs you can actually choose between server side
prepare or not on a per call basis. It contains this example:
Yeah, but it also contains this:
Using prepared statements is in theory quite a bit faster: not
On 31-Aug-06, at 2:58 PM, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Driver interfaces expose very clearly to the user an explicit
interface to prepare and execute a query separately.
The JDBC documentation merely contains statements of the sort A SQL
Ühel kenal päeval, N, 2006-08-31 kell 20:01, kirjutas Peter Eisentraut:
For PL/pgSQL, you simply write a query and all the preparing action
happens implicitly. There is nothing explicit about that interface.
So if users have certain expectations here, they're just making them up.
Or basing
On 2006.08.31 at 14:36:28 -0400, Tom Lane wrote:
I concur with this in the abstract: it would be better design to submit
something to the OpenSSL project to allow setting engine choices and
such site-wide. In the short term, though, it's hard to deny that our
code
if
Bruce Momjian [EMAIL PROTECTED] writes:
Well, the patch only multiplies by 30, so the interval would have to
span +5 million years to overflow. I don't see any reason to add
rounding until we get an actual query that needs it
Have you tried your patch against the various cases that have been
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, the patch only multiplies by 30, so the interval would have to
span +5 million years to overflow. I don't see any reason to add
rounding until we get an actual query that needs it
Have you tried your patch against the various
Martijn van Oosterhout kleptog@svana.org writes:
So what are the options now? A GUC like so:
prepare_means_plan = [true|false]
So then a prepare will always parse straightaway, but you can choose
whether or not you want to plan straightaway or at bind time.
That seems like just a kluge, as
Hello,
Dave Cramer and I have dealt with a company today running 8.1.4 on
Windows 2003. The application is a web app that runs via JDBC/Hibernate.
The application will function perfectly for about 2/3 weeks and then we
will receive a:
server sent data (\D\ message) without prior row
[EMAIL PROTECTED] writes:
Does Oracle automatically regenerate prepared plans on occasion?
Not due to statistics changes, only if your schema changes.
(caveat: I last used Oracle back at 8i)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Joshua D. Drake [EMAIL PROTECTED] writes:
Dave Cramer and I have dealt with a company today running 8.1.4 on
Windows 2003. The application is a web app that runs via JDBC/Hibernate.
The application will function perfectly for about 2/3 weeks and then we
will receive a:
server sent data (\D\
[EMAIL PROTECTED] (Magnus Hagander) writes:
Also people trying to download slony have to do some hunting
to find things. The source only tar is not available on pgfoundry.
All gborg *downloads* are available on:
http://www.postgresql.org/ftp/projects/gborg/
Seems Slony hasn't released
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Dave Cramer and I have dealt with a company today running 8.1.4 on
Windows 2003. The application is a web app that runs via JDBC/Hibernate.
The application will function perfectly for about 2/3 weeks and then we
will receive a:
server
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, are you sure this is coming from JDBC? I see the exact same
message text in libpq:
libpq_gettext(server sent data (\D\ message) without prior row
description (\T\ message)\n));
Maybe the JDBC driver uses the identical message
Peter Eisentraut [EMAIL PROTECTED] writes:
Gregory Stark wrote:
Let's verify that. JDBC and PL/pgSQL have been mentioned.
The JDBC documentation merely contains statements of the sort A SQL
statement with or without IN parameters can be pre-compiled and stored
in a PreparedStatement
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, are you sure this is coming from JDBC? I see the exact same
message text in libpq:
libpq_gettext(server sent data (\D\ message) without prior row description (\T\
message)\n));
Maybe the JDBC driver uses the
On 31-Aug-06, at 6:01 PM, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, are you sure this is coming from JDBC? I see the exact same
message text in libpq:
libpq_gettext(server sent data (\D\ message) without prior row
description (\T\ message)\n));
Maybe
Dave Cramer wrote:
On 31-Aug-06, at 6:01 PM, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, are you sure this is coming from JDBC? I see the exact same
message text in libpq:
libpq_gettext(server sent data (\D\ message) without prior row
description
That sounds suspiciously close to the time from boot to wraparound of
GetTickCount:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/gettickcount.asp
M$ list this as 49 days but that's the time to wrap clear around to
zero; the value overflows and goes negative in
Jaime Casanova [EMAIL PROTECTED] writes:
now that you're reviewing the updatable view patch, i think we must
decide what you're position will be about if the updatable view should
inherit the base table default values... or if we want to create
default values for every view if we want they
Joshua D. Drake [EMAIL PROTECTED] writes:
My bet is something depending on GetTickCount to measure elapsed time
(and no, it's not used in the core Postgres code, but you've got plenty
of other possible culprits in that stack).
This doesn't quite make sense. The only reason we have to reboot
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
My bet is something depending on GetTickCount to measure elapsed time
(and no, it's not used in the core Postgres code, but you've got plenty
of other possible culprits in that stack).
This doesn't quite make sense. The only reason we
Alvaro Herrera wrote:
Dave Cramer wrote:
On 31-Aug-06, at 6:01 PM, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, are you sure this is coming from JDBC? I see the exact same
message text in libpq:
libpq_gettext(server sent data (\D\ message) without prior
Joshua D. Drake [EMAIL PROTECTED] writes:
Which means we need to start stripping it down. Gah, I actually argued
*for* this port to. Next time slap me.
Well, before you invest a lot of time barking up what might be the wrong
tree, there is a very easy test you can use to check the GetTickCount
Martijn van Oosterhout kleptog@svana.org writes:
Then you would be going very much against the user's expectations.
Driver interfaces expose very clearly to the user an explicit interface to
prepare and execute a query separately. What your proposing is to go behind
the user's back
On 31/8/06 23:34, Joshua D. Drake [EMAIL PROTECTED] wrote:
Sure it is a registry entry... so we could (in theory) shrink that quite
a bit.. However I am confused, if we don't use it, what that is
connecting to libpq would trigger it?
I know they are using pgAAdmin...
Are they using
1 - 100 of 116 matches
Mail list logo
