[GENERAL] AT TIME ZONE and DST in UTC<->CET conversion
First, if I do conversion from UTC to CET and back when a timestamp is OUTSIDE of daylight saving period, it's correct: postgres# select '2008-01-01 10:10:10 UTC' AT TIME ZONE 'CET'; timezone - 2008-01-01 11:10:10 postgres# select '2008-01-01 11:10:10 CET' AT TIME ZONE 'UTC'; timezone - 2008-01-01 10:10:10 When I do the same INSIDE this period just the UCT->CET direction is correct but back direction will fail subtracting only 1 hour instead of 2 hours. postgres# select '2008-06-01 10:10:10 UTC' AT TIME ZONE 'CET'; timezone - 2008-06-01 12:10:10 postgres# select '2008-06-01 12:10:10 CET' AT TIME ZONE 'UTC'; timezone - 2008-06-01 11:10:10 If it supports automatic discovery of DST in conversion from UTC to CET (and this is great), why it doesn't support this discovery in opposit direction? Regards, Jaromir smime.p7s Description: S/MIME cryptographic signature
Re: [GENERAL] AT TIME ZONE and DST in UTC<->CET conversion
Jaromír Talíř <[EMAIL PROTECTED]> writes: > postgres# select '2008-06-01 10:10:10 UTC' AT TIME ZONE 'CET'; > timezone > - > 2008-06-01 12:10:10 ISTM this is the one that's wrong. "CET" is standard time, it, GMT+1. If you want a timezone which switches between CET and CST automatically you should use something like Europe/Paris. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [Postgresql 8.2.3] autovacuum starting up even after disabling ?
dushy <[EMAIL PROTECTED]> writes: > On Fri, Jul 4, 2008 at 10:56 PM, Adrian Klaver <[EMAIL PROTECTED]> wrote: >> One question? Did you do pg_ctl reload after changing the config file? > I did not change any config yet - autovacuum was always disabled since > the day PG was set up. A mistake here seems by far the most likely explanation. Does "show autovacuum" confirm that it's off? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Target lists can have at most 1664 entries?
On Wed, Jul 02, 2008 at 09:22:50AM +0200, Bjørn T Johansen wrote: > On Wed, 02 Jul 2008 03:04:04 -0400 > Tom Lane <[EMAIL PROTECTED]> wrote: > > =?UTF-8?Q?Bj=C3=B8rn?= T Johansen <[EMAIL PROTECTED]> writes: > > > What does this mean and how can it be fixed? > > > > Reduce the number of columns in your SELECTs? > > > > This whiffs to me of excruciatingly bad schema design. How could > > you possibly need upwards of a thousand columns in a query result? > > IMHO reasonable column counts are O(10), not O(bignum). > > Well, I do agree but it is not my design and a "fix" in PostgreSQL > would be quicker than fixing the design That's where you're badly mistaken. Your application is completely broken, and trying to adjust everybody else's Postgres to accommodate *your* broken application is both selfish and short-sighted. It's selfish because you're asking others to do work they don't need to do just so you can avoid doing work you need to do, and it's short-sighted because your application is guaranteed to be broken in lots of other ways if it's broken this way. Fix the application, and if you can't, find another job where they're not being idiots. There are plenty of Postgres-related jobs out there. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] AT TIME ZONE and DST in UTC<->CET conversion
Gregory Stark <[EMAIL PROTECTED]> writes: > ISTM this is the one that's wrong. "CET" is standard time, it, GMT+1. > If you want a timezone which switches between CET and CST automatically you > should use something like Europe/Paris. Well, actually he *is* using such a zone: regression=# select * from pg_timezone_names where name = 'CET'; name | abbrev | utc_offset | is_dst --+++ CET | CEST | 02:00:00 | t (1 row) But regression=# select * from pg_timezone_abbrevs where abbrev = 'CET'; abbrev | utc_offset | is_dst ++ CET| 01:00:00 | f (1 row) The problem is that one of these two statements is using the abbrev meaning and the other is using the timezone meaning. We don't have much control over the zone definition, so I'm thinking maybe the abbrev should be removed from the tznames lists. But that seems a bit sucky too. Does anyone have any idea if the zic folk would be responsive to a complaint that defining a timezone with the same name as an abbreviation is a bad idea? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Target lists can have at most 1664 entries?
On Sat, 5 Jul 2008 08:17:37 -0700 David Fetter <[EMAIL PROTECTED]> wrote: > On Wed, Jul 02, 2008 at 09:22:50AM +0200, Bjørn T Johansen wrote: > > On Wed, 02 Jul 2008 03:04:04 -0400 > > Tom Lane <[EMAIL PROTECTED]> wrote: > > > =?UTF-8?Q?Bj=C3=B8rn?= T Johansen <[EMAIL PROTECTED]> writes: > > > > What does this mean and how can it be fixed? > > > > > > Reduce the number of columns in your SELECTs? > > > > > > This whiffs to me of excruciatingly bad schema design. How could > > > you possibly need upwards of a thousand columns in a query result? > > > IMHO reasonable column counts are O(10), not O(bignum). > > > > Well, I do agree but it is not my design and a "fix" in PostgreSQL > > would be quicker than fixing the design > > That's where you're badly mistaken. Your application is completely > broken, and trying to adjust everybody else's Postgres to accommodate > *your* broken application is both selfish and short-sighted. It's > selfish because you're asking others to do work they don't need to do > just so you can avoid doing work you need to do, and it's > short-sighted because your application is guaranteed to be broken in > lots of other ways if it's broken this way. > > Fix the application, and if you can't, find another job where they're > not being idiots. There are plenty of Postgres-related jobs out > there. > > Cheers, > David. Actually, this discussion was finished a long time ago (we are already looking at the Hibernate config and domain modell).. And btw, I wasn't proposing a change in PostgreSQL, only if there were some config that could be changed to accomodate this... BTJ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Installation problem -- another installation is in progress
I am attempting to install the postrgresql-8.3.3-1 download on Windows Vista. When I get to the "Ready to install" dialog and click OK, I get the message "Another installation is in progress", and I need to click on cancel and end the installation -- otherwise I am in a loop. This happens even after I reboot. Any help would be greatly appreciated. Susan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] roll back to 8.1 for PyQt driver work-around
Hello, I just signed on the list. Any suggestions for how best to launch one of two different versions of pg installed on the same machine? I have both 8.3 and 8.1 installed on a MacBookPro (OS X 10.5.2). I stopped the 8.3 postmaster using pg_ctl in order to roll back to 8.1. Problem is, now I can't seem to start the server using either version. When I launch 8.1 with pg_ctl, it yields a "postmaster starting" message; but then a status check shows that the server is not running. Issuing the same commands for 8.3, I get similar results. eg: [tiento:~] postgres% /opt/local/lib/postgresql81/bin/pg_ctl start -D / Library/PostgreSQL8/data -l /Users/Shared/pgLog/pgLog.txt postmaster starting [tiento:~] postgres% /opt/local/lib/postgresql81/bin/pg_ctl status -D / Library/PostgreSQL8/data pg_ctl: neither postmaster nor postgres running I'm trying to roll back to version 8.1 as I've run into a bug in Qt's QPSQL driver. I'm able to create tables and add rows of data to them; but my model.select() statements all fail. The "This version of PostgreSQL is not supported and may not work" message is ominous ;) Thanks in advance! Scott Scott Frankel President/VFX Supervisor Circle-S Studios 510-339-7477 (o) 510-332-2990 (c) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] roll back to 8.1 for PyQt driver work-around
Scott Frankel <[EMAIL PROTECTED]> writes: > Any suggestions for how best to launch one of two different versions > of pg installed on the same machine? > I have both 8.3 and 8.1 installed on a MacBookPro (OS X 10.5.2). I > stopped the 8.3 postmaster using pg_ctl in order to roll back to 8.1. > Problem is, now I can't seem to start the server using either version. It looks like you're trying to use the same data directory for both versions, which won't work. They're not compatible on-disk. > When I launch 8.1 with pg_ctl, it yields a "postmaster starting" > message; but then a status check shows that the server is not > running. Issuing the same commands for 8.3, I get similar results. Looking into the postmaster log file (your -l specification) might yield some insight. pg_ctl itself doesn't really know why the postmaster failed to start. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
