Re: [HACKERS] [PATCHES] Warning for missing createlang
Andrew Dunstan kirjutas L, 06.09.2003 kell 16:14: Peter Eisentraut wrote: Tom Lane writes: There are good security arguments not to have it in the default install, no? I think last time the only reason we saw was that dump restoring would be difficult. I don't see any security reasons. That could be overcome by doing a 'drop language' before running your restore, couldn't it? or to have CREATE OR REPLACE LANGUAGE (like we have for FUNCTIONS). --- Hannu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] pg_id and pg_encoding
Is there any reason to keep separate pg_id and pg_encoding programs, or should they be merged into a C version of initdb? AFAICS initdb is the only thing that uses them. We'll also need to decide the Windows equivalent of the 'don't run as root' rule - or even if we want to enforce it at all, given that it appears to be very common practice on Windows to run all services as a user with Administrator privileges. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_id and pg_encoding
Andrew Dunstan wrote: Is there any reason to keep separate pg_id and pg_encoding programs, or should they be merged into a C version of initdb? AFAICS initdb is the only thing that uses them. Yes, I assume they would go away with a C version. We'll also need to decide the Windows equivalent of the 'don't run as root' rule - or even if we want to enforce it at all, given that it appears to be very common practice on Windows to run all services as a user with Administrator privileges. I assume we will relax that for Win32. I don't think non-Administrators have the same isolation on Win32 as non-root users have on Unix. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pg_id and pg_encoding
Bruce Momjian wrote: We'll also need to decide the Windows equivalent of the 'don't run as root' rule - or even if we want to enforce it at all, given that it appears to be very common practice on Windows to run all services as a user with Administrator privileges. I assume we will relax that for Win32. I don't think non-Administrators have the same isolation on Win32 as non-root users have on Unix. While it's best practice for *ix to work as non-root, many windows users will be administrator-equivalent. The Local System account commonly used to run services is even more privileged than the local admin. So the restriction to non-admins won't make too much sense. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Notices for redundant operations
Robert Treat writes: Hmm... the counter state seems to be that now these commands would tell you they are doing something even though they are arn't really doing anything: Commands are defined in terms of their results, not in terms of their actions, and certainly not in terms of the amount of grinding that is caused by them. Have you ever realized that GRANT SELECT ON table1 TO person; might not do anything? No one has suggested notices for that. Or have you ever seen a notice issued as the result of chmod a+x filename when the file was already executable? -- Peter Eisentraut [EMAIL PROTECTED] ---(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_id and pg_encoding
Andreas Pflug [EMAIL PROTECTED] wrote: Bruce Momjian wrote: We'll also need to decide the Windows equivalent of the 'don't run as root' rule - or even if we want to enforce it at all, given that it appears to be very common practice on Windows to run all services as a user with Administrator privileges. I assume we will relax that for Win32. I don't think non-Administrators have the same isolation on Win32 as non-root users have on Unix. While it's best practice for *ix to work as non-root, many windows users will be administrator-equivalent. The Local System account commonly used to run services is even more privileged than the local admin. So the restriction to non-admins won't make too much sense. Work as non-root is a good practice for windows user too, I'll not bet for the future that on windows all users will be super user; you can choose to start a service like a non super user too, I'd like to mantain the same policy on windows too. Regards Gaetano Mendola ---(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_id and pg_encoding
Gaetano Mendola wrote: Work as non-root is a good practice for windows user too, I'll not bet for the future that on windows all users will be super user; you can choose to start a service like a non super user too, I'd like to mantain the same policy on windows too. We're talking about running services, and many admins probably run their services with an admin group member account. User accounts *can* selectively be given the needed privileges to run a service, but it's quite tricky and documentation isn't too good about this. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Unixware 713 probs
Hi, I have those errors on Unixware 713 with yesterday and today's CVS Script started on Sun Sep 7 20:19:16 2003 $ make Using GNU make found at /usr/local/bin/gmake /usr/local/bin/gmake -C doc all gmake[1]: Entering directory `/home/postgres/pgsql/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/postgres/pgsql/doc' /usr/local/bin/gmake -C src all gmake[1]: Entering directory `/home/postgres/pgsql/src' /usr/local/bin/gmake -C port all gmake[2]: Entering directory `/home/postgres/pgsql/src/port' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/postgres/pgsql/src/port' /usr/local/bin/gmake -C backend all gmake[2]: Entering directory `/home/postgres/pgsql/src/backend' /usr/local/bin/gmake -C ../../src/port all gmake[3]: Entering directory `/home/postgres/pgsql/src/port' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/port' /usr/local/bin/gmake -C access all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/access' /usr/local/bin/gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/common' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/common' /usr/local/bin/gmake -C gist SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/gist' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/gist' /usr/local/bin/gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/hash' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/hash' /usr/local/bin/gmake -C heap SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/heap' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/heap' /usr/local/bin/gmake -C index SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/index' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/index' /usr/local/bin/gmake -C nbtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/nbtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/nbtree' /usr/local/bin/gmake -C rtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/rtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/rtree' /usr/local/bin/gmake -C transam SUBSYS.o gmake[4]: Entering directory `/home/postgres/pgsql/src/backend/access/transam' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/pgsql/src/backend/access/transam' gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/access' /usr/local/bin/gmake -C bootstrap all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/bootstrap' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/bootstrap' /usr/local/bin/gmake -C catalog all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/catalog' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/catalog' /usr/local/bin/gmake -C parser all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/parser' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/parser' /usr/local/bin/gmake -C commands all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/commands' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/commands' /usr/local/bin/gmake -C executor all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/executor' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/executor' /usr/local/bin/gmake -C lib all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/lib' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/pgsql/src/backend/lib' /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq' cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o ip.o ip.c UX:acomp: ERROR: ip.c, line 416: Syntax error before or at: . UX:acomp: WARNING: ip.c, line 419: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 427: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 428: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 429: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 430: left operand of . must be struct/union object UX:acomp: ERROR: ip.c, line 451: Syntax error before or at: . UX:acomp: ERROR: ip.c, line
Re: [HACKERS] Unixware 713 probs
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote: [snip] /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq' cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o ip.o ip.c UX:acomp: ERROR: ip.c, line 416: Syntax error before or at: . UX:acomp: WARNING: ip.c, line 419: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 427: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 428: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 429: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 430: left operand of . must be struct/union object UX:acomp: ERROR: ip.c, line 451: Syntax error before or at: . UX:acomp: ERROR: ip.c, line 452: invalid type combination UX:acomp: WARNING: ip.c, line 455: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 464: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 465: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 466: left operand of . must be struct/union object UX:acomp: line 416 is: int32 s_addr; s_addr is seen by the compiler as: uint32 __S_un . __S_addr ; We need to pick another name. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Unixware 713 probs
On Sun, 7 Sep 2003, Larry Rosenman wrote: --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote: [snip] /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq' cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o ip.o ip.c UX:acomp: ERROR: ip.c, line 416: Syntax error before or at: . UX:acomp: WARNING: ip.c, line 419: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 427: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 428: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 429: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 430: left operand of . must be struct/union object UX:acomp: ERROR: ip.c, line 451: Syntax error before or at: . UX:acomp: ERROR: ip.c, line 452: invalid type combination UX:acomp: WARNING: ip.c, line 455: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 464: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 465: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 466: left operand of . must be struct/union object UX:acomp: line 416 is: int32 s_addr; s_addr is seen by the compiler as: uint32 __S_un . __S_addr ; We need to pick another name. As a side note, if s_addr is being defined by a common system header, you should probably complain to your vendor as well, since that's amazingly bad behavior on its part. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Unixware 713 probs
--On Sunday, September 07, 2003 12:52:18 -0700 Stephan Szabo [EMAIL PROTECTED] wrote: On Sun, 7 Sep 2003, Larry Rosenman wrote: --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote: [snip] /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq' cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o ip.o ip.c UX:acomp: ERROR: ip.c, line 416: Syntax error before or at: . UX:acomp: WARNING: ip.c, line 419: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 427: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 428: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 429: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 430: left operand of . must be struct/union object UX:acomp: ERROR: ip.c, line 451: Syntax error before or at: . UX:acomp: ERROR: ip.c, line 452: invalid type combination UX:acomp: WARNING: ip.c, line 455: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 464: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 465: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 466: left operand of . must be struct/union object UX:acomp: line 416 is: int32 s_addr; s_addr is seen by the compiler as: uint32 __S_un . __S_addr ; We need to pick another name. As a side note, if s_addr is being defined by a common system header, you should probably complain to your vendor as well, since that's amazingly bad behavior on its part. netinet/in_f.h:#define s_addr __S_un.__S_addr Hrm. I'll ask, but this is SCO, so. Meanwhile, this header is in the field, so. I fired off a note to a contact at SCO. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 pgp0.pgp Description: PGP signature
Re: [HACKERS] Notices for redundant operations
On Sun, Sep 07, 2003 at 06:36:47PM +0200, Peter Eisentraut wrote: Robert Treat writes: Hmm... the counter state seems to be that now these commands would tell you they are doing something even though they are arn't really doing anything: Commands are defined in terms of their results, not in terms of their actions, and certainly not in terms of the amount of grinding that is caused by them. This argument makes sense. At least it convinced me. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La fuerza no está en los medios físicos sino que reside en una voluntad indomable (Gandhi) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Unixware 713 probs
On Sun, 7 Sep 2003, Larry Rosenman wrote: --On Sunday, September 07, 2003 12:52:18 -0700 Stephan Szabo [EMAIL PROTECTED] wrote: On Sun, 7 Sep 2003, Larry Rosenman wrote: --On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote: [snip] /usr/local/bin/gmake -C libpq all gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq' cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o ip.o ip.c UX:acomp: ERROR: ip.c, line 416: Syntax error before or at: . UX:acomp: WARNING: ip.c, line 419: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 427: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 428: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 429: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 430: left operand of . must be struct/union object UX:acomp: ERROR: ip.c, line 451: Syntax error before or at: . UX:acomp: ERROR: ip.c, line 452: invalid type combination UX:acomp: WARNING: ip.c, line 455: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 464: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 465: left operand of . must be struct/union object UX:acomp: WARNING: ip.c, line 466: left operand of . must be struct/union object UX:acomp: line 416 is: int32 s_addr; s_addr is seen by the compiler as: uint32 __S_un . __S_addr ; We need to pick another name. As a side note, if s_addr is being defined by a common system header, you should probably complain to your vendor as well, since that's amazingly bad behavior on its part. netinet/in_f.h:#define s_addr __S_un.__S_addr Hrm. I'll ask, but this is SCO, so. Meanwhile, this header is in the field, so. Yeah, we obviously need to deal with it now, but hopefully at some point in the future other people won't. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_id and pg_encoding
On Sun, 2003-09-07 at 16:46, Bruce Momjian wrote: Andrew Dunstan wrote: Is there any reason to keep separate pg_id and pg_encoding programs, or should they be merged into a C version of initdb? AFAICS initdb is the only thing that uses them. Yes, I assume they would go away with a C version. I use both of them for the Debian packaging, to try to ensure that upgrading goes seamlessly. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C For whosoever shall call upon the name of the Lord shall be saved. Romans 10:13 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Needed function IF(expr, expr, expr)
However, as of 7.4, that problem is gone too. If you write the function just as above (language sql, volatile, not strict) then the planner will inline it and indeed what you get is a CASE. Watch this: Hm. I wonder if there are cases of people using functions like this with user-defined volatile functions depending on the function's side effects happening the correct number of times. Or do volatile functions not get inlined like this? So we do actually have a sort-of-credible way to make a user-defined function that emulates IF(). I think we might be able to do Oracle's DECODE() as well, though I don't know its exact definition. (You'd still need to make several of 'em to handle differing numbers of arguments, but that seems well within the bounds of feasibility.) I think there's a problem implementing decode() surrounding NULL: SELECT decode(col, 'foo', 1, NULL, 2, 3) would mean: SELECT CASE WHEN col='foo' THEN 1 WHEN col IS NULL THEN 2 ELSE 3 END To do it I think you would need a iseq() function that compared NULLs as being equal. -- greg ---(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] table-level and row-level locks.
A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple. where is 'HEAP_MARKED_FOR_UPDATE infomask bit' found ? thanks From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [HACKERS] table-level and row-level locks. Date: Wed, 20 Aug 2003 14:45:23 -0400 Koichi Suzuki [EMAIL PROTECTED] writes: I need to know where such lock marks are stored in the source level. A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html _ Use custom emotions -- try MSN Messenger 6.0! http://www.msnmessenger-download.com/tracking/reach_emoticon ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] table-level and row-level locks.
On Sun, Sep 07, 2003 at 04:07:42PM -0700, Jenny - wrote: A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple. where is 'HEAP_MARKED_FOR_UPDATE infomask bit' found ? Have you ever heard of the grep *nix utility? It's quite useful. Anyway, t_infomask is part of a struct called HeapTupleHeaderData, defined somewhere in src/include/access/htup.h -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) You liked Linux a lot when he was just the gawky kid from down the block mowing your lawn or shoveling the snow. But now that he wants to date your daughter, you're not so sure he measures up. (Larry Greenemeier) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Needed function IF(expr, expr, expr)
Greg Stark [EMAIL PROTECTED] writes: Hm. I wonder if there are cases of people using functions like this with user-defined volatile functions depending on the function's side effects happening the correct number of times. Or do volatile functions not get inlined like this? SQL functions can't have side effects, at least not if they are simple SELECTs, which is the only kind that gets inlined. To do it I think you would need a iseq() function that compared NULLs as being equal. No, just CASE WHEN (col = checkval) OR (col IS NULL AND checkval IS NULL) ... 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
[HACKERS] row level lock and table level locks
A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple.Is there a similar bit modified if the row in question is being waited upon by some transaction? Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: [HACKERS] row level lock and table level locks
Larry Douzie [EMAIL PROTECTED] writes: A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple. Is there a similar bit modified if the row in question is being waited upon by some transaction? No. We handle that case by waiting for the transaction that's locked the row to commit or abort. (Waiting for a transaction is done by having every transaction take out exclusive lock on its xact ID when it starts; then would-be waiters try to take share lock on the xact ID, causing them to block till the exclusive lock is released.) In general, the Postgres lock management code is not designed for transparency :-( ... it does the jobs it's supposed to do, but it's not always easy to inspect the visible state to find out what's happening. Perhaps someday someone will get motivated to rewrite this stuff. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] row level lock and table level locks
On Sun, Sep 07, 2003 at 11:24:42PM -0400, Tom Lane wrote: No. We handle that case by waiting for the transaction that's locked the row to commit or abort. (Waiting for a transaction is done by having every transaction take out exclusive lock on its xact ID when it starts; then would-be waiters try to take share lock on the xact ID, causing them to block till the exclusive lock is released.) This is interesting in the nested transactions case. Suppose a transaction takes a lock on a tuple. If another transaction tries to do the same, it has to wait for the previous transaction to finish. That's pretty clear and simple. Now, if a subtransaction has got a lock on some tuple, and another transaction tree tries to grab the lock on that tuple, it should have to wait for the entire transaction tree to finish. But what if the subtransaction that got the lock aborts? Maybe the waiter could awake at that point. I invented a CommitContext, that is supposed to hold things that should be kept in memory if a subtransaction commits, and discarded if it aborts (think async notifies, smgr pending deletes). The list of things has to be kept until the transaction tree is finished, but can be discarded in a single operation if any subtransaction aborts. Maybe some similar thing can be done with locks? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) El conflicto es el camino real hacia la union ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] row level lock and table level locks
Is there a array or some sort of datastructures that store all the HeapTupleDatas for all rows in the db? like we have the LockData storing all the current locks in the db. thanks!Tom Lane [EMAIL PROTECTED] wrote: Larry Douzie <[EMAIL PROTECTED]>writes: A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple. Is there a similar bit modified if the row in question is being waited upon by some transaction?No. We handle that case by waiting for the transaction that's lockedthe row to commit or abort. (Waiting for a transaction is done byhaving every transaction take out exclusive lock on its xact ID when itstarts; then would-be waiters try to take share lock on the xact ID,causing them to block till the exclusive lock is released.)In general, the Postgres lock management code is not designed fortransparency :-( ... it do es the jobs it's supposed to do, but it's notalways easy to inspect the visible state to find out what's happening.Perhaps someday someone will get motivated to rewrite this stuff.regards, tom lane Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Re: [HACKERS] row level lock and table level locks
Alvaro Herrera [EMAIL PROTECTED] writes: Now, if a subtransaction has got a lock on some tuple, and another transaction tree tries to grab the lock on that tuple, it should have to wait for the entire transaction tree to finish. But what if the subtransaction that got the lock aborts? Maybe the waiter could awake at that point. Yes. At present, a transaction that aborts will *immediately* drop all its locks (and other shared resources), even before waiting for its client to acknowledge the failure. Seems to me the same should hold true of subtransactions. 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: [HACKERS] row level lock and table level locks
Larry Douzie [EMAIL PROTECTED] writes: Is there a array or some sort of datastructures that store all the HeapTupleDatas for all rows in the db? Er, wouldn't that be the database files? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] FreeBSD/i386 thread test
FreeBSD 4.8/i386: Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe Chris - Original Message - From: Bruce Momjian [EMAIL PROTECTED] To: Kurt Roeckx [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 04, 2003 6:07 AM Subject: Re: [HACKERS] Unixware Patch (Was: Re: Beta2 Tag'd and Bundled ...) Kurt Roeckx wrote: On Wed, Sep 03, 2003 at 03:36:53PM -0400, Bruce Momjian wrote: I would like every operating system that supports thread-safety to run this program and report back the results. On a Linux system with glibc 2.1: Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe From a Linux system with libc5: Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FreeBSD/i386 thread test
Christopher Kings-Lynne wrote: FreeBSD 4.8/i386: Your gethostbyname() is _not_ thread-safe Your getpwuid() is _not_ thread-safe Your functions are _not_ all thread-safe Interesting. Do you have all the *_r files listed in thread.c? I sure hope so. I assume you used the template thread compile flags for this test. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Needed function IF(expr, expr, expr)
Any comments on the UNKNOWN issue? It's not too late to change that for 7.4, if we have consensus that we should. I would actually prefer to get UNKNOWN so I can apply my own default type, but we're not even given the chance to resolve the unknown issue ourselves. CREATE OR REPLACE FUNCTION if(bool,anyelement,anyelement) RETURNS anyelement AS 'SELECT CASE WHEN $2 is of (unknown) THEN CASE WHEN $1 THEN $2::point ELSE $3::point END ELSE CASE WHEN $1 THEN $2 ELSE $3 END END' language SQL; CREATE FUNCTION rbt=# select if(true, '33', '44'); ERROR: could not determine ANYARRAY/ANYELEMENT type because input is UNKNOWN signature.asc Description: This is a digitally signed message part
[HACKERS] Code insertion
Hi all, Just wondering if someone could help me with this rather specific problem. I am trying to figure out where i should insert some code that basically resets stats after a certain number of transactions(or sql statements) have been executed. Collects Stats after some more statements have been executed and continues to do this. I need to access these stats so i store them in Shared memory. The long term goal is to reset stats, collect stats, reset stats, collect second set of stats, compare 1st and second stats. Therefore i can't have the 1st or second stats rewritting itself. I had this problem when i tried to insert the code in the Executor under ExecutorRun(). Signed Very Desperate ---(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] [GENERAL] Needed function IF(expr, expr, expr)
Rod Taylor [EMAIL PROTECTED] writes: Any comments on the UNKNOWN issue? It's not too late to change that for 7.4, if we have consensus that we should. I would actually prefer to get UNKNOWN so I can apply my own default type, but we're not even given the chance to resolve the unknown issue ourselves. CREATE OR REPLACE FUNCTION if(bool,anyelement,anyelement) RETURNS anyelement AS 'SELECT CASE WHEN $2 is of (unknown) THEN CASE WHEN $1 THEN $2::point ELSE $3::point END ELSE CASE WHEN $1 THEN $2 ELSE $3 END END' language SQL; There's no chance of that working --- the parser has to be able to determine the result type of a function invocation without reference to the function body. (Otherwise CREATE OR REPLACE FUNCTION invalidates every use of the function.) I don't feel that the anyelement in - anyelement out mechanism is the last word in polymorphism, though. Care to propose additional features of the same kind? If you can find a way to describe the behavior you want in terms of the function signature, it'd be worth considering ... 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] [GENERAL] Needed function IF(expr, expr, expr)
I don't feel that the anyelement in - anyelement out mechanism is the last word in polymorphism, though. Care to propose additional features of the same kind? If you can find a way to describe the behavior you want in terms of the function signature, it'd be worth considering ... For my immediate purposes the output is a known type. It is the input that would be useful if it was passed through as unknown, or effectively function as a placeholder if a stronger match cannot be found. Due to inherited poorly typed data I find myself doing quite a bit of X_orNULL(anyelement) returns X. This takes quite a bit of interesting structure to make it work on the current system. CASE WHEN $1 IS OF (X) then $1 WHEN $1 IS OF (unknown) AND cancastX($1) THEN $1::X ELSE NULL::X END Another useful function would be an extension of IS OF with output somewhat like format_type. Returning a string of the datatype based upon the value passed to it. getType(anyelement) RETURNS text Order of type match for unknown: - Exact match first -- function(unknown) returns type - Cast match second - Anyelement match with defined return type should be supplied as UNKNOWN (per function examples above) If wanted, Anyelement match with anyelement return type could be converted to text. Perhaps this is best described as a fallback cast (when anyelement is unknown, autocast to X) CREATE FUNCTION x(anyelement) RETURNS anyelement LANGUAGE SQL RETURNS TYPE text ON UNKNOWN OUTPUT; Without this clause an error would be thrown as unknown is not a valid output. signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Index creation takes for ever
Bruce Momjian [EMAIL PROTECTED] writes: I assume this completes this TODO: * Order duplicate index entries by tid for faster heap lookups I don't know why that TODO entry exists, but I think the idea is counterproductive. The existing btree code will tend to put newer versions of a row earlier (because it puts a new entry in front of any with duplicate keys), which usually reduces the time spent skipping dead rows. Forcing tid ordering will cost us more in dead-row skipping than it's likely to save elsewhere. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Index creation takes for ever
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I assume this completes this TODO: * Order duplicate index entries by tid for faster heap lookups I don't know why that TODO entry exists, but I think the idea is counterproductive. The existing btree code will tend to put newer versions of a row earlier (because it puts a new entry in front of any with duplicate keys), which usually reduces the time spent skipping dead rows. Forcing tid ordering will cost us more in dead-row skipping than it's likely to save elsewhere. I assume you are talking about a unique index that probably only has a few non-expired rows (in which case the newer rows first is better). The TODO deals with cases where you have lots of valid duplicate index rows, and you want to spin through all the matching rows in heap order rather than randomly. This is related to our CLUSTER capability. The idea originally came from Vadim. At what point does this patch do the sorting? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] Index creation takes for ever
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: * Order duplicate index entries by tid for faster heap lookups I don't know why that TODO entry exists, but I think the idea is counterproductive. I assume you are talking about a unique index that probably only has a few non-expired rows (in which case the newer rows first is better). The TODO deals with cases where you have lots of valid duplicate index rows, and you want to spin through all the matching rows in heap order rather than randomly. Maybe so, but it would degrade the performance in the unique-index case if we do it as the TODO is worded. My own opinion is that the bitmap-index-lookup approach will be superior to trying to keep the index entries in TID order. (That's the idea we've been discussing for awhile of separating the heap-fetch stage from the index-scan stage: scan the index, make a sparse bitmap of the TIDs we need to visit, possibly AND or OR this bitmap with maps derived from other indexes, and finally visit the rows in heap order.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] Index creation takes for ever
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: * Order duplicate index entries by tid for faster heap lookups I don't know why that TODO entry exists, but I think the idea is counterproductive. I assume you are talking about a unique index that probably only has a few non-expired rows (in which case the newer rows first is better). The TODO deals with cases where you have lots of valid duplicate index rows, and you want to spin through all the matching rows in heap order rather than randomly. Maybe so, but it would degrade the performance in the unique-index case if we do it as the TODO is worded. Yes, the wording is just a guide. My own opinion is that the bitmap-index-lookup approach will be superior to trying to keep the index entries in TID order. (That's the idea we've been discussing for awhile of separating the heap-fetch stage from the index-scan stage: scan the index, make a sparse bitmap of the TIDs we need to visit, possibly AND or OR this bitmap with maps derived from other indexes, and finally visit the rows in heap order.) Oh, yes. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 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] Index creation takes for ever
On Sun, 7 Sep 2003 11:43:42 -0400 (EDT), Bruce Momjian [EMAIL PROTECTED] wrote: I assume this completes this TODO: * Order duplicate index entries by tid for faster heap lookups I don't think so, because the patch does nothing to keep the sort order once the index is initially created. If you want to post it now, [...] I did already post it. It's only the last page or so of the original message. The link in that message points to a testing aid which is not part of what I would like to see committed. Servus Manfred ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Unixware 713 probs
--On Sunday, September 07, 2003 14:19:00 -0500 Larry Rosenman
[EMAIL PROTECTED] wrote:
--On Sunday, September 07, 2003 20:22:30 +0200 [EMAIL PROTECTED] wrote:
[snip]
/usr/local/bin/gmake -C libpq all
gmake[3]: Entering directory `/home/postgres/pgsql/src/backend/libpq'
cc -O -Kinline,no_host -I../../../src/include -I/usr/local/include -c -o
ip.o ip.c UX:acomp: ERROR: ip.c, line 416: Syntax error before or at: .
UX:acomp: WARNING: ip.c, line 419: left operand of . must be
struct/union object UX:acomp: WARNING: ip.c, line 427: left operand of
. must be struct/union object UX:acomp: WARNING: ip.c, line 428: left
operand of . must be struct/union object UX:acomp: WARNING: ip.c,
line 429: left operand of . must be struct/union object UX:acomp:
WARNING: ip.c, line 430: left operand of . must be struct/union
object UX:acomp: ERROR: ip.c, line 451: Syntax error before or at: .
UX:acomp: ERROR: ip.c, line 452: invalid type combination
UX:acomp: WARNING: ip.c, line 455: left operand of . must be
struct/union object UX:acomp: WARNING: ip.c, line 464: left operand of
. must be struct/union object UX:acomp: WARNING: ip.c, line 465: left
operand of . must be struct/union object UX:acomp: WARNING: ip.c,
line 466: left operand of . must be struct/union object UX:acomp:
line 416 is:
int32 s_addr;
s_addr is seen by the compiler as:
uint32 __S_un . __S_addr ;
We need to pick another name.
LER
Here's a quickie patch I did to fix it.
Index: src/backend/libpq/ip.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/ip.c,v
retrieving revision 1.21
diff -u -r1.21 ip.c
--- src/backend/libpq/ip.c 5 Sep 2003 23:07:21 - 1.21
+++ src/backend/libpq/ip.c 7 Sep 2003 19:36:06 -
@@ -413,10 +413,10 @@
{
struct sockaddr_in addr4;
struct sockaddr_in6 addr6;
- uint32 s_addr;
+ uint32 pg_s_addr;
memcpy(addr4, addr, sizeof(addr4));
- s_addr = ntohl(addr4.sin_addr.s_addr);
+ pg_s_addr = ntohl(addr4.sin_addr.s_addr);
memset(addr6, 0, sizeof(addr6));
@@ -424,10 +424,10 @@
addr6.sin6_addr.s6_addr[10] = 0xff;
addr6.sin6_addr.s6_addr[11] = 0xff;
- addr6.sin6_addr.s6_addr[12] = (s_addr 24) 0xFF;
- addr6.sin6_addr.s6_addr[13] = (s_addr 16) 0xFF;
- addr6.sin6_addr.s6_addr[14] = (s_addr 8) 0xFF;
- addr6.sin6_addr.s6_addr[15] = (s_addr) 0xFF;
+ addr6.sin6_addr.s6_addr[12] = (pg_s_addr 24) 0xFF;
+ addr6.sin6_addr.s6_addr[13] = (pg_s_addr 16) 0xFF;
+ addr6.sin6_addr.s6_addr[14] = (pg_s_addr 8) 0xFF;
+ addr6.sin6_addr.s6_addr[15] = (pg_s_addr) 0xFF;
memcpy(addr, addr6, sizeof(addr6));
}
@@ -448,11 +448,11 @@
{
struct sockaddr_in addr4;
struct sockaddr_in6 addr6;
- uint32 s_addr;
+ uint32 pg_s_addr;
int i;
memcpy(addr4, addr, sizeof(addr4));
- s_addr = ntohl(addr4.sin_addr.s_addr);
+ pg_s_addr = ntohl(addr4.sin_addr.s_addr);
memset(addr6, 0, sizeof(addr6));
@@ -461,10 +461,10 @@
for (i = 0; i 12; i++)
addr6.sin6_addr.s6_addr[i] = 0xff;
- addr6.sin6_addr.s6_addr[12] = (s_addr 24) 0xFF;
- addr6.sin6_addr.s6_addr[13] = (s_addr 16) 0xFF;
- addr6.sin6_addr.s6_addr[14] = (s_addr 8) 0xFF;
- addr6.sin6_addr.s6_addr[15] = (s_addr) 0xFF;
+ addr6.sin6_addr.s6_addr[12] = (pg_s_addr 24) 0xFF;
+ addr6.sin6_addr.s6_addr[13] = (pg_s_addr 16) 0xFF;
+ addr6.sin6_addr.s6_addr[14] = (pg_s_addr 8) 0xFF;
+ addr6.sin6_addr.s6_addr[15] = (pg_s_addr) 0xFF;
memcpy(addr, addr6, sizeof(addr6));
}
also on my http://www.lerctr.org/~ler/postgresql page.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
ip.patch
Description: Binary data
pgp0.pgp
Description: PGP signature
