Re: [HACKERS] Re: Beta2 ... ?
On Fri, 5 Jan 2001, Lamar Owen wrote: Ok, consider my mind changed. :-). My only concerns were, due to some feedback I have gotten, is that people would treat the RPM release as _productions_ rather than beta -- but maybe I'm just being paranoid. Just because you're paranoid doesn't mean someone isn't out to get you! But like Tom says - a beta in the name - should do it (and will for me). Lamar, Is it possible to put some variables in the spec file so I can turn off compiling the python and tcl portions. Of course I seem to remember a thread to a similar effect floating through but can't remember what the outcome was. TIA, Rod --
[HACKERS] Open documentation items
(approximately in the order in the HISTORY file) WAL -- update documentation of fsync option (runtime.sgml) TOAST -- The introductory paragraph in lobj.sgml needs some updating regarding the remaining merits of the large object system. Overhaul pg_dump (Philip Warner) -- backup.sgml could use some fresh blood after this development. New PL/pgSQL GET DIAGNOSTICS statement for SPI value access (Jan) New quote_ident() and quote_literal() functions (Jan) -- Is documented in PL/pgSQL chapter, but should be in the functions chapter as well? New SQL function setval(seq,val,bool) for use in pg_dump (Philip) -- Sequence related functions seem poorly documented in general. New CHECKPOINT command for WAL which creates new WAL log file (Vadim) New BIT and BIT VARYING types (Adriaan Joubert, Tom, me) That's about all I can see. Nice... -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] is_view seems unnecessarily slow
backend/commands/command.c has a routine is_view() that tests for view-ness by scanning pg_rewrite (all of it) to see if the given relation has any ON SELECT rules. This is only used to disallow AlterTableAddConstraint and LockTableCommand on views. While I don't care much about the performance of AlterTableAddConstraint, it does bug me that this might slow down LOCK TABLE a good deal. Any objection to replacing this routine by a test for relkind = VIEW? regards, tom lane
[HACKERS] global/pg_database ?
Posting again as even though I receive mail from hackers I am apparently not a member (registered correctly as [EMAIL PROTECTED] - from will say [EMAIL PROTECTED] - setting reply-to to [EMAIL PROTECTED] used to get around it..) psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such fi le or directory and it's true.. % ls /usr/local/pgsql/data/global 1260126112621264126917127 17130 pg_control source from Jan 3 15:59 GMT configure --enable-locale --enable-recode --enable-debug --enable-cassert --wit h-CXX all but geometry (rounding errors) pass gmake runcheck PGLIB=/usr/local/pgsql/lib PGDATA=/usr/local/pgsql/data PGDATESTYLE=European LC_ALL=en_GB.ISO8859-1 then did the initdb This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Creating directory /usr/local/pgsql/data Creating directory /usr/local/pgsql/data/base Creating directory /usr/local/pgsql/data/global Creating directory /usr/local/pgsql/data/pg_xlog Creating template1 database in /usr/local/pgsql/data/base/1 DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:51:59 DEBUG: CheckPoint record at (0, 8) DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 16384 DEBUG: database system is in production state Creating global relations in /usr/local/pgsql/data/global DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:52:03 DEBUG: CheckPoint record at (0, 108) DEBUG: Redo record at (0, 108); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 17199 DEBUG: database system is in production state Initializing pg_shadow. Enabling unlimited row width for system tables. Creating system views. Loading pg_description. Setting lastsysoid. Vacuuming database. Copying template1 to template0. Success. You can now start the database server using: /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start Any ideas? Cheers, Patrick
[HACKERS] initdb prob
Please ignore last 2 messages re psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or directory - I had another old postmaster running... Cheers, Patrick
[HACKERS] initdb prob
psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or directory and it's true.. % ls /usr/local/pgsql/data/global 1260126112621264126917127 17130 pg_control source from Jan 3 15:59 GMT configure --enable-locale --enable-recode --enable-debug --enable-cassert --with-CXX all but geometry (rounding errors) pass gmake runcheck PGLIB=/usr/local/pgsql/lib PGDATA=/usr/local/pgsql/data PGDATESTYLE=European LC_ALL=en_GB.ISO8859-1 then did the initdb This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Creating directory /usr/local/pgsql/data Creating directory /usr/local/pgsql/data/base Creating directory /usr/local/pgsql/data/global Creating directory /usr/local/pgsql/data/pg_xlog Creating template1 database in /usr/local/pgsql/data/base/1 DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:51:59 DEBUG: CheckPoint record at (0, 8) DEBUG: Redo record at (0, 8); Undo record at (0, 8); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 16384 DEBUG: database system is in production state Creating global relations in /usr/local/pgsql/data/global DEBUG: starting up DEBUG: database system was shut down at 2001-01-03 18:52:03 DEBUG: CheckPoint record at (0, 108) DEBUG: Redo record at (0, 108); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 514; NextOid: 17199 DEBUG: database system is in production state Initializing pg_shadow. Enabling unlimited row width for system tables. Creating system views. Loading pg_description. Setting lastsysoid. Vacuuming database. Copying template1 to template0. Success. You can now start the database server using: /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start Any ideas? Cheers, Patrick
[HACKERS] ERROR: cannot find attribute 10 of???
Anyone can help with that one? Warning: PostgresSQL query failed: ERROR: cannot find attribute 10 of relation pg_am in [..] Warning: 0 is not a PostgresSQL result index in Thanks in advice ineck
Re: [HACKERS] Re: Beta2 ... ?
Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... I'd like to argue for .deb Debian packages as well, for similar reasons. But I'm aware that those are harder to produce, and that Oliver Elphick is almost alone on this task. -- Emmanuel Charpentier
Re: [HACKERS] global/pg_database ?
psql: FATAL 1: cannot open /usr/local/pgsql/data/global/pg_database: No such file or directory Not sure why you are getting such a message, but it strikes me that you may have a corrupted set of sources, ie, some out-of-date files. Have you tried doing a fresh cvs checkout and build from scratch? To be more specific, I suspect that would be coming out of GetRawDatabaseInfo if compiled with OLD_FILE_NAMING defined. Possibly you have an old config.h (have you rerun configure lately?) or neglected to do a make clean before rebuilding. regards, tom lane
[HACKERS] pg_restore options issues
pg_restore has some options that are supposed to allow restoring some or all indexes/tables/triggers/etc. For example pg_restore --table restores all tables and pg_restore --table=my_table restores only the named table. The equivalent short option is -t but it does not allow restoring all tables, since it requires an argument. I suggest that an argument of '*' also means to restore all tables. Also, if you just call pg_restore without arguments it hangs waiting for input from stdin. This is a bit confusing. I suggest that stdin is used if and only if the file name argument is '-'. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] CVS regression test failure on OBSD
When I run 'make check' on the CVS version (today and for the last serveral days), I have been getting interesting failures. Some of the tests fail, but the interesting part is that not the same tests always fail. Example: bpalmer@mizer:~/APPS/pgsqldiff 1 2 1c1 boolean ... FAILED --- boolean ... ok 3c3 name ... ok --- name ... FAILED 5c5 text ... FAILED --- text ... ok 9,10c9,10 oid ... FAILED float4 ... ok --- oid ... ok float4 ... FAILED In the regression.diff file, I keep seeing this: *** ./expected/name.out Tue Jan 4 11:19:34 2000 --- ./results/name.out Sat Jan 6 16:36:34 2001 *** *** 1,124 ! -- ! -- NAME ! -- all inputs are silently truncated at NAMEDATALEN (32) characters ! -- ! -- fixed-length by reference ! SELECT name 'name string' = name 'name string' AS "True"; ! True ! -- ... ... ... ! (2 rows) ! ! DROP TABLE NAME_TBL; --- 1 ! psql: Backend startup failed == Any ideas where to look for this one? When I run the regression test WITH ANOTHER INSTANCE OF PGSQL running, I got an error telling me that I needed more SEMMNI or SEMMNS. I recompiled my kernel with the values of 1024 and 2048 respectivly, and that seems to have solved the problem, but they may still be related. Any ideas? - Brandon b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5
Re: [HACKERS] CVS regression test failure on OBSD
bpalmer [EMAIL PROTECTED] writes: ! psql: Backend startup failed Any ideas where to look for this one? In the postmaster: the fork() to launch a backend is failing. There should be a more detailed message in the postmaster's stderr log, but almost certainly it's a resource-exhaustion issue. Does your kernel enforce a per-userid limit on the number of processes, for example? regards, tom lane
Re: [HACKERS] CVS regression test failure on OBSD
In the postmaster: the fork() to launch a backend is failing. There
should be a more detailed message in the postmaster's stderr log,
but almost certainly it's a resource-exhaustion issue. Does your
kernel enforce a per-userid limit on the number of processes, for
example?
Looks like that was part of the problem. Process ulimit and openfile
limit were both problems. I have rolled up the process ulimit (soft /
hard) to 256 and the Open Files to 256.
There are still, however, 4 tests that fail.
Attached.
- Brandon
uname -a
OpenBSD mizer 2.8 a#0 i386 (2.8 snapshot NOV 6 install)
b. palmer, [EMAIL PROTECTED]
pgp: www.crimelabs.net/bpalmer.pgp5
*** ./expected/int2.out Tue Jan 4 11:19:34 2000
--- ./results/int2.out Sat Jan 6 17:56:29 2001
***
*** 14,20
INSERT INTO INT2_TBL(f1) VALUES ('-32767');
-- bad input values -- should give warnings
INSERT INTO INT2_TBL(f1) VALUES ('10');
! ERROR: pg_atoi: error reading "10": Numerical result out of range
INSERT INTO INT2_TBL(f1) VALUES ('asdf');
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
SELECT '' AS five, INT2_TBL.*;
--- 14,20
INSERT INTO INT2_TBL(f1) VALUES ('-32767');
-- bad input values -- should give warnings
INSERT INTO INT2_TBL(f1) VALUES ('10');
! ERROR: pg_atoi: error reading "10": Result too large
INSERT INTO INT2_TBL(f1) VALUES ('asdf');
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
SELECT '' AS five, INT2_TBL.*;
==
*** ./expected/int4.out Tue Mar 14 18:06:56 2000
--- ./results/int4.out Sat Jan 6 17:56:30 2001
***
*** 14,20
INSERT INTO INT4_TBL(f1) VALUES ('-2147483647');
-- bad input values -- should give warnings
INSERT INTO INT4_TBL(f1) VALUES ('1');
! ERROR: pg_atoi: error reading "1": Numerical result out of range
INSERT INTO INT4_TBL(f1) VALUES ('asdf');
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
SELECT '' AS five, INT4_TBL.*;
--- 14,20
INSERT INTO INT4_TBL(f1) VALUES ('-2147483647');
-- bad input values -- should give warnings
INSERT INTO INT4_TBL(f1) VALUES ('1');
! ERROR: pg_atoi: error reading "1": Result too large
INSERT INTO INT4_TBL(f1) VALUES ('asdf');
ERROR: pg_atoi: error in "asdf": can't parse "asdf"
SELECT '' AS five, INT4_TBL.*;
==
*** ./expected/float8.out Mon Mar 20 00:19:10 2000
--- ./results/float8.outSat Jan 6 17:56:30 2001
***
*** 241,249
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400');
ERROR: Input '-10e400' is out of range for float8
INSERT INTO FLOAT8_TBL(f1) VALUES ('10e-400');
- ERROR: Input '10e-400' is out of range for float8
INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
- ERROR: Input '-10e-400' is out of range for float8
-- maintain external table consistency across platforms
-- delete all values and reinsert well-behaved ones
DELETE FROM FLOAT8_TBL;
--- 241,247
==
*** ./expected/geometry.out Tue Sep 12 17:07:16 2000
--- ./results/geometry.out Sat Jan 6 17:56:52 2001
***
*** 114,120
| (5.1,34.5) | [(1,2),(3,4)] | (3,4)
| (-5,-12) | [(1,2),(3,4)] | (1,2)
| (10,10)| [(1,2),(3,4)] | (3,4)
! | (0,0) | [(0,0),(6,6)] | (-0,0)
| (-10,0)| [(0,0),(6,6)] | (0,0)
| (-3,4) | [(0,0),(6,6)] | (0.5,0.5)
| (5.1,34.5) | [(0,0),(6,6)] | (6,6)
--- 114,120
| (5.1,34.5) | [(1,2),(3,4)] | (3,4)
| (-5,-12) | [(1,2),(3,4)] | (1,2)
| (10,10)| [(1,2),(3,4)] | (3,4)
! | (0,0) | [(0,0),(6,6)] | (0,0)
| (-10,0)| [(0,0),(6,6)] | (0,0)
| (-3,4) | [(0,0),(6,6)] | (0.5,0.5)
| (5.1,34.5) | [(0,0),(6,6)] | (6,6)
***
*** 150,160
six |box
-+
| (2.12132034355964,2.12132034355964),(-2.12132034355964,-2.12132034355964)
! | (71.7106781186548,72.7106781186548),(-69.7106781186548,-68.7106781186548)
! | (4.53553390593274,6.53553390593274),(-2.53553390593274,-0.535533905932738)
! | (3.12132034355964,4.12132034355964),(-1.12132034355964,-0.121320343559643)
| (107.071067811865,207.071067811865),(92.9289321881345,192.928932188135)
! |
Re: [HACKERS] CVS regression test failure on OBSD
bpalmer [EMAIL PROTECTED] writes: There are still, however, 4 tests that fail. Those all look like trivial platform dependencies. Please read http://www.postgresql.org/devel-corner/docs/postgres/regress.htm http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm and submit resultmap patches as required for your platform. regards, tom lane
[HACKERS] I'm amazed we never caught this before ...
The stringToNode routines (backend/nodes/read.c and readfuncs.c) depend on a static variable that is the next-input pointer for lsptok(). Guess what happens if stringToNode is invoked recursively. (Hint: it's not good.) It's apparently not easy for this to happen, but I have a reproducible test case involving relcache flush while reading the rule action parsetree for a view. readDatum() needs to be able to look up the pg_type entry for the value it's reading, and that lookup could result in relcache flush, which would lead to an attempt to read the rule actions for any locked relcache entries --- like, say, the one we are currently trying to load. I propose fixing this by making stringToNode save and restore the entry-time value of the static pointer. (Alternatively, we could explicitly pass a pointer-to-pointer-to-char to lsptok() and every single one of the readfuncs, but that seems like way too much notational clutter.) I am not sure that is enough to fix the problem completely. It might be best to avoid calling get_typbyval() from readDatum, which could be done if we re-ordered the fields of a CONST dump so that the byval field appears before we need to read the const value itself. That means an initdb, but we've already forced an initdb for beta2 ... Marc, can you hold off wrapping beta2 for a few hours? I think this is a 'must fix'. regards, tom lane
[HACKERS] Re: I'm amazed we never caught this before ...
On Sat, 6 Jan 2001, Tom Lane wrote: The stringToNode routines (backend/nodes/read.c and readfuncs.c) depend on a static variable that is the next-input pointer for lsptok(). Guess what happens if stringToNode is invoked recursively. (Hint: it's not good.) It's apparently not easy for this to happen, but I have a reproducible test case involving relcache flush while reading the rule action parsetree for a view. readDatum() needs to be able to look up the pg_type entry for the value it's reading, and that lookup could result in relcache flush, which would lead to an attempt to read the rule actions for any locked relcache entries --- like, say, the one we are currently trying to load. I propose fixing this by making stringToNode save and restore the entry-time value of the static pointer. (Alternatively, we could explicitly pass a pointer-to-pointer-to-char to lsptok() and every single one of the readfuncs, but that seems like way too much notational clutter.) I am not sure that is enough to fix the problem completely. It might be best to avoid calling get_typbyval() from readDatum, which could be done if we re-ordered the fields of a CONST dump so that the byval field appears before we need to read the const value itself. That means an initdb, but we've already forced an initdb for beta2 ... Marc, can you hold off wrapping beta2 for a few hours? I think this is a 'must fix'. No probs ... I got the update to mk-release from Peter, so let me know when you are ready and we'll go with beta2 ...
Re: [HACKERS] CVS regression test failure on OBSD
Those all look like trivial platform dependencies. Please read http://www.postgresql.org/devel-corner/docs/postgres/regress.htm http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm and submit resultmap patches as required for your platform. Sweet. Thanks, looks like the problem is solved. Should me make note of the changes what were needed for OBSD somewhere? b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5 bpalmer@mizer:~/APPS/pgsql/src/test/regressdiff -c resultmap resultmap.orig *** resultmap Sat Jan 6 19:35:02 2001 --- resultmap.orig Sat Jan 6 19:12:57 2001 *** *** 7,13 float4/.*-qnx=float4-exp-three-digits float8/.*-bsdi=float8-small-is-zero float8/.*-freebsd=float8-small-is-zero - float8/.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/alpha.*-dec-osf.*:cc=float8-fp-exception --- 7,12 *** *** 16,22 geometry/.*-darwin=geometry-powerpc-darwin geometry/.*-freebsd=geometry-positive-zeros geometry/.*-freebsd4=geometry-positive-zeros-bsd - geometry/.*-openbsd=geometry-positive-zeros-bsd geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc --- 15,20 *** *** 45,51 int2/.*-irix6=int2-too-large int2/.*-netbsd=int2-too-large int2/.*-qnx=int2-too-large - int2/.*-openbsd=int2-too-large int2/alpha.*-dec-osf=int2-too-large int2/hppa=int2-too-large int2/i.86-pc-cygwin=int2-math-result-out-of-range --- 43,48 *** *** 62,68 int4/.*-irix6=int4-too-large int4/.*-netbsd=int4-too-large int4/.*-qnx=int4-too-large - int4/.*-openbsd=int4-too-large int4/alpha.*-dec-osf=int4-too-large int4/hppa=int4-too-large int4/i.86-pc-cygwin=int4-math-result-out-of-range --- 59,64
Re: [HACKERS] pg_restore options issues
At 22:05 6/01/01 +0100, Peter Eisentraut wrote: restores only the named table. The equivalent short option is -t but it does not allow restoring all tables, since it requires an argument. I suggest that an argument of '*' also means to restore all tables. Sounds fine. Also, if you just call pg_restore without arguments it hangs waiting for input from stdin. This is a bit confusing. I suggest that stdin is used if and only if the file name argument is '-'. Also sounds reasonable. I'm working on pg_dump at the moment, so if there is anything else, let me know. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Re: I'm amazed we never caught this before ...
OK, stringToNode changes committed. I think we're ready to go for beta2... regards, tom lane
Re: [HACKERS] CVS regression test failure on OBSD
bpalmer [EMAIL PROTECTED] writes: [ resultmap patches for OpenBSD ] Applied, thanks! Sweet. Thanks, looks like the problem is solved. Should me make note of the changes what were needed for OBSD somewhere? If there's anything that users need to know beyond the standard build instructions, perhaps we should add a doc/FAQ_OBSD ... regards, tom lane
Re: [HACKERS] CVS regression test failure on OBSD
bpalmer writes: Those all look like trivial platform dependencies. Please read http://www.postgresql.org/devel-corner/docs/postgres/regress.htm http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.htm and submit resultmap patches as required for your platform. Sweet. Thanks, looks like the problem is solved. Should me make note of the changes what were needed for OBSD somewhere? Apparently these resultmap entries were needed at some point. It wouldn't surprise me if the error messages changed between releases of the OS -- it's happened to FreeBSD as well. Perhaps they should be qualified by version. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] CVS regression test failure on OBSD
Peter Eisentraut [EMAIL PROTECTED] writes: Apparently these resultmap entries were needed at some point. I think you read the message backwards --- we were adding the entries, not removing them. (The patch was reversed as given, which is a common mistake.) As patched, the entries for OpenBSD look pretty much like those for the other flavors of BSD, which gives me a nice warm fuzzy feeling about it... regards, tom lane
[HACKERS] beta2 bundled ... will officially announce sunday evening ...
can a couple ppl check it over and make sure that nothing was overlooked
before I announce it?
Peter, I got your mk-release changes in for the docs ... the build itself
looked great, but I figure a couple of confirmations before announcing it
will at least prevent any obvious bug reports ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
Re: [HACKERS] beta2 bundled ... will officially announce sunday evening ...
The Hermit Hacker [EMAIL PROTECTED] writes: can a couple ppl check it over and make sure that nothing was overlooked before I announce it? Looks great, other than that it's missing the fixes I checked in since then ;-) regards, tom lane
Re: [HACKERS] beta2 bundled ... will officially announce sundayevening ...
On Sat, 6 Jan 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: can a couple ppl check it over and make sure that nothing was overlooked before I announce it? Looks great, other than that it's missing the fixes I checked in since then ;-) Critical enough to ditch beta2 and wrap up a quick beta3? Or I could go with the theory that I haven't announced it yet, so can bundle a new beta2 with no guilty conscious :)
[HACKERS] Oops, looks like query cancel is busted
regression=# begin; BEGIN regression=# insert into rtest_t1 values(1,2); INSERT 287918 1 regression=# select * from tenk1, tenk1 t2; -- press ^C here Cancel request sent ERROR: Query was cancelled. ERROR: Query was cancelled. FATAL 2: elog: error during error recovery, giving up! pqReadData() -- backend closed the channel unexpectedly. This probably means the backend terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Succeeded. The problem is that END_CRIT_SECTION does (in effect) if (QueryCancel) CancelQuery(); which is OK in the main line of a transaction, but definitely NOT ok when we are already recovering from an error. Like, say, the error triggered by CancelQuery. And there are END_CRIT_SECTION calls needing to be executed in that path --- the one in RecordTransactionAbort being the hardest to avoid. I think we should do two things here: 1. Alter END_CRIT_SECTION to only check for ProcDiePending. It should not attempt to sprinkle the whole system with hidden QueryCancel checks, which is what it's in effect doing now. 2. Modify CancelQuery to clear QueryCancel before elog'ing. Similarly, END_CRIT_SECTION should clear ProcDiePending before elog'ing that case. Although either one of these would be sufficient to suppress the particular case I'm seeing, I think both are good practice. For example, it is NOT a good idea to be checking for QueryCancel in the END_CRIT_SECTION at the end of RecordTransactionCommit. At that point we've already committed and raising an error is silly. So point #1 seems like a good idea. Point #2 seems like a good idea to avoid recursive errors from explicitly written QueryCancel checks in the post-elog path of control. I cannot find any such at the moment other than the one in END_CRIT_SECTION, but one might get added someday. regards, tom lane
Re: [HACKERS] beta2 bundled ... will officially announce sunday evening ...
The Hermit Hacker [EMAIL PROTECTED] writes: On Sat, 6 Jan 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: can a couple ppl check it over and make sure that nothing was overlooked before I announce it? Looks great, other than that it's missing the fixes I checked in since then ;-) Critical enough to ditch beta2 and wrap up a quick beta3? Depends whether you think query-cancel is critical. Or I could go with the theory that I haven't announced it yet, so can bundle a new beta2 with no guilty conscious :) I'd do that or nothing at all. There'll always be another bug... regards, tom lane
Re: [HACKERS] beta2 bundled ... will officially announce sundayevening ...
On Sun, 7 Jan 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: On Sat, 6 Jan 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: can a couple ppl check it over and make sure that nothing was overlooked before I announce it? Looks great, other than that it's missing the fixes I checked in since then ;-) Critical enough to ditch beta2 and wrap up a quick beta3? Depends whether you think query-cancel is critical. Or I could go with the theory that I haven't announced it yet, so can bundle a new beta2 with no guilty conscious :) I'd do that or nothing at all. There'll always be another bug... lets leave it for the next beta ... as you say, there will be other bugs, and there will be a beta3 ...
Re: [HACKERS] Re: [SQL] renaming columns... danger?
As for the latest CVS source, it looks still we have problems regarding alter table rename column and pg_dump as Grant has mentioned. Results of pg_dump is attached. test=# create table a ( aa serial primary key ); NOTICE: CREATE TABLE will create implicit sequence 'a_aa_seq' for SERIAL column 'a.aa' NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for table 'a' CREATE test=# alter TABLE a RENAME aa to new_aa; ALTER test=# \q [t-ishii@srapc1474 current]$ pg_dump test /tmp/aaa [t-ishii@srapc1474 current]$ dropdb test DROP DATABASE [t-ishii@srapc1474 current]$ createdb test CREATE DATABASE [t-ishii@srapc1474 current]$ psql test /tmp/aaa Using pager is off. You are now connected as new user t-ishii. CREATE ERROR: CREATE TABLE: column "aa" named in key does not exist UPDATE 53 ERROR: Relation 'a' does not exist invalid command \. BEGIN CREATE INSERT 18819 1 UPDATE 1 DROP COMMIT setval 1 (1 row) [t-ishii@srapc1474 current]$ psql test Welcome to psql, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit Using pager is off. test=# \dt No relations found. test=# -- attachments -- Multipart/Mixed 2/ 1 Text/Plain(guess) CoverPage* B2 Application/Octet-Stream aaa.gz 3. 0-1-2-3-4-5-6-7-8-9--
Re: [HACKERS] Re: [SQL] renaming columns... danger?
As for the latest CVS source, it looks still we have problems regarding alter table rename column and pg_dump as Grant has mentioned. Results of pg_dump is attached. Sorry, an attachmet was missing. aaa.gz
Re: [HACKERS] Re: [SQL] renaming columns... danger?
At 15:15 7/01/01 +0900, Tatsuo Ishii wrote: As for the latest CVS source, it looks still we have problems regarding alter table rename column and pg_dump as Grant has mentioned. Results of pg_dump is attached. Sorry, an attachmet was missing. I can reproduce this in 7.0.2 as well; it's because the PK attr name comes from the index relation attr names, not the original relation. I'll look into alternative queries but would welcome suggestions. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
