[BUGS] BUG #4025: wsock32.dll not found

2008-03-11 Thread James
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

[BUGS] lseg ?# (intersects) incorrect for lsegs whose intersection is another lseg

2008-03-11 Thread Andy Meyer
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

Re: [BUGS] BUG #4026: Displaying Wrong dates

2008-03-11 Thread Tom Lane
"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

[BUGS] BUG #4026: Displaying Wrong dates

2008-03-11 Thread Yogesh
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

[BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-11 Thread Jonathan Guthrie
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:

Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-11 Thread Tom Lane
"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

[BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Alex Hunsaker
(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

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Tom Lane
"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

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Alex Hunsaker
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

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Alex Hunsaker
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

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Alex Hunsaker
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

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Tom Lane
"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

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Alex Hunsaker
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 ... > >

Re: [BUGS] 8.3.0 backend segfaults

2008-03-11 Thread Tom Lane
"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

Re: [BUGS] BUG #4027: backslash escaping not disabled in plpgsql

2008-03-11 Thread Peter Eisentraut
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