[BUGS] abstime bug
# select '1901/12/14 1:00'::abstime; abstime 2038-01-19 07:22:24+08 (1 row) ---(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] Postmaster already running !!!
Hi, only remove postmaster.pid (NO clean up) good look. Jhon Carrillojdigital (a) cantv.net Caracas - Venezuela - Original Message - From: Sivaraman K.G To: pgsql-bugs@postgresql.org Sent: Friday, July 22, 2005 2:30 AM Subject: [BUGS] Postmaster already running !!! Hi, I am running PostgreSQL version 8.0 in Solaris 8. I am starting the postmaster when the system is coming up. I am facing the following problem : FATAL: lock file "/data/ALAsm/PGSQL/data/postmaster.pid" already exists HINT: Is another postmaster (PID 448) running in data directory "/data/ALAsm/PGSQL/data"? is coming, eventhough postmaster wasn't running and postmaster fail to start, which makes my system to go down (due to my script). I have to manually clean up the postmaster.pid from the directory /data/ALAsm/PGSQL/data (from where I have initialized the database using initdb and running the postmaster). Can anyone help what is the problem here ?. Also, I got another problem. LOG: could not bind IPv6 socket: Cannot assign requested address HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. LOG: could not bind socket for statistics collector: Cannot assign requested address LOG: database system was interrupted at 2005-07-21 15:05:15 CDT LOG: checkpoint record is at 0/E06260 LOG: redo record is at 0/E06260; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 174106; next OID: 25721 LOG: database system was not properly shut down; automatic recovery in progress LOG: record with zero length at 0/E062A0 LOG: redo is not required PANIC: could not access status of transaction 174106 DETAIL: could not read from file "/data/ALAsm/PGSQL/data/pg_clog/" at offset 40960: Error 0 LOG: startup process (PID 501) was terminated by signal 6 LOG: aborting startup due to startup process failure After this, postmaster is not running and the system got rebooted continuously. In this case, I have to manually cleanup all the database and run initdb again to setup the database. Can any one help, what is the problem?. Thanks Siva -- K.G.Sivaraman, Axes Technologies (I) Pvt Ltd "The only SERVICE to be done for our lower classes is to give them EDUCATION, to develop their lost individuality" - Swami Vivekananda
Re: [BUGS] abstime bug
jw wrote: # select '1901/12/14 1:00'::abstime; abstime 2038-01-19 07:22:24+08 (1 row) Current CVS shows: test= select '1901/12/14 1:00'::abstime; abstime 1901-12-14 01:00:00-05 (1 row) What PostgreSQL version are you using? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] abstime bug
On Fri, Jul 22, 2005 at 10:15:40AM -0400, Bruce Momjian wrote: Current CVS shows: test= select '1901/12/14 1:00'::abstime; abstime 1901-12-14 01:00:00-05 (1 row) Depends on your timezone: SET TimeZone TO 'US/Eastern'; SELECT '1901/12/14 1:00'::abstime; abstime 1901-12-14 01:00:00-05 (1 row) SET TimeZone TO 'Asia/Hong_Kong'; SELECT '1901/12/14 1:00'::abstime; abstime 2038-01-19 07:51:40+08 (1 row) I'd guess this is due to the 32-bitness of abstime. Those timestamps are around the min and max values of a 32-bit timestamp based on the traditional Unix epoch. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] abstime bug
Michael Fuhr wrote: On Fri, Jul 22, 2005 at 10:15:40AM -0400, Bruce Momjian wrote: Current CVS shows: test= select '1901/12/14 1:00'::abstime; abstime 1901-12-14 01:00:00-05 (1 row) Depends on your timezone: SET TimeZone TO 'US/Eastern'; SELECT '1901/12/14 1:00'::abstime; abstime 1901-12-14 01:00:00-05 (1 row) SET TimeZone TO 'Asia/Hong_Kong'; SELECT '1901/12/14 1:00'::abstime; abstime 2038-01-19 07:51:40+08 (1 row) I'd guess this is due to the 32-bitness of abstime. Those timestamps are around the min and max values of a 32-bit timestamp based on the traditional Unix epoch. Yea, I see the same thing in 8.0.X. I don't think abstime should be used in that date range, timestamp is a better solution. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #1723: array_cat() bug when passed empty array
Dave Chapeskie [EMAIL PROTECTED] writes: On Mon, Jun 20, 2005 at 03:44:24PM -0400, Tom Lane wrote: This makes it perfectly clear that the problem is that exec_assign_value must copy the given value before it frees the old, just in case they're the same. (Hmm, I wonder if we can shortcircuit the whole thing ...) Anyone working on fixing this? I'd have tried but I didn't want to dive into exec_assign_value() and exec_cast_value(). Done some time ago, I think [ digs in CVS log... ] yeah, here it is: 2005-06-20 16:44 tgl * src/pl/plpgsql/src/: pl_exec.c (REL7_3_STABLE), pl_exec.c (REL7_4_STABLE), pl_exec.c (REL7_2_STABLE), pl_exec.c (REL8_0_STABLE), pl_exec.c: plpgsql's exec_assign_value() freed the old value of a variable before copying/converting the new value, which meant that it failed badly on var := var if var is of pass-by-reference type. Fix this and a similar hazard in exec_move_row(); not sure that the latter can manifest before 8.0, but patch it all the way back anyway. Per report from Dave Chapeskie. You can get the patches from our CVS server. http://developer.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c regards, tom lane ---(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] abstime bug
Bruce Momjian pgman@candle.pha.pa.us writes: Michael Fuhr wrote: I'd guess this is due to the 32-bitness of abstime. Those timestamps are around the min and max values of a 32-bit timestamp based on the traditional Unix epoch. Yea, I see the same thing in 8.0.X. I don't think abstime should be used in that date range, timestamp is a better solution. It's still a bug though; if the value is out of range, abstimein should reject it, not misconvert it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1780: JDBC driver setNull throws for BLOB and CLOB
On Fri, 22 Jul 2005, Andrus Adamchik wrote: Bug reference: 1780 PostgreSQL version: 8.0.1 Description:JDBC driver setNull throws for BLOB and CLOB columns Details: Whenver I call PreparedStatement.setNull(int, int) on BLOB or CLOB columns, an exception below occurs. Driver version: postgresql-8.0-310.jdbc3.jar. But looks like latest CVS version has the same problem. This has been fixed in CVS for the 8.0 and development drivers, we just haven't done a release in nearly three months. I'll put out a release this weekend unless there are any other outstanding fixes I'm unaware of. Kris Jurka ---(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: [JDBC] [BUGS] BUG #1780: JDBC driver setNull throws for BLOB
On Fri, 22 Jul 2005, Kris Jurka wrote: On Fri, 22 Jul 2005, Andrus Adamchik wrote: Whenver I call PreparedStatement.setNull(int, int) on BLOB or CLOB columns, an exception below occurs. Driver version: postgresql-8.0-310.jdbc3.jar. But looks like latest CVS version has the same problem. This has been fixed in CVS for the 8.0 and development drivers, we just haven't done a release in nearly three months. I'll put out a release this weekend unless there are any other outstanding fixes I'm unaware of. Actually looking more closely, this was fixed in build 311 which is available, but we should still put out a new release for other fixes. Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] abstime bug
Michael Fuhr [EMAIL PROTECTED] writes: SET TimeZone TO 'Asia/Hong_Kong'; SELECT '1901/12/14 1:00'::abstime; abstime 2038-01-19 07:51:40+08 (1 row) I'd guess this is due to the 32-bitness of abstime. Those timestamps are around the min and max values of a 32-bit timestamp based on the traditional Unix epoch. Fixed in CVS tip: regression=# SET TimeZone TO 'Asia/Hong_Kong'; SET regression=# SELECT '1901/12/14 1:00'::abstime; abstime - invalid (1 row) Doesn't seem important enough to back-patch, though. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
