The following bug has been logged online:
Bug reference: 4025
Logged by: James
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0.1
Operating system: winXP
Description:wsock32.dll not found
Details:
when installation reach initdb stage, it shows can not init
Using PostgreSQL 8.2.3, on linux (FC3):
test=> select lseg'((0,0),(1,0))' ?# lseg'((0,0),(1,0))';
-[ RECORD 1 ]
?column? | f
while
avail=> select lseg'((0,0),(1,0))' ?# lseg'((0,0),(1,1))';
-[ RECORD 1 ]
?column? | t
Looking over the geometric operations source it appears that the
intersect o
"Yogesh" <[EMAIL PROTECTED]> writes:
> If I query database from my DB server which is on the same linux box, it
> diplays the wrong dates.Like actual date in my table is say 17-MAR-08
> 11.59.00 PM, then it displays 2008-03-18 00:59:00.
> and If I query the DB using a standalone script then it give
The following bug has been logged online:
Bug reference: 4026
Logged by: Yogesh
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.2
Operating system: linux
Description:Displaying Wrong dates
Details:
If I query database from my DB server which is on the same
The following bug has been logged online:
Bug reference: 4027
Logged by: Jonathan Guthrie
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.0
Operating system: Debian Gnu/Linux "unstable" 2.6.24
Description:backslash escaping not disabled in plpgsql
Details:
"Jonathan Guthrie" <[EMAIL PROTECTED]> writes:
> I have set the standard_conforming_strings to "on" in my settings ...
> However, when I attempt to define this function:
> create function foo (out r refcursor) as $bar$
> begin
> open r for
>select * from user_data
>where name_first like n
(Sorry if duplicates show up this is the third time ive posted this in
the past 10 hours, Im assuming it got dropped because of the
attachments)
Problem: Apparently random segfaults apparently query agnostic, seem
to be more frequent when a pg_dump is running
The most frequent query it segfault
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> Problem: Apparently random segfaults apparently query agnostic, seem
> to be more frequent when a pg_dump is running
Hmm, seems from the backtrace that we're trying to do a replan with an
invalid ActiveSnapshot. What sequence of operations is the co
On Tue, Mar 11, 2008 at 10:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> > Problem: Apparently random segfaults apparently query agnostic, seem
> > to be more frequent when a pg_dump is running
>
> Hmm, seems from the backtrace that we're trying to
FYI right now Im trying:
Author: tgl
Date: Sat Feb 2 22:26:17 2008 +
Fix WaitOnLock() to ensure that the process's "waiting" flag is reset after
erroring out of a wait. We can use a PG_TRY block for this, but
add a comment
explaining why it'd be a bad idea to use it for any ot
Oops we actually use DBI->prepare_cached() not DBI->prepare() which to
my understanding should be roughly equivalent to (because of
Apache::DBI):
prepare query ;
begin;
execute query;
commit;
(next page load)
begin;
execute query;
commit;
I can turn that off and only use DBI->prepare() as a t
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> I can turn that off and only use DBI->prepare() as a test. Or heck
> just cut DBI->prepare() out and just quote everything and send them
> through using DBI->do() instead. That is if you think that could be
> the culprit.
The path of control that's d
On Wed, Mar 12, 2008 at 12:19 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Now personally, I am much more interested in *reproducing* the problem
> than merely dodging it. I can understand if you just need a workaround
> yesterday, but please see if you can get a reproducible test case ...
>
>
"Alex Hunsaker" <[EMAIL PROTECTED]> writes:
> the mean time here is a new backtrace I just got (lord knows how... it
> seems to be as soon as I stop trying to make it crash and look away,
> thats when it does).
Not sure that you are clear on what's happening here, but the train of
events is someth
Tom Lane wrote:
> plpgsql does not consider standard_conforming_strings --- it still uses
> backslash escaping in its function bodies regardless. Since the
> language itself is not standardized, I see no particular reason that
> standard_conforming_strings should govern it.
I think plpgsql should
15 matches
Mail list logo