Re: [BUGS] My investigations of the postmaster Bus error
gerbil started failing with bus errors some time ago. We were finally able to 'fix it' by clearing out the CVS checkout, but the first failure could have been legitimate. See http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=gerbil&dt=2005-08-26%2009:18:41 Hope this helps... On Tue, Oct 11, 2005 at 09:13:15PM +0200, Martin Pitt wrote: > Hi PostgreSQL developers! > > There have already been some reports about the mysterious Bus error > that postmaster dies with on some architectures. Since that bites > pretty hard, I did some investigations and tests on various > architectures with various configurations. > > As background, Debian currently builds with gcc 4.0.2 by default, and > I use the latest 7.4.9 and 8.0.4 PostgreSQL versions. The default is > to build with -O2. > > Here are the results: > > * On i386, PowerPC, AMD 64, S/390, arm, and Alpha all versions work >fine with all tested compiler versions (gcc 3.3.3 and 4.0.2). > > * On IA 64, HP PARISC, and sparc postmaster 7.4 and 8.0 fail with a >bus error when ran from initdb. It works fine as soon as I > >- build with gcc 3.3 or >- build with -O0 or >- run postmaster through initdb under gdb (grumpf) or >- run postmaster through initdb under strace or >- run postmaster directly (not through initdb). > >Yay Heisenbugs. :-/ > >Also, at least 8.1 on sparc works also well with gcc 4.0 and -O2. > > * And then there is MIPS, which really sucks. It constantly crashes >in all configurations I tried it with: > >8.0 with gcc-4.0 -O2 >8.0 with gcc-4.0 -O0 >8.0 with gcc-3.3 -O2 >8.0 with gcc-3.3 -O2 and --disable-spinlocks >7.4 with gcc-4.0 -O2 original without any patches >7.4 with gcc-3.3 -O2 with recent MIPS spinlock patch > >This also produces an usable backtrace: > >Starting program: > > /home/mpitt/8.0/postgresql-8.0-8.0.3/debian/tmp/usr/lib/postgresql/8.0/bin/postmaster > >Program received signal SIGBUS, Bus error. >0x006e4f80 in InitializeGUCOptions () at guc.c:2360 >2360*conf->variable = >conf->reset_val; >(gdb) bt >#0 0x006e4f80 in InitializeGUCOptions () at guc.c:2360 >#1 0x005c7f68 in PostmasterMain (argc=1, argv=0x100539e0) at > postmaster.c:439 >#2 0x0056f874 in main (argc=1, argv=0x100539e0) at main.c:268 > >Some weeks ago I tracked down the particular variable it fails on >(some float variable; unfortunately I forgot the name, but if it is >important, I can redo the research), but I did not find any >datatype mismatch or similar obvious things. > > Does anybody have an idea about these bus errors? Also, if somebody > wants to track down the MIPS bug: I can offer temporary ssh access to > a Debian sid with all required build dependencies, gdb, and the like > for debugging. > > Thanks and have a nice day! > > Martin > > -- > Martin Pitthttp://www.piware.de > Ubuntu Developer http://www.ubuntu.com > Debian Developer http://www.debian.org > > In a world without walls and fences, who needs Windows and Gates? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] .pgpass does not work for createlang
Michael Fuhr <[EMAIL PROTECTED]> writes: > On Tue, Oct 11, 2005 at 11:16:40AM -0700, John Shin wrote: >> Tried many diffent ways but nothing seems to stick for createlang. >> .pgpass works for all others (createdb, dropdb, createuser, dropuser, >> etc.) >> -bash-3.00$ createdb test -h localhost -U postgres >> CREATE DATABASE > Hmmm...this command fails with "too many command-line arguments" > on both FreeBSD and Solaris (8.0.4 built from source on both), so > I wonder if your build is using a getopt_long() that behaves > differently than what I'm using. Might not matter, though. That syntax does work for me on FC4, so probably the issue is GNU getopt_long versus other implementations (likely, our own port/ code). I don't think it's relevant though, since John exhibited a failure even while using the "standard" command line syntax. The whole thing is more than passing strange. createlang uses exactly the same connection code as the other "scripts" binaries, so there's no obvious reason why it would behave differently. I concur with the suggestion to try strace'ing it and see where the behavior starts to vary from, say, createdb. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] .pgpass does not work for createlang
[Please copy the mailing list on replies so others can participate in and learn from the discussion.] On Tue, Oct 11, 2005 at 11:16:40AM -0700, John Shin wrote: > Tried many diffent ways but nothing seems to stick for createlang. > .pgpass works for all others (createdb, dropdb, createuser, dropuser, > etc.) [snip] > -bash-3.00$ createdb test -h localhost -U postgres > CREATE DATABASE Hmmm...this command fails with "too many command-line arguments" on both FreeBSD and Solaris (8.0.4 built from source on both), so I wonder if your build is using a getopt_long() that behaves differently than what I'm using. Might not matter, though. > -bash-3.00$ createlang -h localhost -U postgres plpgsql test > Password: Have you done a process trace (strace, ktrace, truss, etc.) to see if createlang is even looking for .pgpass? Does it work if you set the PGUSER environment variable instead of using the -U option? You mentioned FC4, so maybe Tom Lane or somebody more familiar with that platform has some ideas about what's happening. -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] My investigations of the postmaster Bus error
Hi PostgreSQL developers! There have already been some reports about the mysterious Bus error that postmaster dies with on some architectures. Since that bites pretty hard, I did some investigations and tests on various architectures with various configurations. As background, Debian currently builds with gcc 4.0.2 by default, and I use the latest 7.4.9 and 8.0.4 PostgreSQL versions. The default is to build with -O2. Here are the results: * On i386, PowerPC, AMD 64, S/390, arm, and Alpha all versions work fine with all tested compiler versions (gcc 3.3.3 and 4.0.2). * On IA 64, HP PARISC, and sparc postmaster 7.4 and 8.0 fail with a bus error when ran from initdb. It works fine as soon as I - build with gcc 3.3 or - build with -O0 or - run postmaster through initdb under gdb (grumpf) or - run postmaster through initdb under strace or - run postmaster directly (not through initdb). Yay Heisenbugs. :-/ Also, at least 8.1 on sparc works also well with gcc 4.0 and -O2. * And then there is MIPS, which really sucks. It constantly crashes in all configurations I tried it with: 8.0 with gcc-4.0 -O2 8.0 with gcc-4.0 -O0 8.0 with gcc-3.3 -O2 8.0 with gcc-3.3 -O2 and --disable-spinlocks 7.4 with gcc-4.0 -O2 original without any patches 7.4 with gcc-3.3 -O2 with recent MIPS spinlock patch This also produces an usable backtrace: Starting program: /home/mpitt/8.0/postgresql-8.0-8.0.3/debian/tmp/usr/lib/postgresql/8.0/bin/postmaster Program received signal SIGBUS, Bus error. 0x006e4f80 in InitializeGUCOptions () at guc.c:2360 2360*conf->variable = conf->reset_val; (gdb) bt #0 0x006e4f80 in InitializeGUCOptions () at guc.c:2360 #1 0x005c7f68 in PostmasterMain (argc=1, argv=0x100539e0) at postmaster.c:439 #2 0x0056f874 in main (argc=1, argv=0x100539e0) at main.c:268 Some weeks ago I tracked down the particular variable it fails on (some float variable; unfortunately I forgot the name, but if it is important, I can redo the research), but I did not find any datatype mismatch or similar obvious things. Does anybody have an idea about these bus errors? Also, if somebody wants to track down the MIPS bug: I can offer temporary ssh access to a Debian sid with all required build dependencies, gdb, and the like for debugging. Thanks and have a nice day! Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates? signature.asc Description: Digital signature
Re: [BUGS] .pgpass does not work for createlang
On Mon, Oct 10, 2005 at 06:25:59PM -0700, John Shin wrote: > It seems that for v8.0.4 the createlang will not take .pgpass inputs and > always prompts for password. Is this broken for the new version? Well, > now I have to type in the password for my database script. > > -bash-3.00$ createdb test -h localhost -U postgres > CREATE DATABASE Is that the exact command you ran? As shown it should fail with a syntax error because the options are in the wrong place: % createdb test -h localhost -U postgres createdb: too many command-line arguments (first is "localhost") Try "createdb --help" for more information. > -bash-3.00$ createlang plpgsql test -h localhost -U postgres > Password: Likewise: % createlang plpgsql test -h localhost -U postgres createlang: too many command-line arguments (first is "-h") Try "createlang --help" for more information. Use the --help option or consult the createlang documentation to see the correct order of options and arguments. It works fine here with .pgpass if the syntax is correct; have you run "createlang --version" to verify that you're running the 8.0.4 version? -- Michael Fuhr ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1954: Bug in to_date('09-10-2005', 'dd-mm-yyyy')
Antonio Molina wrote:
The following bug has been logged online:
Bug reference: 1954
Logged by: Antonio Molina
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3
Operating system: Linux
Description:Bug in to_date('09-10-2005', 'dd-mm-')
Details:
We did have a error using TO_DATE() function with 09-10-2005 the result is
08-10-2005.
Works OK in 7.4 here. Does it work for other dates, and is that a
daylight-saving-time (or summer-time) change-over date in your locale?
--
Richard Huxton
Archonet Ltd
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #1951: Multiple instances of postgres.exe running
> Bug reference: 1951 > Logged by: Terry Leffler > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.04 > Operating system: windows 2000 > Description:Multiple instances of postgres.exe running > Details: > > Hi, > > I have seen multiple instances of postgres.exe running in my > task manager. > Right now it is 6 separate instances. I can reboot and > (postgresql starts as a service) I will see 4 instances of > postgres.exe. > > I can do "SELECT * FROM pg_stat_activity" and I receive: > > 1;"template1";1720;1;"postgres";"";"" > 17262;"TurningRocks";584;1;"postgres";" enabled>";"" > 17262;"TurningRocks";808;1;"postgres";" enabled>";"" This is absolutely normal. The first four are the bgwriter, the logger and the two stats processees. The other are the backends serving active connections. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #1951: Multiple instances of postgres.exe running
The following bug has been logged online: Bug reference: 1951 Logged by: Terry Leffler Email address: [EMAIL PROTECTED] PostgreSQL version: 8.04 Operating system: windows 2000 Description:Multiple instances of postgres.exe running Details: Hi, I have seen multiple instances of postgres.exe running in my task manager. Right now it is 6 separate instances. I can reboot and (postgresql starts as a service) I will see 4 instances of postgres.exe. I can do "SELECT * FROM pg_stat_activity" and I receive: 1;"template1";1720;1;"postgres";"";"" 17262;"TurningRocks";584;1;"postgres";"";"" 17262;"TurningRocks";808;1;"postgres";"";"" Thanks ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #1952: Doc 32.4 example
The following bug has been logged online: Bug reference: 1952 Logged by: incheol yang Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.3, 8.0.4 Operating system: linux Description:Doc 32.4 example Details: You said like this => DELETE FROM ttest; INFO: trigf (fired before): there are 2 rows in ttest INFO: trigf (fired after ): there are 1 rows in ttest INFO: trigf (fired before): there are 1 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest ^^ remember what we said about visibility. DELETE 2 but I got different output. vela=# delete from ttest; ì ë³´: trigf (fired before): there are 2 rows in ttest ì ë³´: trigf (fired before): there are 1 rows in ttest ì ë³´: trigf (fired after ): there are 0 rows in ttest ì ë³´: trigf (fired after ): there are 0 rows in ttest DELETE 2 Is this my mistake? # This is my entire list vela=# \i MakeTrigger.sql DROP TABLE DROP FUNCTION CREATE TABLE CREATE FUNCTION CREATE TRIGGER CREATE TRIGGER vela=# insert into ttest values (null); ì ë³´: trigf (fired before): there are 0 rows in ttest INSERT 0 0 vela=# insert into ttest values (1); ì ë³´: trigf (fired before): there are 0 rows in ttest ì ë³´: trigf (fired after ): there are 1 rows in ttest INSERT 117771 1 vela=# insert into ttest select x *2 from ttest; ì ë³´: trigf (fired before): there are 1 rows in ttest ì ë³´: trigf (fired after ): there are 2 rows in ttest INSERT 117772 1 vela=# update ttest set x = null where x = 2; ì ë³´: trigf (fired before): there are 2 rows in ttest UPDATE 0 vela=# update ttest set x = 4 where x = 2; ì ë³´: trigf (fired before): there are 2 rows in ttest ì ë³´: trigf (fired after ): there are 2 rows in ttest UPDATE 1 vela=# delete from ttest; ì ë³´: trigf (fired before): there are 2 rows in ttest ì ë³´: trigf (fired before): there are 1 rows in ttest ì ë³´: trigf (fired after ): there are 0 rows in ttest ì ë³´: trigf (fired after ): there are 0 rows in ttest DELETE 2 vela=# ---(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
[BUGS] .pgpass does not work for createlang
It seems that for v8.0.4 the createlang will not take .pgpass inputs and always prompts for password. Is this broken for the new version? Well, now I have to type in the password for my database script. -bash-3.00$ createdb test -h localhost -U postgres CREATE DATABASE -bash-3.00$ createlang plpgsql test -h localhost -U postgres Password: Running FC4 and PostgreSQL 8.0.4 John
[BUGS] BUG #1954: Bug in to_date('09-10-2005', 'dd-mm-yyyy')
The following bug has been logged online:
Bug reference: 1954
Logged by: Antonio Molina
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3
Operating system: Linux
Description:Bug in to_date('09-10-2005', 'dd-mm-')
Details:
We did have a error using TO_DATE() function with 09-10-2005 the result is
08-10-2005.
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #1953: trigger action on delete
The following bug has been logged online: Bug reference: 1953 Logged by: incheol yang Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: fedora core 4 Description:trigger action on delete Details: kernel version 2.6.13-1.1526_FC4 CPU AMD ATHLON 1G Hz kernel version 2.6.13-1.1526_FC4 rpm postgresql-8.0.4-2.FC4.1 db encoded by UNICODE _int.sql contrib was appended source code was copied by mouse. cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) cc -fpic -c trigf.c -I/usr/include/pgsql/server cc -shared -o trigf.so trigf.o === 8.0.4 Document chapter 32.4 === INSERT, INSERT INTO, UPDATE commands had same output, but => DELETE FROM ttest; INFO: trigf (fired before): there are 2 rows in ttest INFO: trigf (fired after ): there are 1 rows in ttest INFO: trigf (fired before): there are 1 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest ^^ fired before -> after -> before -> after === My output === => DELETE FROM ttest; INFO: trigf (fired before): there are 2 rows in ttest INFO: trigf (fired before): there are 1 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest fired before -> before -> after -> after Is this my fault? ~ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
Bruce Momjian writes: >> Where does textcat fit into things? > textcat is the internal function mapped to ||. It isn't documented > anywhere for general use. It does show up in psql \df though. I > suppose the bug reporter could use that, but it isn't portable to other > database systems. textcat only handles the two-input case, however. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1947: Enhancement Request - CONCAT() function
Klint Gore wrote: > On Mon, 10 Oct 2005 23:45:03 -0400 (EDT), Bruce Momjian > wrote: > > Oracle has a tendency to keep things around forever, which is nice, but > > over the years it produces a system with lots of strange features that > > make the system hard to use. PostgreSQL has a tendency to remove old, > > unused stuff over time to keep the system easy to understand. This is > > part of the reason we have not added CONCAT, because it doesn't really > > add new functionality to the vast majority of our users. > > > > Sure, if someone wants to write scripts that work with PostgreSQL and > > Oracle EBCDIC machines, it would be nice to have, but for 99% of our > > users, it is just added cruft, and we have a tendency to try to reduce > > cruft rather than make 1% of people happy, especially when the > > extensibility system of PostgreSQL allows users to create their own > > CONCAT functions if they desire. > > Where does textcat fit into things? textcat is the internal function mapped to ||. It isn't documented anywhere for general use. It does show up in psql \df though. I suppose the bug reporter could use that, but it isn't portable to other database systems. -- 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] BUG #1955: trigger action on delete
"incheol yang" <[EMAIL PROTECTED]> writes: > => DELETE FROM ttest; > INFO: trigf (fired before): there are 2 rows in ttest INFO: trigf (fired > before): there are 1 rows in ttest INFO: trigf (fired after ): there are 0 > rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest > fired before -> before -> after -> after > Is this my fault? I think this is a documentation bug. I'm not sure the example output was ever correct, but it's certainly wrong now. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #1955: trigger action on delete
The following bug has been logged online: Bug reference: 1955 Logged by: incheol yang Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: fedora core 4 Description:trigger action on delete Details: kernel : version 2.6.13-1.1526_FC4 CPU: AMD ATHLON 1G Hz kernel version rpm postgresql-8.0.4-2.FC4.1 db encoded by UNICODE _int.sql contrib was appended source code was copied by mouse. cc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) cc -fpic -c trigf.c -I/usr/include/pgsql/server cc -shared -o trigf.so trigf.o cp trigf.so /usr/lib/pgsql/. === 8.0.4 Document chapter 32.4 === INSERT, INSERT INTO, UPDATE commands had same output, but => DELETE FROM ttest; INFO: trigf (fired before): there are 2 rows in ttest INFO: trigf (fired after ): there are 1 rows in ttest INFO: trigf (fired before): there are 1 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest fired before -> after -> before -> after === My output === => DELETE FROM ttest; INFO: trigf (fired before): there are 2 rows in ttest INFO: trigf (fired before): there are 1 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest INFO: trigf (fired after ): there are 0 rows in ttest fired before -> before -> after -> after Is this my fault? ---(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] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000
The antivirus is CA eTrust EZ v 7.0.6.7. I cannot put back the antivirus on that server because it is now in production mode. Jean-Pierre Pelletier - Original Message - From: "Qingqing Zhou" <[EMAIL PROTECTED]> To: Sent: Friday, October 07, 2005 3:08 PM Subject: Re: [BUGS] Possibly corrupted shared memory, PostgreSQL 8.1 beta2, Windows 2000 ""Jean-Pierre Pelletier"" <[EMAIL PROTECTED]> wrote Turning off the antivirus fixed the problem. We haven't have any read/write/open error in more than two days. Thank you very much for your help and keep up the good work. You are welcome :-) But I still suspect if this really solves the problem ... by the way, may I know what anti-virus software are you using? And, if it is possible, can you please turn on the anti-virus software again and check the GetLastError()? A more detailed "guess" of the problem is here: http://archives.postgresql.org/pgsql-hackers/2005-07/msg00489.php Thanks a lot, Qingqing ---(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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
