Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Jorge Campins
How can I find which version I'm using? All I could see in pgAdmin is 8.1. Which value should I use for timezone in postgresql.conf? I tried select * from pg_timezone_names to get a list of valid time zone names but it failed with relation pg_timezone_names does not exist. Thanks and

Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Magnus Hagander
Jorge Campins wrote: How can I find which version I'm using? All I could see in pgAdmin is 8.1. SELECT version(); Which value should I use for timezone in postgresql.conf? I tried select * from pg_timezone_names to get a list of valid time zone names but it failed with relation

Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Magnus Hagander
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: Try setting your timezone in postgresql.conf - that should override whatever Windows has for you. Unless his 8.1 is really 8.1.something-pretty-darn-recent, it's not going to know about the latest Venezuela DST law change anyway.

Re: [BUGS] 8.3.0: vacuum full analyze: invalid memory alloc request size

2008-02-10 Thread Tomas Szepe
Hmm, please see if you can get a stack trace from that (set the breakpoint at errfinish()). You might want to use vacuum verbose first so that you can figure out which individual table is causing it. Ok, I recompiled CVS head with --enable-debug and with --enable-cassert and hit the

Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Magnus Hagander
In 8.2, use pg_timezone_names to find the proper one for you - it'll exist once you've upgraded :-) //Magnus Jorge Campins wrote: I'll upgrade to 8.2 ASAP. Once in 8.2, which value should I use for timezone in postgresql.conf? Thanks and regards, Jorge - Original Message - From:

Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Jorge Campins
I'll upgrade to 8.2 ASAP. Once in 8.2, which value should I use for timezone in postgresql.conf? Thanks and regards, Jorge - Original Message - From: Magnus Hagander [EMAIL PROTECTED] To: Jorge Campins [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED]; pgsql-bugs@postgresql.org Sent:

Re: [BUGS] BUG #3947: Unable to Initialize Data Cluster

2008-02-10 Thread Dave Page
On Feb 10, 2008 4:45 PM, Fusion Software (UK) Ltd [EMAIL PROTECTED] wrote: Can also confirm that under exactly the same circumstances 8.2 installs without a hitch. There's definitiely a glitch somewhere in the 8.3 installation package. 8.3 is the first release build with VC++ 2005 - previous

[BUGS] BUG #3950: Server Problems

2008-02-10 Thread Wolvesden
The following bug has been logged online: Bug reference: 3950 Logged by: Wolvesden Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Windows XP Description:Server Problems Details: For some reason when I upgraded to 8.3 I can't get the

Re: [BUGS] BUG #3947: Unable to Initialize Data Cluster

2008-02-10 Thread Dave Page
[Please keep messages CC'd to the list] On Feb 10, 2008 4:25 PM, Fusion Software (UK) Ltd [EMAIL PROTECTED] wrote: Just to update you on the latest. It appears that although we can get 8.3.0 to install by installing the Visual C++ 2005 msi first, although it appears to work fine when its

Re: [BUGS] BUG #3950: Server Problems

2008-02-10 Thread Tom Lane
Wolvesden [EMAIL PROTECTED] writes: For some reason when I upgraded to 8.3 I can't get the server to start. What it keeps telling me is as Follows: pg_ctrl: another server might be running; trying to start server anyway FATAL: unreconized configuration parameter redirect_stderr This

Re: [BUGS] BUG #3947: Unable to Initialize Data Cluster

2008-02-10 Thread Dave Page
On Feb 10, 2008 5:10 PM, Fusion Software (UK) Ltd [EMAIL PROTECTED] wrote: Hi Dave Is this machine on a domain with any group policies or similar? I assume you're running the installations as Administrator? Its a basic default Vista installation with no domain or group policies. Most of our

Re: [BUGS] 8.3.0: vacuum full analyze: invalid memory alloc request size

2008-02-10 Thread Tom Lane
Tomas Szepe [EMAIL PROTECTED] writes: Do you perhaps have a ridiculously low fillfactor attached to the system catalogs? I don't know - how do I tell? If you did, you'd know it --- that's not something that would happen without your trying to do it. After poking around in the code a bit, I

Re: [BUGS] 8.3.0: vacuum full analyze: invalid memory alloc request size

2008-02-10 Thread Tom Lane
Tomas Szepe [EMAIL PROTECTED] writes: Are you doing anything that would involve lots of updates in these catalogs --- maybe repeatedly renaming a column, or something like that? Hmm, I typically use a pair of ALTER TABLE table DISABLE TRIGGER USER;/ ALTER TABLE table ENABLE TRIGGER USER;

Re: [BUGS] 8.3.0: vacuum full analyze: invalid memory alloc request size

2008-02-10 Thread Tomas Szepe
Tomas Szepe [EMAIL PROTECTED] writes: Are you doing anything that would involve lots of updates in these catalogs --- maybe repeatedly renaming a column, or something like that? Hmm, I typically use a pair of ALTER TABLE table DISABLE TRIGGER USER;/ ALTER TABLE table ENABLE TRIGGER

[BUGS] BUG #3951: SELECT ... WHERE Param = ? does not work if Param is of type bytea

2008-02-10 Thread vha
The following bug has been logged online: Bug reference: 3951 Logged by: vha Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Windows XP SP2 Description:SELECT ... WHERE Param = ? does not work if Param is of type bytea Details: I have a

Re: [BUGS] 8.3.0: vacuum full analyze: invalid memory alloc request size

2008-02-10 Thread Tom Lane
Tomas Szepe [EMAIL PROTECTED] writes: Are you running with autovacuum on, or not? At the moment autovacuum is off, but it _might_ have been on in the first 40 hours or so... Sorry, I can't say exactly. Okay ... so with autovac off, I can reproduce a problem this way: 1. Put 1000 repetitions

Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Alvaro Herrera
Magnus Hagander wrote: Tom Lane wrote: This does suggest that we'll need to revisit the win32_tzmap[] list every so often? Seems so. It's the first time I've heard of a timezone being *added* and not just changed, but obviously it does happen :-( Hmm, was this table manually built? I

Re: [BUGS] BUG #3948: date/time functions returning wrong value

2008-02-10 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: I think what I conclude from this is that Windows TZ database is so bogus that we should avoid trying to rely on it -- I say if the user does not set timezone in postgresql.conf, refuse to start. Remember we're also relying on the OS for the time of day