Re: [HACKERS] [BUGS] ECPG CONNECT TO DEFAULT segfault
On Tue, Dec 28, 2004 at 11:15:52PM -0700, Michael Fuhr wrote: PostgreSQL 8.0.0rc2, 7.4.6 Solaris 9, FreeBSD 4.11-PRERELEASE ECPG's CONNECT TO DEFAULT causes a segmentation fault. This originally came up in the Connection without database name thread in pgsql-hackers: This is exactly what I did fix with the work mentioned in the hackers thread. It should work nicely with CVS HEAD. Could you please try this? BTW Tom, I just found that my problem with PGDATABASE was a local one. It surely works, so the oracle style syntax will remain. That is you can also write EXEC SQL CONNECT username to connect to the default database using the given username. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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
[HACKERS] fmgr_oldstyle calls from 8.0.0RC2 trigger
I'm trying to implement a trigger within 8.0.0RC2. I get a segfault when the trigger is fired, valgrind reports an illegal read being the line: TriggerData *trigdata = (TriggerData *) fcinfo-context; Valgrind reports: ==941== Use of uninitialised value of size 4 ==941==at 0x3CD9C197: cache_bbox (lwgeom_triggers.c:10) ==941==by 0x825C274: fmgr_oldstyle (fmgr.c:637) ==941==by 0x81258C8: ExecCallTriggerFunc (trigger.c:1149) ==941==by 0x812646F: ExecBRUpdateTriggers (trigger.c:1525) Isn't fmgr_oldstyle the Version 0 function caller ? Shouldn't triggers be defined as Version 1 ? TIA --strk; For standing up against patentability of software, Thank You, Poland! Read the intervention:http://kwiki.ffii.org/ConsPolon041221En Send your thanks: thankyoupoland.info Read/do more: http://www.noepatents.org/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] race condition for drop schema cascade?
pgbuildfarm=# select name, operating_system, stage, count from buildsystems b, (select sysname, stage, count(*) as count from build_status where log ~ 'tablespace testspace is not empty' group by sysname, stage) as s where s.sysname=b.name; Note that the expected log has that as error message after a drop tablespace testspace;, while it should works with a drop tablespace testspace cascade;. How many of those errors are because of some other error? Like dog for intance ran out of diskspace recently and had those in the logs. I know panda also once ran out of diskspace, but the logs for that aren't available on the site anymore. When was the last time this error actually happened? Because looking at emu (which seem to have it the most) shows that it's last 30 builds are all succesful. PS: It might be nice to have an option to keep the last X days of all logs around. Kurt ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] race condition for drop schema cascade?
Kurt Roeckx wrote: pgbuildfarm=# select name, operating_system, stage, count from buildsystems b, (select sysname, stage, count(*) as count from build_status where log ~ 'tablespace testspace is not empty' group by sysname, stage) as s where s.sysname=b.name; Note that the expected log has that as error message after a drop tablespace testspace;, while it should works with a drop tablespace testspace cascade;. How many of those errors are because of some other error? Like dog for intance ran out of diskspace recently and had those in the logs. I know panda also once ran out of diskspace, but the logs for that aren't available on the site anymore. When was the last time this error actually happened? Because looking at emu (which seem to have it the most) shows that it's last 30 builds are all succesful. You're right - my query was not sufficiently specific. There have in fact been 4 failures: pgbuildfarm=# select sysname, snapshot, stage, branch from build_status where log ~ 'tablespace testspace is not empty.*tablespace testspace is not empty' and not log ~ 'No space left'; sysname | snapshot |stage | branch +-+--+ hare| 2004-12-09 05:15:05 | Check| HEAD otter | 2004-12-11 15:50:09 | Check| HEAD otter | 2004-12-15 15:50:10 | Check| HEAD gibbon | 2004-12-28 23:55:05 | InstallCheck | HEAD gibbon is a Cygwin box, otter and hare are both Debian 3.1 boxes, hare on Alpha and otter on MIPS. PS: It might be nice to have an option to keep the last X days of all logs around. You mean on the client? I'd rather not - the logs kept there are mostly intended as debugging devices. The buildfarm db keeps the log from the stage where an error occurred indefinitely. I intend to provide a way of going back through that history - at the moment you can easily see the last 30. cheers andrew ---(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: [HACKERS] fmgr_oldstyle calls from 8.0.0RC2 trigger
Sorry, my fault, just mistyped the function name in PG_FUNCTION_INFO_V1() macro. --strk; On Wed, Dec 29, 2004 at 11:08:28AM +0100, strk wrote: I'm trying to implement a trigger within 8.0.0RC2. I get a segfault when the trigger is fired, valgrind reports an illegal read being the line: TriggerData *trigdata = (TriggerData *) fcinfo-context; Valgrind reports: ==941== Use of uninitialised value of size 4 ==941==at 0x3CD9C197: cache_bbox (lwgeom_triggers.c:10) ==941==by 0x825C274: fmgr_oldstyle (fmgr.c:637) ==941==by 0x81258C8: ExecCallTriggerFunc (trigger.c:1149) ==941==by 0x812646F: ExecBRUpdateTriggers (trigger.c:1525) Isn't fmgr_oldstyle the Version 0 function caller ? Shouldn't triggers be defined as Version 1 ? TIA --strk; For standing up against patentability of software, Thank You, Poland! Read the intervention:http://kwiki.ffii.org/ConsPolon041221En Send your thanks: thankyoupoland.info Read/do more: http://www.noepatents.org/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- For standing up against patentability of software, Thank You, Poland! Read the intervention:http://kwiki.ffii.org/ConsPolon041221En Send your thanks: thankyoupoland.info Read/do more: http://www.noepatents.org/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 28 déc. 04, à 23:36, Tom Lane a écrit : Andrew Dunstan [EMAIL PROTECTED] writes: This result is now seen for HEAD on buildfarm member osprey: Yeah, I was wondering about that. It should be easy to reproduce the failure by hand (just run the tsearch regression test and then re-execute that query) --- can we see a debugger stack trace from the errfinish call? I'm trying to reproduce this. I've made an install with ./configure --prefix /data/postgresql/tests-install --enable-debug --enable--cassert Then cd contrib/tsearch gmake gmake install gmake installcheck The test fails, but differently than with the buildfarm setup (which fails consistently with the same error message each time). here is the tail of regression.diff (which indicates that the first query failed): SELECT '1'::mquery_txt; ! server closed the connection unexpectedly ! This probably means the server terminated abnormally ! before or while processing the request. ! connection to server was lost the log of the server is ERROR: group regressgroup1 does not exist NOTICE: type txtidx is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type txtidx is only a shell NOTICE: type query_txt is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type query_txt is only a shell NOTICE: type mquery_txt is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type mquery_txt is only a shell NOTICE: type gtxtidx is not yet defined DETAIL: Creating a shell type definition. NOTICE: argument type gtxtidx is only a shell LOG: server process (PID 23241) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2004-12-29 15:36:27 CET LOG: checkpoint record is at 0/DA95E8 LOG: redo record is at 0/DA95E8; undo record is at 0/0; shutdown FALSE LOG: next transaction ID: 1119; next OID: 66382 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/DA9628 LOG: record with zero length at 0/E09988 LOG: redo done at 0/E09958 LOG: database system is ready The cube contrib regression tests passes with this setup. I'm trying right now to gmake installcheck in contrib/, to see if there are dependancies between tests. Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] [BUGS] ECPG CONNECT TO DEFAULT segfault
On Wed, Dec 29, 2004 at 10:32:21AM +0100, Michael Meskes wrote: On Tue, Dec 28, 2004 at 11:15:52PM -0700, Michael Fuhr wrote: ECPG's CONNECT TO DEFAULT causes a segmentation fault. This originally came up in the Connection without database name thread in pgsql-hackers: This is exactly what I did fix with the work mentioned in the hackers thread. It should work nicely with CVS HEAD. Could you please try this? Try what? I don't see a patch, link, or suggested fix in the thread -- just your original message and the two followups by Tom Lane and me. Or was the fix discussed in a different thread? -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pg_class changes for group ownership
Greetings, Due to the fact that group system id's and user system id's can overlap, pg_class will need to change in order to accomedate group ownership. The things I've thought of so far, in order of preference: a) Add a boolean field 'relgroup_owned' which is 'false' when relowner is a user and 'true' when relowner is a group. b) Add an integer field 'relgroup_owner' which is the 'group' owner of the relation, this would imply 'dual' ownership, ala unix semantics, but doesn't quite fit in w/ Postgres ACLs, imv. c) Don't change pg_class's structure but change the meaning of 'relowner' such that positive numbers are 'user' owners and negative numbers are 'group' owners, where the group id is the abs(relowner). Similar to (a) but seems kind of nasty to me. Also means that '0' couldn't ever be used for a system id, and that it'd be more difficult to change relowner to Oid later (probably involving something like (a)). Thoughts? Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: here is the tail of regression.diff (which indicates that the first=20 query failed): SELECT '1'::mquery_txt; ! server closed the connection unexpectedly ! This probably means the server terminated abnormally ! before or while processing the request. ! connection to server was lost Backtracing the core dump from that crash would do fine. It's probably the same failure --- what this looks like to me now is dereferencing a garbage pointer, which happens to pick up an irrelevant value in the one symptom and touch unmapped memory in the other. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] race condition for drop schema cascade?
Andrew Dunstan [EMAIL PROTECTED] writes: You're right - my query was not sufficiently specific. There have in fact been 4 failures: pgbuildfarm=# select sysname, snapshot, stage, branch from build_status where log ~ 'tablespace testspace is not empty.*tablespace testspace is not empty' and not log ~ 'No space left'; sysname | snapshot |stage | branch +-+--+ hare| 2004-12-09 05:15:05 | Check| HEAD otter | 2004-12-11 15:50:09 | Check| HEAD otter | 2004-12-15 15:50:10 | Check| HEAD gibbon | 2004-12-28 23:55:05 | InstallCheck | HEAD Why does the last show as an install failure? Anyway, given the small number of machines involved, I'm once again wondering what filesystem they are using. They wouldn't be running the check over NFS, by any chance, for instance? The theory that is in my mind is that the bgwriter could have written out a page for the table in the test tablespace, and thereby be holding an open file pointer for it. On standard Unix filesystems this would not disrupt the backend's ability to unlink the table at the DROP stage, but I'm wondering about nonstandard filesystems ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] RC3 on Friday
FYI, the release team is planning a PostgreSQL RC3 release for this Friday. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
Le 29 déc. 04, à 18:05, Tom Lane a écrit : =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: here is the tail of regression.diff (which indicates that the first=20 query failed): SELECT '1'::mquery_txt; ! server closed the connection unexpectedly ! This probably means the server terminated abnormally ! before or while processing the request. ! connection to server was lost Backtracing the core dump from that crash would do fine. Here you go (gdb) bt #0 0x010a in ?? () #1 0x046e9cce in queryin (buf=Cannot access memory at address 0x0 ) at query.c:543 #2 0x046e9e44 in mqtxt_in (fcinfo=0xb688) at query.c:620 #3 0x0019d790 in OidFunctionCall3 (functionId=61367, arg1=2762304, arg2=0, arg3=4294967295) at fmgr.c:1408 #4 0x00091298 in stringTypeDatum (tp=0x2a26e9, string=0x2a2640 1, atttypmod=-1) at parse_type.c:338 #5 0x00091968 in coerce_type (pstate=0x2a2610, node=0x2a2240, inputTypeId=2762304, targetTypeId=61366, targetTypeMod=-1, ccontext=98, cformat=COERCE_EXPLICIT_CAST) at parse_coerce.c:185 #6 0x0009157c in coerce_to_target_type (pstate=0x2a2518, expr=0x2a2240, exprtype=705, targettype=61366, targettypmod=-1, ccontext=COERCION_EXPLICIT, cformat=COERCE_EXPLICIT_CAST) at parse_coerce.c:80 #7 0x0008b440 in typecast_expression (pstate=0x2a2518, expr=0x2a2240, typename=0x2a2358) at parse_expr.c:1651 #8 0x0008a814 in transformExpr (pstate=0x2a2518, expr=0x2a23d8) at parse_expr.c:177 #9 0x00093224 in transformTargetEntry (pstate=0x2a2518, node=0x2a23d8, expr=0x0, colname=0x0, resjunk=0 '\0') at parse_target.c:72 #10 0x000932aa in transformTargetList (pstate=0x2a2518, targetlist=0xb688) at parse_target.c:148 #11 0x00077676 in transformSelectStmt (pstate=0x2a2518, stmt=0x2a2450) at analyze.c:1813 #12 0x00075496 in transformStmt (pstate=0x2a2518, parseTree=0x2a2450, extras_before=0xba80, extras_after=0xba84) at analyze.c:371 #13 0x00075230 in do_parse_analyze (parseTree=0x2a2450, pstate=0x2a2518) at analyze.c:245 #14 0x0007514c in parse_analyze (parseTree=0x2a2450, paramTypes=0x0, numParams=0) at analyze.c:169 #15 0x00138f3a in pg_analyze_and_rewrite (parsetree=0x2a2450, paramTypes=0x0, numParams=0) at postgres.c:555 #16 0x00139298 in exec_simple_query (query_string=0x2a2020 SELECT '1'::mquery_txt;) at postgres.c:872 #17 0x0013b4c6 in PostgresMain (argc=4, argv=0x27f390, username=0x27f260 rzara) at postgres.c:3007 #18 0x00114b7c in BackendRun (port=0x28f200) at postmaster.c:2817 #19 0x0011447e in BackendStartup (port=0x28f200) at postmaster.c:2453 #20 0x00112cd0 in ServerLoop () at postmaster.c:1198 #21 0x001126f0 in PostmasterMain (argc=3, argv=0xc674) at postmaster.c:917 #22 0x000e465e in main (argc=3, argv=0xc674) at main.c:268 Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] pg_class changes for group ownership
Stephen Frost [EMAIL PROTECTED] writes: Due to the fact that group system id's and user system id's can overlap, pg_class will need to change in order to accomedate group ownership. The things I've thought of so far, in order of preference: I thought that the agreed-on direction for this was to merge users and groups into a single kind of entity, or at least make sure that they share a common unique identifier space. Then AclId is still sufficient as an ownership indicator, and you don't need any of these kluges. IIRC something of this sort is needed for improved compliance with the SQL spec anyway --- see past discussions about roles. 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
Re: [HACKERS] pg_class changes for group ownership
* Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Due to the fact that group system id's and user system id's can overlap, pg_class will need to change in order to accomedate group ownership. The things I've thought of so far, in order of preference: I thought that the agreed-on direction for this was to merge users and groups into a single kind of entity, or at least make sure that they share a common unique identifier space. Then AclId is still sufficient as an ownership indicator, and you don't need any of these kluges. IIRC something of this sort is needed for improved compliance with the SQL spec anyway --- see past discussions about roles. Ah, alright, sounds good to me. I'll look into making them share a common unique identifier space, that shouldn't be too difficult. Of course, that'll require a dump/restore, I expect.. I don't suppose that could possibly happen before 8.0, eh? :) Stephen signature.asc Description: Digital signature
Re: [HACKERS] race condition for drop schema cascade?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: You're right - my query was not sufficiently specific. There have in fact been 4 failures: pgbuildfarm=# select sysname, snapshot, stage, branch from build_status where log ~ 'tablespace testspace is not empty.*tablespace testspace is not empty' and not log ~ 'No space left'; sysname | snapshot |stage | branch +-+--+ hare| 2004-12-09 05:15:05 | Check| HEAD otter | 2004-12-11 15:50:09 | Check| HEAD otter | 2004-12-15 15:50:10 | Check| HEAD gibbon | 2004-12-28 23:55:05 | InstallCheck | HEAD Why does the last show as an install failure? We run the standard regression suite twice - the failure on Gibbon occurred on the second of these. Clearly this is very transient. Anyway, given the small number of machines involved, I'm once again wondering what filesystem they are using. They wouldn't be running the check over NFS, by any chance, for instance? The theory that is in my mind is that the bgwriter could have written out a page for the table in the test tablespace, and thereby be holding an open file pointer for it. On standard Unix filesystems this would not disrupt the backend's ability to unlink the table at the DROP stage, but I'm wondering about nonstandard filesystems ... Jim Buttafuoco reported on December 16th that he had rebuilt the filesystem on his MIPS box - I assume this means that he isn't using NFS. In any case, we have not seen the problem since then. His Alpha box has not been reporting buildfarm results since before then. The Cygwin box is running on NTFS - and we know we've encountered plenty of problems with unlinking on Windows. I know it's not much to go on. cheers andrew ---(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: [HACKERS] pg_class changes for group ownership
Stephen Frost [EMAIL PROTECTED] writes: Ah, alright, sounds good to me. I'll look into making them share a common unique identifier space, that shouldn't be too difficult. Of course, that'll require a dump/restore, I expect.. I don't suppose that could possibly happen before 8.0, eh? :) Changing pg_class would have the same problem ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_class changes for group ownership
* Tom Lane ([EMAIL PROTECTED]) wrote: Stephen Frost [EMAIL PROTECTED] writes: Ah, alright, sounds good to me. I'll look into making them share a common unique identifier space, that shouldn't be too difficult. Of course, that'll require a dump/restore, I expect.. I don't suppose that could possibly happen before 8.0, eh? :) Changing pg_class would have the same problem ... Well, yes, but that's no longer the issue. I guess my thought was that if we could get the common id space change in before 8.0 then group ownership could possibly be introduced in 8.1 w/o having to do a dump/restore. I'm still relatively new to Postgres, is it normal to require a dump/restore between semi-major (8.0 to 8.1) revisions? If so then it doesn't matter since I wouldn't expect group ownership to be introduced prior to 8.1 (at the earliest..) anyway. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] pg_class changes for group ownership
Stephen Frost [EMAIL PROTECTED] writes: Well, yes, but that's no longer the issue. I guess my thought was that if we could get the common id space change in before 8.0 then group ownership could possibly be introduced in 8.1 w/o having to do a dump/restore. No chance whatever during RC stage. We might have listened to such a proposal in August, but it's not happening now. Especially not when you don't even have the patch yet ;-). (FWIW, given the infrastructure we have, I don't really see any way to enforce uniqueness except to merge pg_shadow and pg_group into one table. So it's not going to be a trivial change.) I'm still relatively new to Postgres, is it normal to require a dump/restore between semi-major (8.0 to 8.1) revisions? Yes. There have been one or two such revisions that didn't require a dump, but I doubt 8.1 will be one of them. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] race condition for drop schema cascade?
Andrew/all I have not seen any problems on my MIPS systems since the rebuild ext3 (I ran badblocks during fs creation). I should have the alpha running about soon, the disk died and I am waiting a replacement. I do believe there is a floating point problem with older alpha's out there. The seems to have a problem with INFINITY and NAN's. I did some checking on the net and the problem seems know (with no solution). Maybe something can go into the readme or such. If anyone is interested in looking at this for pg8.0 I can give SSH access in a week or so. Jim -- Original Message --- From: Andrew Dunstan [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] Cc: Kurt Roeckx [EMAIL PROTECTED], PostgreSQL-development pgsql-hackers@postgresql.org Sent: Wed, 29 Dec 2004 13:05:26 -0500 Subject: Re: [HACKERS] race condition for drop schema cascade? Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: You're right - my query was not sufficiently specific. There have in fact been 4 failures: pgbuildfarm=# select sysname, snapshot, stage, branch from build_status where log ~ 'tablespace testspace is not empty.*tablespace testspace is not empty' and not log ~ 'No space left'; sysname | snapshot |stage | branch +-+--+ hare| 2004-12-09 05:15:05 | Check| HEAD otter | 2004-12-11 15:50:09 | Check| HEAD otter | 2004-12-15 15:50:10 | Check| HEAD gibbon | 2004-12-28 23:55:05 | InstallCheck | HEAD Why does the last show as an install failure? We run the standard regression suite twice - the failure on Gibbon occurred on the second of these. Clearly this is very transient. Anyway, given the small number of machines involved, I'm once again wondering what filesystem they are using. They wouldn't be running the check over NFS, by any chance, for instance? The theory that is in my mind is that the bgwriter could have written out a page for the table in the test tablespace, and thereby be holding an open file pointer for it. On standard Unix filesystems this would not disrupt the backend's ability to unlink the table at the DROP stage, but I'm wondering about nonstandard filesystems ... Jim Buttafuoco reported on December 16th that he had rebuilt the filesystem on his MIPS box - I assume this means that he isn't using NFS. In any case, we have not seen the problem since then. His Alpha box has not been reporting buildfarm results since before then. The Cygwin box is running on NTFS - and we know we've encountered plenty of problems with unlinking on Windows. I know it's not much to go on. cheers andrew ---(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 --- End of Original Message --- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] race condition for drop schema cascade?
Tom, my systems are all EXT3 (Debian 3.1) (andrew can tell you which ones they are). Jim -- Original Message --- From: Tom Lane [EMAIL PROTECTED] To: Andrew Dunstan [EMAIL PROTECTED] Cc: Kurt Roeckx [EMAIL PROTECTED], PostgreSQL-development pgsql-hackers@postgresql.org Sent: Wed, 29 Dec 2004 12:26:56 -0500 Subject: Re: [HACKERS] race condition for drop schema cascade? Andrew Dunstan [EMAIL PROTECTED] writes: You're right - my query was not sufficiently specific. There have in fact been 4 failures: pgbuildfarm=# select sysname, snapshot, stage, branch from build_status where log ~ 'tablespace testspace is not empty.*tablespace testspace is not empty' and not log ~ 'No space left'; sysname | snapshot |stage | branch +-+--+ hare| 2004-12-09 05:15:05 | Check| HEAD otter | 2004-12-11 15:50:09 | Check| HEAD otter | 2004-12-15 15:50:10 | Check| HEAD gibbon | 2004-12-28 23:55:05 | InstallCheck | HEAD Why does the last show as an install failure? Anyway, given the small number of machines involved, I'm once again wondering what filesystem they are using. They wouldn't be running the check over NFS, by any chance, for instance? The theory that is in my mind is that the bgwriter could have written out a page for the table in the test tablespace, and thereby be holding an open file pointer for it. On standard Unix filesystems this would not disrupt the backend's ability to unlink the table at the DROP stage, but I'm wondering about nonstandard filesystems ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster --- End of Original Message --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] race condition for drop schema cascade?
Jim Buttafuoco wrote: Andrew/all I have not seen any problems on my MIPS systems since the rebuild ext3 (I ran badblocks during fs creation). I should have the alpha running about soon, the disk died and I am waiting a replacement. I do believe there is a floating point problem with older alpha's out there. The seems to have a problem with INFINITY and NAN's. I did some checking on the net and the problem seems know (with no solution). Maybe something can go into the readme or such. If anyone is interested in looking at this for pg8.0 I can give SSH access in a week or so. I doubt that either of the problems (FP on old Alpha or failing 'drop schema cascade + drop tablespace') is a showstopper. Maybe the 'platforms supported' notes should carry a mention. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes: Le 29 d=E9c. 04, =E0 18:05, Tom Lane a =E9crit : Backtracing the core dump from that crash would do fine. Here you go (gdb) bt #0 0x010a in ?? () #1 0x046e9cce in queryin (buf=3DCannot access memory at address 0x0 ) at query.c:543 #2 0x046e9e44 in mqtxt_in (fcinfo=3D0xb688) at query.c:620 #3 0x0019d790 in OidFunctionCall3 (functionId=3D61367, arg1=3D2762304,=20= arg2=3D0, arg3=3D4294967295) at fmgr.c:1408 #4 0x00091298 in stringTypeDatum (tp=3D0x2a26e9, string=3D0x2a2640 1,=20= atttypmod=3D-1) at parse_type.c:338 Hmm. I was hoping to spot some obviously machine-dependent code nearby to the crash point, but I don't see anything wrong in that area. You might try rebuilding tsearch with -O0 (if it wasn't already) in hopes that the backtrace becomes more accurate. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] using pg_config to get LDFLAGS?
Hi! I'm maintaining a bunch of FreeBSD ports for postgresql stuff. I get problems when building postgresql with Kerberos, because packages like libpqxx does not automatically understand that it will also need to link with libkrb.so. Is there any default way to get gnu configure for such packages to understand that it needs to link with libkrb.so? Using pg_config --configure, the LDFLAGS are there to extract, but perhaps a cleaner way is possible? # # without kerberos: # pg_config --configure '--with-libraries=/usr/local/lib' '--with-includes=/usr/local/include' '--with-docdir=/usr/local/share/doc/postgresql' '--enable-nls' '--prefix=/usr/local' 'i386-portbld-freebsd5.3' 'LDFLAGS=' 'CFLAGS=-O -pipe -march=athlon-xp' 'host_alias=i386-portbld-freebsd5.3' 'build_alias=i386-portbld-freebsd5.3' 'target_alias=i386-portbld-freebsd5.3' 'CC=cc' # # with kerberos # pg_config --configure '--with-libraries=/usr/local/lib' '--with-includes=/usr/local/include' '--with-docdir=/usr/local/share/doc/postgresql' '--enable-nls' '--with-krb5' '--prefix=/usr/local' 'i386-portbld-freebsd5.3' 'LDFLAGS= -L/usr/lib -lkrb5 -lasn1 -lcrypto -lroken -lcrypt -lcom_err' 'CFLAGS=-O -pipe -march=athlon-xp' 'host_alias=i386-portbld-freebsd5.3' 'build_alias=i386-portbld-freebsd5.3' 'target_alias=i386-portbld-freebsd5.3' 'CC=cc' Regards, Palle ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Shared row locking
On Thu, 16 Dec 2004 21:54:14 -0300, Alvaro Herrera [EMAIL PROTECTED] wrote: Else, it will have to wait, using XactLockTableWait, for the first transaction in the array that is still running. We can be sure that no one will try to share-lock the tuple while we check the btree because we hold an exclusive lock on the tuple's heap page's buffer. Do you really want to XactLockTableWait while holding an exclusive lock on a heap page? Or are you going to release the lock before entering the wait? Thanks to tablespaces, it's very easy to create special Relations that can be dealt with by standard buffer and storage manager, etc. I don't get how tablespaces would help. The btree idea: - does not need crash recovery. Maybe we could use a stripped down version of nbtree. This could cause a maintanibility nightmare. It could be a nightmare if you simply duplicate and then modify the code. A better way would be to refactor nbtree to be able to handle btrees with different properties: . shared/private . logged/non-logged . flexible value data type. - can't hold more than 300 or so simultaneous lockers (because of value length, limited to 1/3 of a page). I doubt this is a real problem. Or you store each lock as a separate index tuple. If this is expected to be a problem because of many repeating key vaules, nbtree should be enhanced to support duplicate key compression, which might be a good thing per se. Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Shared row locking
On Mon, 20 Dec 2004 21:44:01 +0100, [EMAIL PROTECTED] wrote: Tom Lane [EMAIL PROTECTED] wrote on 20.12.2004, 19:34:21: #1 could have a pretty serious performance impact, too. For small numbers of FOR UPDATE locks (too few to force spill to disk) I would expect #2 to substantially beat #1. #1 essentially imposes the worst case performance at all times, whereas #2 degrades (at a currently unknown rate) when there are lots and lots of FOR UPDATE locks. I don't see too much of a difference between #1 (an on-disk structure buffered in shared memory) and #2 (a shared memory structure spilling to disk). As long as we can avoid unnecessary writes, #1 has the nice property that it automatically adapts to different usage patterns because it uses the normal shared buffer pool and cache replacement strategy. [My gut feeling would be against another permanent on-disk structure, since this is one more thing for a user to delete to save space etc...] Irrelevant, IMHO. Whoever manually deletes any file under PGDATA deserves whatever this may cause. I haven't seen many programs that use extended SELECT FOR UPDATE logic. AFAICS, SELECT FOR UPDATE is not the primary issue here, because it locks rows exclusively. This thread is about shared locks, which should be used for foreign key checks. Servus Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bgwriter behavior
[I know I'm late and this has already been discussed by Richrad, Tom, et al., but ...] On Tue, 21 Dec 2004 16:17:17 -0600, Jim C. Nasby [EMAIL PROTECTED] wrote: look at where the last page you wrote out has ended up in the LRU list since you last ran, and start scanning from there (by definition everything after that page would have to be clean). This is a bit oversimplified, because that page will be moved to the start of the list when it is accessed the next time. A = B = C = D = E = F = G = H = I = J = K = L = m = n = o = p = q ^ would become M = A = B = C = D = E = F = G = H = I = J = K = L = n = o = p = q ^ (a-z ... known to be clean, A-Z ... possibly dirty) But with a bit of cooperation from the backends this could be made to work. Whenever a backend takes the page which is the start of the clean tail out of the list (most probably to insert it into another list or to re-insert it at the start of the same list) the clean tail pointer is advanced to the next list element, if any. So we would get M = A = B = C = D = E = F = G = H = I = J = K = L = n = o = p = q ^ As a little improvement the clean tail could be prevented from shrinking unnecessarily fast by moving the pointer to the previous list element if this is found to be clean: M = A = B = C = D = E = F = G = H = I = J = K = l = n = o = p = q ^ Maybe this approach could serve both goals, (1) keeping a number of clean pages at the LRU end of the list and (2) writing out other dirty pages if there's not much to do near the end of the list. But ... On Tue, 21 Dec 2004 10:26:48 -0500, Tom Lane [EMAIL PROTECTED] wrote: Also, the cntxDirty mechanism allows a block to be dirtied without changing the ARC state at all. ... which might kill this proposal anyway. Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Shared row locking
Manfred Koizar [EMAIL PROTECTED] writes: I don't see too much of a difference between #1 (an on-disk structure buffered in shared memory) and #2 (a shared memory structure spilling to disk). If you stand back that far, maybe you can't see a difference ;-) ... but the proposal on the table was for an extremely special-purpose on-disk structure. I'd prefer to see first if we can solve a more general problem, namely the fixed size of the existing lock table. It's certainly possible that that idea won't work out, but if it can be done for a similar time investment as the special-purpose log would take, it'd be a win. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
