Re: [BUGS] BUG #3948: date/time functions returning wrong value
On Sun, Feb 10, 2008 at 09:33:46PM -0500, Tom Lane wrote: > 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 :-(. > I'm not sure there's any point in trying to be a lot better than > it is about timekeeping. In particular, even if the user has set > the displayed local time correctly, what Windows will tell us the > UTC time is depends entirely on its idea of the timezone offset. > If we have a different idea of the timezone offset, all it will buy > us is complaints from users that our time is wrong. > > (Now, this pessimistic view of things might be obsolete if Windows > systems commonly get their UTC time from NTP, as is standard on > Linux and Mac these days. I hadn't heard that Microsoft was up > to speed on that, though --- if they did, I think it'd force them > to be a whole lot more careful keeping their local timezone knowledge > up to date ...) Since Windows 2000, all domain members in a Windows domain member machines will synchronize their time with NTP. It's a requirement of Kerberos that the clocks don't drift. Recommended best practice is to have your domain controller sync to either an external source on the net or to a GPS. Since Windows 2000, there has been an NTP client included in Windows. Since Windows XP, I think (could be 2000), all non-domain machines will ntp-synchronize with servers at microsoft by default. Since Windows NT, it's been possible and recommended to synchronize all members of a domain to the domain controllers with the "net time" tools available. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3947: Unable to Initialize Data Cluster
On Feb 11, 2008 3:11 PM, Fusion Software (UK) Ltd <[EMAIL PROTECTED]> wrote: > > > Glad you're on the case. Please keep me posted as we have a number of > installations coming up in the next couple of months and we'd much rather > use 8.3 if at all possible. Can you check one thing for me please - on the machine that hangs then fails to start the service, do you see netlogon starting and more or less immediately stopping in the eventlog? You may also see notices about PostgreSQL failing to start because of netlogon. If so (and this might be worth trying in any case), in the Services control panel applet, please edit the PostgreSQL service and set the service user account to .\postgres instead of \postgres as it probably is at the moment. Does the service start then? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3948: date/time functions returning wrong value
Dear All, I installed 8.2.6.2 and solved my problem. I set Windows time zone to "Caracas" and PostgreSQL "America/Caracas" and now they both give me the right time. WARNING: not only people in Venezuela but also people in Bolivia is affected by this problem. As you might recall, Windows used to have a single time zone for both countries, namely "Caracas/La Paz". If now you set Windows time zone to "La Paz", PostgreSQL 8.2.6.2 will use "America/Caracas" unless you specify something else in postgresql.conf. In this case, Windows has Bolivia's time and PostgreSQL has Venezuela's time. So people in Bolivia should also specify timezone in postgresql.conf. Thank you all very much for your kind support. Regards, Jorge - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> To: "Alvaro Herrera" <[EMAIL PROTECTED]> Cc: "Tom Lane" <[EMAIL PROTECTED]>; "Jorge Campins" <[EMAIL PROTECTED]>; Sent: Monday, February 11, 2008 4:05 AM Subject: Re: [BUGS] BUG #3948: date/time functions returning wrong value On Sun, Feb 10, 2008 at 11:22:53PM -0300, Alvaro Herrera wrote: 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 think I see a mistake. It has Yes. And it's obviously in need of updating. two entries for "Mexico Standard Time", one of which (the one at GMT-6) is mapped to America/Mexico_City (which I think would be correct), and the other at America/La_Paz (the one at -7). This latter one I think is Yes, that's clearly a mistake :-( It'll only ever use the first one though... What's in the database is one called "Mexico Stanadrd Time" and another one called "Mexico Standard Time 2". We're missing the "2" there. It's hard to tell though -- I am not sure how does Windows define timezones. I have always been annoyed by the fact that Chilean timezone is nowhere near it's database (I think the closest is Bogota, but it's really bogus because it's not even in the same hemisphere). Fortunately this means there's no bogus entry for Chile in this struct ... My TZ database has an entry for Santiago... AFAIK, that's in Chile? -04? Took me less than 30 seconds to find in the GUI for the Timezone settings. The internal entry name is "Pacific SA Standad Time", which we map to America/Santiago. Is that actually bogus? 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. While there are a lot of bogus things about the Windows TZ database, that's not one of them. (the bogusness mostly deals with them not properly tracking changes in DST rules over time - they are only interesetd in rules that are in force *today*) //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3948: date/time functions returning wrong value
Jorge Campins wrote: Dear All, I installed 8.2.6.2 and solved my problem. I set Windows time zone to "Caracas" and PostgreSQL "America/Caracas" and now they both give me the right time. WARNING: not only people in Venezuela but also people in Bolivia is affected by this problem. As you might recall, Windows used to have a single time zone for both countries, namely "Caracas/La Paz". If now you set Windows time zone to "La Paz", PostgreSQL 8.2.6.2 will use "America/Caracas" unless you specify something else in postgresql.conf. In this case, Windows has Bolivia's time and PostgreSQL has Venezuela's time. So people in Bolivia should also specify timezone in postgresql.conf. Yeah, I've got an update that has some more timezones around here available coming up, I think that's going to help it. But always - the pg database of timezones is a lot more extensive than the Windows one, so it's always a good idea to check it out. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] Postgres para Windows Vista
Hola soy un estudiante de Ingeniería de sistemas y quisiera saber si ustedes tienen un parche de postgres para Windows Vista ya que el programa no se deja instalar en mi computador. Atentamente, FABIAN DAVID GUTIERREZ _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
Re: [BUGS] Vers. 8.3.0: "make check" fails dismally
On Wed, 06 Feb 2008 11:26:16 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Am Mittwoch, 6. Februar 2008 schrieb Mike Dowling: > >> Naively checking the build using "make check" (yes, gnu make, and as an > >> unprivaleged user) fails all tests. The apparent reason is that > >> postgres cannot find its shared libraries. > > Which platform? > An idea that comes to mind is that you had an older PG version already > installed and for some reason the dynamic loader tried to resolve > libpq.so as the older version instead of the newer one. If that's the > problem then a temporary workaround such as LD_LIBRARY_PATH is often the > best answer for running "make check", since the issue will disappear > after you "make install" anyway. No. Setting LD_LIBRARY_PATH does not work for me. The test system is looking for libpq.so.5, but not libpq.so. If I move the old /usr/lib/libpq.so.5 to somewhere else, everything works. My platforms are Debian GNU/Linux 4.0 Etch r2, kernel 2.6.22.10, GCC 4.1.2, GLIBC 2.3.6, i386 and x86_64. My configuration is: ./configure --prefix=/usr The result is below. I would be very appreciated if someone can tell me where I did wrong. [EMAIL PROTECTED] src/postgresql-8.3.0 % pwd /usr/local/src/postgresql-8.3.0 [EMAIL PROTECTED] src/postgresql-8.3.0 % export LD_LIBRARY_PATH=/usr/local/src/postgresql-8.3.0/src/test/regress/tmp_check/install/usr/lib [EMAIL PROTECTED] src/postgresql-8.3.0 % make check All of PostgreSQL successfully made. Ready to install. == removing existing temp installation== == creating temporary installation== == initializing database system == == starting postmaster== running on port 55432 with pid 20391 == creating database "regression" == CREATE DATABASE ALTER DATABASE == installing plpgsql == CREATE LANGUAGE == running regression test queries== parallel group (17 tests): boolean char name varchar text int2 int4 int8 float4 bit oid float8 numeric txid uuid enum money boolean ... FAILED char ... FAILED name ... FAILED varchar ... FAILED text ... FAILED int2 ... FAILED int4 ... FAILED int8 ... FAILED oid ... FAILED float4 ... FAILED float8 ... FAILED bit ... FAILED numeric ... FAILED txid ... FAILED uuid ... FAILED enum ... FAILED money... FAILED test strings ... FAILED test numerology ... FAILED parallel group (18 tests): point lseg box path polygon circle date time timetz timestamp timestamptz interval tinterval tstypes abstime reltime comments inet point... FAILED lseg ... FAILED box ... FAILED path ... FAILED polygon ... FAILED circle ... FAILED date ... FAILED time ... FAILED timetz ... FAILED timestamp... FAILED timestamptz ... FAILED interval ... FAILED abstime ... FAILED reltime ... FAILED tinterval... FAILED inet ... FAILED tstypes ... FAILED comments ... FAILED parallel group (5 tests): geometry horology type_sanity opr_sanity oidjoins geometry ... FAILED horology ... FAILED oidjoins ... FAILED type_sanity ... FAILED opr_sanity ... FAILED test insert ... FAILED test create_function_1... FAILED test create_type ... FAILED test create_table ... FAILED test create_function_2... FAILED parallel group (2 tests): copy copyselect copy ... FAILED copyselect ... FAILED parallel group (8 tests): constraints triggers create_misc create_operator inherit vacuum drop_if_exists create_aggregate constraints ... FAILED triggers ... FAILED create_misc ... FAILED create_aggregate ... FAILED create_operator ... FAILED inherit ... FAILED vacuum ... FAILED drop_if_exists ... FAILED parallel group (2 tests): create_index create_view create_index ... FAILED create_view ... FAILED test sanity_check ... FAILED test errors ... FAILED test select ... FAIL
Re: [BUGS] Adding new columns - bug
"Michael Andreasen" <[EMAIL PROTECTED]> writes: > There is nothing sepcial about the product table other than it has a couple > of trigger rules to post to other tables on updates of some fields (audit > log), nothing to cause this behavior. I have only noticed this happening of > this table, so I am guessing it's related to it having rules, since it's one > of the few that does. Perhaps you should post the triggers or rules you have on this table. SQL generally expands things like "select *" when you define things so it may well have stored a definition which is out of date and causes this problem. 8.3 may actually fix it for you because if they're plpgsql functions then they will replan any cached query plans. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3947: Unable to Initialize Data Cluster
On Feb 10, 2008 7:45 PM, Fusion Software (UK) Ltd <[EMAIL PROTECTED]> wrote: > > > If it would help I can always invite you to onto the desktop so you can see > for yourself what is happening? Not sure how to do that but I've seen the > facility for remote assistance on Vista. Alternatively you can go to our > support page on www.fusionsoftwareuk.co.uk and download RealVNC which will > allow the same thing. > I've actually managed to reproduce the problem here (at last) on a fresh Vista Ultimate installation. I'm seeing 2 issues: 1) The installation of the runtimes doesn't get committed during install until the InstallFinalize action. This has always been the case of course, but on Vista, things seem to have changed such that the files are not even accessible until then. Of course, initdb happens before InstallFinalize so it can rollback if there's a problem. 2) Having manually installed the runtimes, initdb will work fine but the server fails to start. The SCM reports that the dependency service netlogon failed to start (which it does unless you're on a domain). The problem is, we don't explicitly include netlogon as a dependency anywhere I can see :-( This second one is an odd one, because none of the other Vista machines I've ever tested on have been on a domain, so this should have happened before. Not missing the runtimes I can imagine as other packages may have installed them though. I'll keep investigating... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] Adding new columns - bug
I have a found a bug when adding a new column to an existing table. This happens in 6.1 and 6.2, not able to test 6.3 yet. This is the process I am doing; alter table product add column search_priority int default 0; update product set search_priority = 0; search_priority,count(*) from product group by 1; search_priority | count -+--- 0 | 26462 (1 row) This is as expected so far. However "product" is a very busy table and is updated every few seconds. If I wait for a few minutes then perform the same select again I get this; search_priority,count(*) from product group by 1; search_priority | count -+--- | 147 0 | 26315 Other processes are updating the product table, they NOT updating the "search_priority" and have no knowledge of it. It seems that when they update any column on the row the newly added field is reset to null. If I drop the the table and reload from a dump all works well, so this behavior only happens on columns added via an alter table. There is nothing sepcial about the product table other than it has a couple of trigger rules to post to other tables on updates of some fields (audit log), nothing to cause this behavior. I have only noticed this happening of this table, so I am guessing it's related to it having rules, since it's one of the few that does. Is this a known bug at all? PS, been using postgreSQL for about 6 years and this is the ONLY bug i've come across, so though i'd better report it ;)
Re: [BUGS] BUG #3947: Unable to Initialize Data Cluster
On Feb 11, 2008 4:16 PM, Fusion Software (UK) Ltd <[EMAIL PROTECTED]> wrote: > > > OK this might be something. If I look at the Application event history it > has "Waiting for server startup", then "FATAL: unrecognized configuration > parameter "redirect_stderr" and finally "Timed out waiting for server > startup". Oh - I'll bet your installer is laying down an 8.2 config file after the installation completes. You'll need to update that for 8.3. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #3948: date/time functions returning wrong value
On Sun, Feb 10, 2008 at 11:22:53PM -0300, Alvaro Herrera wrote: > 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 think I see a mistake. It has Yes. And it's obviously in need of updating. > two entries for "Mexico Standard Time", one of which (the one at GMT-6) > is mapped to America/Mexico_City (which I think would be correct), and > the other at America/La_Paz (the one at -7). This latter one I think is Yes, that's clearly a mistake :-( It'll only ever use the first one though... What's in the database is one called "Mexico Stanadrd Time" and another one called "Mexico Standard Time 2". We're missing the "2" there. > It's hard to tell though -- I am not sure how does Windows define > timezones. I have always been annoyed by the fact that Chilean timezone > is nowhere near it's database (I think the closest is Bogota, but it's > really bogus because it's not even in the same hemisphere). Fortunately > this means there's no bogus entry for Chile in this struct ... My TZ database has an entry for Santiago... AFAIK, that's in Chile? -04? Took me less than 30 seconds to find in the GUI for the Timezone settings. The internal entry name is "Pacific SA Standad Time", which we map to America/Santiago. Is that actually bogus? > 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. While there are a lot of bogus things about the Windows TZ database, that's not one of them. (the bogusness mostly deals with them not properly tracking changes in DST rules over time - they are only interesetd in rules that are in force *today*) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Adding new columns - bug
This happens in 6.1 and 6.2, not able to test 6.3 yet. Sorry typo... should be 8.x ofcourse. On 11/02/2008, Michael Andreasen <[EMAIL PROTECTED]> wrote: > > I have a found a bug when adding a new column to an existing table. This > happens in 6.1 and 6.2, not able to test 6.3 yet. > > This is the process I am doing; > > alter table product add column search_priority int default 0; > update product set search_priority = 0; > search_priority,count(*) from product group by 1; > search_priority | count > -+--- >0 | 26462 > (1 row) > > This is as expected so far. > > However "product" is a very busy table and is updated every few seconds. > If I wait for a few minutes then perform the same select again I get this; > > search_priority,count(*) from product group by 1; > search_priority | count > -+--- > | 147 >0 | 26315 > > Other processes are updating the product table, they NOT updating the > "search_priority" and have no knowledge of it. It seems that when they > update any column on the row the newly added field is reset to null. > > If I drop the the table and reload from a dump all works well, so this > behavior only happens on columns added via an alter table. > > There is nothing sepcial about the product table other than it has a > couple of trigger rules to post to other tables on updates of some fields > (audit log), nothing to cause this behavior. I have only noticed this > happening of this table, so I am guessing it's related to it having rules, > since it's one of the few that does. > > Is this a known bug at all? > > PS, been using postgreSQL for about 6 years and this is the ONLY bug i've > come across, so though i'd better report it ;) > > >
