[BUGS] pg_ctl telling only half the truth
Guess what happend here: [EMAIL PROTECTED] pg80]$ bin/pg_ctl -D data -l log start postmaster starting [EMAIL PROTECTED] pg80]$ No, postmaster was not starting - it was configured to listen on the default port - and there was already another postmaster running on 5432. This information was of course in the log file, but pg_ctl should have said that the postmaster did not start successfully. -- Markus Bertheau <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 8: explain analyze is your friend
[BUGS] Killed backend won't rollback transaction?
Dear Gurus, Version: PostgreSQL 7.4.3 on Linux. I have two transactions trying to insert the same value in a unique index (pkey). Tested and if I simpy try two plain sql backends, everything's ok. However, mine is a silly scenario. Obviously, the first one locks something (I assume the tuple) since the other one goes waiting. If I end this transaction (either by COMMIT or ROLLBACK), the other transaction resumes (either by pkey violation error or successful insert). BUT if I kill the first transaction (with standard (15 Terminate) signal), the second one stucks in "waiting". I know it's not recommended to "kill -9 the postmaster", but it's plain "kill", and I couldn't circumvent it. What happend is that I * called a plpgsql function that inserted in this pkey, then * called a C function that * called system() that * called php that inserted the same value via another connection, sentenced to waiting. The process hung, with no cancellation possible (the backend wrote "Cancel request sent" but nothing happened -- system() ignores interrupts). I fixed the lock, but I wondered if it's considered a bug. TIA, G. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug in pgAdminIII or in pg 8 beta3 ?
Thank's for all I upgrade my pg8 to beta 4 and I now it's all ok . I didn't realize that I had checked this option on install of beta 3. Sorry :( Magnus Hagander wrote: No bug; these objects exist in the template1 database - someone created them there - so they get copied into every new database. This is a _feature_. It lets you ensure that every new database contains certain objects. I believe tsearch2 is part of the install in Magnus' .mxi Windows Installer version. It is indeed installed. The activation of the module in 'template1' is optional and *not* enabled by default, though. But there is a checkbox for it... //Magnus
Re: [BUGS] pg_ctl telling only half the truth
Markus Bertheau <[EMAIL PROTECTED]> writes: > Guess what happend here: > [EMAIL PROTECTED] pg80]$ bin/pg_ctl -D data -l log start > postmaster starting > [EMAIL PROTECTED] pg80]$ > No, postmaster was not starting - it was configured to listen on the > default port - and there was already another postmaster running on 5432. > This information was of course in the log file, but pg_ctl should have > said that the postmaster did not start successfully. It did not say that the postmaster had started; it said it was starting, which was true. If you want it to wait around to verify whether the postmaster started OK, use the -w switch. regards, tom lane ---(end of broadcast)--- TIP 3: 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] pg_ctl telling only half the truth
Ð ÐÑÐ, 05.11.2004, Ð 16:46, Tom Lane ÐÐÑÐÑ: > Markus Bertheau <[EMAIL PROTECTED]> writes: > > Guess what happend here: > > [EMAIL PROTECTED] pg80]$ bin/pg_ctl -D data -l log start > > postmaster starting > > [EMAIL PROTECTED] pg80]$ > > > No, postmaster was not starting - it was configured to listen on the > > default port - and there was already another postmaster running on 5432. > > This information was of course in the log file, but pg_ctl should have > > said that the postmaster did not start successfully. > > It did not say that the postmaster had started; it said it was starting, > which was true. If you want it to wait around to verify whether the > postmaster started OK, use the -w switch. Why is the -w switch not on by default then? (I guess this also answers the question why it is there at all - i.e. why you have to be able to not wait for the postmaster to start.) Thanks -- Markus Bertheau <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Killed backend won't rollback transaction?
=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?= <[EMAIL PROTECTED]> writes: > BUT if I kill the first transaction (with standard (15 Terminate) signal), > the second one stucks in "waiting". SIGTERM on individual backends is not recommended or supported. FWIW, though, I could not duplicate this bug report. Are you sure you know what the second one was really waiting on? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #1306: locale related issue.
The following bug has been logged online: Bug reference: 1306 Logged by: David Dick Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Beta Operating system: Debian (Woody) with a Linux 2.6.7 kernel Description:locale related issue. Details: in response to; tar -jxf postgresql-8.0.0beta4.tar.bz2 cd postgresql-8.0.0beta4 ./configure make check combination, i received the following message. postgres 7.4.3 makes check fine *snip* /bin/sh ./pg_regress --temp-install --top-builddir=../../.. --schedule=./parallel_schedule --multibyte=SQL_ASCII == creating temporary installation== == initializing database system == == starting postmaster== running on port 65432 with pid 11316 == creating database "regression" == CREATE DATABASE pg_regress: could not set database default locales make[2]: *** [check] Error 2 rm regress.o make[2]: Leaving directory `/home/dave/postgresql-8.0.0beta4/src/test/regress' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/dave/postgresql-8.0.0beta4/src/test' make: *** [check] Error 2 [EMAIL PROTECTED]:~/postgresql-8.0.0beta4$ [EMAIL PROTECTED]:~$ uname -a Linux summit 2.6.7 #1 SMP Sun Jul 18 08:02:18 EST 2004 i686 unknown Sorry for the brevity of the report. Would be happy to respond with more detail if requested. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #1306: locale related issue.
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes: > CREATE DATABASE > pg_regress: could not set database default locales This is most likely not actually locale-related at all; it's probably got something to do with a failure to start psql. Please remove the "2>/dev/null" in the pg_regress script at the point where this error would be reported, so you can see what the problem really is. (Yes, we've done that in CVS tip...) regards, tom lane ---(end of broadcast)--- TIP 3: 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 #1306: locale related issue.
David Dick <[EMAIL PROTECTED]> writes: > /home/dave/postgresql-8.0.0beta4/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql: > > relocation error: > /home/dave/postgresql-8.0.0beta4/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/psql: > > undefined symbol: PQserverVersion > pg_regress: could not set database default locales Apparently psql is picking up an old libpq.so version from /usr/local/pgsql/lib. You may need to go ahead and install the newer version. Or if that doesn't sound like a good plan, reconfigure and rebuild with an installation --prefix that doesn't match the existing older installation. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] domain on bit(N) type produces strange results
Creating a domain on bit(N) doesn't seem to work as expected when casting to the domain type. CREATE DOMAIN bit4 AS bit(4); SELECT 7::bit(4), 7::bit4; bit | bit4 --+-- 0111 | 1000 (1 row) Reported in #postgresql by msw_alt. Kris Jurka ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] domain on bit(N) type produces strange results
Kris Jurka <[EMAIL PROTECTED]> writes: > Creating a domain on bit(N) doesn't seem to work as expected when casting > to the domain type. > CREATE DOMAIN bit4 AS bit(4); > SELECT 7::bit(4), 7::bit4; > bit | bit4 > --+-- > 0111 | 1000 > (1 row) What's going on here is that "7::bit4" is implemented as "7::bit::bit(4)", and since 7::bit is taken to mean 7::bit(1), the result follows. Bit is the only typmod-using datatype for which casting to the type with typmod -1 risks discarding information. In a brief look I'm not sure whether this can easily be fixed without introducing unwanted side-effects. regards, tom lane ---(end of broadcast)--- TIP 3: 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
