Re: [HACKERS] Attempt to stop dead instance can stop a random process?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Sep 01, 2007 at 12:57:35AM -0400, Tom Lane wrote: > [EMAIL PROTECTED] writes: > > Hm. I've come to expect the OS removing all pidfiles early at bootup. > > If there's a script in your system that does that, then adding Postgres > lockfiles to it makes all kinds of sense. Our problem as upstream > software is that this isn't something well-standardized that we could > plug into ... Right -- this becomes the distributor's job (when compiling from sources, the distributor is the sysadmin). Upstream can only recommend. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFG2R2XBcgs9XrR2kYRAoNDAJ9gN3ytdJzXyzJ0/MKTzWVZvq/X3ACfZtQm cVYkpNrJqhvRjtUvm/5co0c= =HBPE -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Per-function search_path => per-function GUC settings
I believe we had consensus that 8.3 needs to include an easier way for a function to set a local value of search_path, as proposed here: http://archives.postgresql.org/pgsql-hackers/2007-03/msg01717.php I've been holding off actually implementing that because adding a column to pg_proc would create merge problems for pending patches. But tsearch was the last one with any major changes to pg_proc.h, so it's probably time to get on with it. A few days ago, Simon suggested that we should generalize this notion to allow per-function settings of any GUC variable: http://archives.postgresql.org/pgsql-hackers/2007-08/msg01155.php My reaction to that was more or less "D'oh, of course!" Stuff like regex_flavor can easily break a function. So rather than thinking only about search_path, it seems to me we should implement a facility that allows function-local settings of any USERSET GUC variable, and probably also SUSET ones if the function is SECURITY DEFINER and owned by a superuser. The most straightforward way to support this syntactically seems to be to follow the per-user and per-database GUC setting features: ALTER FUNCTION func(args) SET var = value ALTER FUNCTION func(args) RESET var The RESET alternative is a lot cleaner than my previous suggestion of "PATH NONE" to remove a non-default path setting, anyway. I thought about ways to include GUC settings directly into CREATE FUNCTION, but it seemed pretty ugly and inconsistent with the existing syntax. So I'm thinking of supporting only the above syntaxes, meaning it'll take at least two commands to create a secure SECURITY DEFINER function. Comments? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Linkage for escape strings
Just a minor doc upgrade. I've linked a couple of the more prominent mentions of "escape string syntax" in Functions and Operators / Pattern Matching back to the section on SQL string literals, which explains how escape syntax works. I considering linking all mentions of escape syntax, but thought that might be overkill since there are so many of them. Thanks for your time, BJ Index: doc/src/sgml/func.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/func.sgml,v retrieving revision 1.392 diff -c -r1.392 func.sgml *** doc/src/sgml/func.sgml 31 Aug 2007 21:33:48 - 1.392 --- doc/src/sgml/func.sgml 1 Sep 2007 17:09:45 - *** *** 2929,2942 ! Note that the backslash already has a special meaning in string ! literals, so to write a pattern constant that contains a backslash ! you must write two backslashes in an SQL statement (assuming escape ! string syntax is used). Thus, writing a pattern ! that actually matches a literal backslash means writing four backslashes ! in the statement. You can avoid this by selecting a different escape ! character with ESCAPE; then a backslash is not special ! to LIKE anymore. (But it is still special to the string literal parser, so you still need two of them.) --- 2929,2942 ! Note that the backslash already has a special meaning in string literals, ! so to write a pattern constant that contains a backslash you must write two ! backslashes in an SQL statement (assuming escape string syntax is used, see ! ). Thus, writing a pattern that ! actually matches a literal backslash means writing four backslashes in the ! statement. You can avoid this by selecting a different escape character ! with ESCAPE; then a backslash is not special to ! LIKE anymore. (But it is still special to the string literal parser, so you still need two of them.) *** *** 3549,3555 meaning in PostgreSQL string literals. To write a pattern constant that contains a backslash, you must write two backslashes in the statement, assuming escape ! string syntax is used. --- 3549,3555 meaning in PostgreSQL string literals. To write a pattern constant that contains a backslash, you must write two backslashes in the statement, assuming escape ! string syntax is used (see ). ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCH] Lazy xid assingment V2
August Zajonc <[EMAIL PROTECTED]> writes: > I do have a question about jamming though. Will the system work if the > file ended up stuck in this folder? Let's say the move destination has a > duplicate file that conflicts, or permissions change under you, or disks > fill. Yeah, the move-the-file approach seems to introduce its own set of failure modes, which hardly seems like something we want. I had an idea this morning that might be useful: back off the strength of what we try to guarantee. Specifically, does it matter if we leak a file on crash, as long as it isn't occupying a lot of disk space? (I suppose if you had enough crashes to accumulate many thousands of leaked files, the directory entries would start to be a performance drag, but if your DB crashes that much you have other problems.) This leads to the idea that we don't really need to protect the open(O_CREAT) per se. Rather, we can emit a WAL entry *after* successful creation of a file, while it's still empty. This eliminates all the issues about logging an action that might fail. The WAL entry would need to include the relfilenode and the creating XID. Crash recovery would track these until it saw the commit or abort or prepare record for the XID, and if it didn't find any, would remove the file. With this approach I think we'd not even need to force-fsync the WAL entry; instead treat it like an async COMMIT record (pass its LSN to the walwriter). Even in the absence of any subsequent WAL activity, it would reach disk via the walwriter before the new file could be filled to a size that would bother anyone. (If the new file is being filled via WAL-logged insertions, then you can probably make even stronger statements than that, but we do have operations like COPY and CREATE INDEX that can fill a file with unlogged insertions.) So the performance impact would be about nil. I still don't think that this area is in urgent need of a fix, but I wanted to get this idea into the archives. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Per-function search_path => per-function GUC settings
On 9/2/07, Tom Lane <[EMAIL PROTECTED]> wrote: > I thought about ways to include GUC settings directly into CREATE > FUNCTION, but it seemed pretty ugly and inconsistent with the > existing syntax. So I'm thinking of supporting only the above > syntaxes, meaning it'll take at least two commands to create a secure > SECURITY DEFINER function. There's a niceness to being able to tell Postgres everything it needs to know about a function in the one CREATE FUNCTION command. So if we integrated the GUC settings into CREATE FUNCTION, we'd end up writing something like CREATE FUNCTION foo(int) RETURNS int AS $$ ... $$ LANGUAGE plpgsql STABLE STRICT SECURITY DEFINER RESET search_path SET regex_flavor = 'cinnamon'; That doesn't seem especially horrible. In what way do you feel it is inconsistent with existing syntax? And ... although I'll admit this is a paranoid thing to mention, if you have to fix the search_path setting *after* creating a function as SECURITY DEFINER, then there is necessarily a short period of time where the function exists and is insecure. Cheers, BJ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Per-function search_path => per-function GUC settings
"Tom Lane" <[EMAIL PROTECTED]> writes: > I thought about ways to include GUC settings directly into CREATE > FUNCTION, but it seemed pretty ugly and inconsistent with the > existing syntax. So I'm thinking of supporting only the above > syntaxes, meaning it'll take at least two commands to create a secure > SECURITY DEFINER function. I think security definer functions should automatically inherit their search_path. The whole "secure by default" thing. It might be best to have a guc variable which controls the variables which are automatically saved. regexp_flavour and maybe a handful of others could be in it by default. But that might depend on how expensive it is at run-time. I wouldn't want trivial SQL functions to no longer be inline-able because one might one day use a regexp for example. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Per-function search_path => per-function GUC settings
"Brendan Jurd" <[EMAIL PROTECTED]> writes: > CREATE FUNCTION foo(int) RETURNS int AS $$ > ... > $$ > LANGUAGE plpgsql > STABLE > STRICT > SECURITY DEFINER > RESET search_path > SET regex_flavor = 'cinnamon'; > That doesn't seem especially horrible. In what way do you feel it is > inconsistent with existing syntax? Hmm ... I hadn't thought of including SET in the syntax, so I was running into problems with distingushing GUC variable names from the keywords that are already in the syntax. That way would work from a grammar point of view. It still seems a bit inconsistent to me, but we could live with it. Comments anyone? > And ... although I'll admit this is a paranoid thing to mention, if > you have to fix the search_path setting *after* creating a function as > SECURITY DEFINER, then there is necessarily a short period of time > where the function exists and is insecure. You already have that issue with respect to the default public execute permissions on the function. The standard solution is to do it in a transaction block --- then no one can even see the function until you commit. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Per-function search_path => per-function GUC settings
Gregory Stark <[EMAIL PROTECTED]> writes: > I think security definer functions should automatically inherit their > search_path. The whole "secure by default" thing. This assumes that the search path at creation time has something to do with the path you'd like to use at execution, which is unlikely to be the case in existing pg_dump output, to name one example. I don't really want to get into doing the above. > It might be best to have a guc variable which controls the variables which are > automatically saved. regexp_flavour and maybe a handful of others could be in > it by default. But that might depend on how expensive it is at run-time. I > wouldn't want trivial SQL functions to no longer be inline-able because one > might one day use a regexp for example. Well, security definer functions can't be inlined anyway, so as long as you only try to do this for sec-def functions it wouldn't be an issue. I just think it's too big a departure from existing behavior, and will probably break more things than it fixes. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCH] Lazy xid assingment V2
Tom Lane wrote: > I had an idea this morning that might be useful: back off the strength > of what we try to guarantee. Specifically, does it matter if we leak a > file on crash, as long as it isn't occupying a lot of disk space? > (I suppose if you had enough crashes to accumulate many thousands of > leaked files, the directory entries would start to be a performance drag, > but if your DB crashes that much you have other problems.) This leads > to the idea that we don't really need to protect the open(O_CREAT) per > se. Rather, we can emit a WAL entry *after* successful creation of a > file, while it's still empty. This eliminates all the issues about > logging an action that might fail. The WAL entry would need to include > the relfilenode and the creating XID. Crash recovery would track these > until it saw the commit or abort or prepare record for the XID, and if > it didn't find any, would remove the file. That idea, like all other approaches based on tracking WAL records, fail if there's a checkpoint after the WAL record (and that's quite likely to happen if the file is large). WAL replay wouldn't see the file creation WAL entry, and wouldn't know to track the xid. We'd need a way to carry the information over checkpoints. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in DefineIndex(): it was continuing to access the
Hi Tom and Andrew, On Thu, 30 Aug 2007, Tom Lane wrote: > Date: Thu, 30 Aug 2007 10:04:34 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Andrew Dunstan <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], PostgreSQL-development > Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix brain fade in > DefineIndex(): it was continuing to access the > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > >> I've just configure centaur (CentOS 5) like this. > >> Do you need it for every version (8.1, 8.2) or just HEAD > >> Do you need it just once a week or every run? > >> I can also configure wharthog (unixware) like this if you need... > > > I have no idea - probably just HEAD, but Tom will have a better idea :-) > > HEAD only is enough IMHO. If we find any bugs it should be pretty > obvious whether they need to be back-patched. > > regards, tom lane > While waiting for my application for another animal, I made some tests and was surprised that cluster test failed with an ordering error. Maybe an ORDER BY is missing in the test query. Here's an exerpt of check.log: == creating temporary installation== == initializing database system == == starting postmaster== running on port 55678 with pid 6928 == creating database "regression" == CREATE DATABASE ALTER DATABASE == installing plpgsql == CREATE LANGUAGE == running regression test queries== parallel group (15 tests): text name oid char float4 int2 boolean varchar int8 float8 int4 uuid bit enum numeric boolean ... ok char ... ok name ... ok varchar ... ok text ... ok int2 ... ok int4 ... ok int8 ... ok oid ... ok float4 ... ok float8 ... ok bit ... ok numeric ... ok uuid ... ok enum ... ok test strings ... ok test numerology ... ok parallel group (18 tests): comments path lseg time timetz reltime polygon tinterval box circle abstime tstypes point interval timestamptz timestamp date inet point... ok lseg ... ok box ... ok path ... ok polygon ... ok circle ... ok date ... ok time ... ok timetz ... ok timestamp... ok timestamptz ... ok interval ... ok abstime ... ok reltime ... ok tinterval... ok inet ... ok tstypes ... ok comments ... ok parallel group (5 tests): geometry horology type_sanity oidjoins opr_sanity geometry ... ok horology ... ok oidjoins ... ok type_sanity ... ok opr_sanity ... ok test insert ... ok test create_function_1... ok test create_type ... ok test create_table ... ok test create_function_2... ok parallel group (2 tests): copy copyselect copy ... ok copyselect ... ok parallel group (8 tests): create_operator create_aggregate vacuum drop_if_exists create_misc constraints inherit triggers constraints ... ok triggers ... ok create_misc ... ok create_aggregate ... ok create_operator ... ok inherit ... ok vacuum ... ok drop_if_exists ... ok parallel group (2 tests): create_view create_index create_index ... ok create_view ... ok test sanity_check ... ok test errors ... ok test select ... ok parallel group (20 tests): select_distinct_on btree_index select_into delete select_distinct namespace update hash_index select_having union case random select_implicit prepared_xacts aggregates transactions subselect portals join arrays select_into ... ok select_distinct ... ok select_distinct_on ... ok select_implicit ... ok select_having... ok subselect... ok union... ok case ... ok join ... ok aggregates ... ok transactions ... ok random ... ok portals ... ok arrays ... ok btree_index ... ok hash_index ... ok update ... ok namespace
Re: [HACKERS] Per-function search_path => per-function GUC settings
"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> I think security definer functions should automatically inherit their >> search_path. The whole "secure by default" thing. > > This assumes that the search path at creation time has something to do > with the path you'd like to use at execution, which is unlikely to be > the case in existing pg_dump output, to name one example. I don't > really want to get into doing the above. pg_dump will have to do a ALTER FUNCTION SET command anyways, no? So the default search_path that gets saved doesn't really matter. In general if it's not the search path you want at run-time you just have to change it, but you should always have *something* set or else it's a wide open security hole. I'm not clear why the search path at creation time is such a bad choice anyways, it is security "definer", what's the difference between taking the userid from the defining environment and taking the search path from the defining environment? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Per-function search_path => per-function GUC settings
On Sat, 2007-09-01 at 12:41 -0400, Tom Lane wrote: > A few days ago, Simon suggested that we should generalize this notion > to allow per-function settings of any GUC variable: > http://archives.postgresql.org/pgsql-hackers/2007-08/msg01155.php > My reaction to that was more or less "D'oh, of course!" Stuff like > regex_flavor can easily break a function. So rather than thinking > only about search_path, it seems to me we should implement a facility > that allows function-local settings of any USERSET GUC variable, and > probably also SUSET ones if the function is SECURITY DEFINER and owned by > a superuser. > > The most straightforward way to support this syntactically seems to > be to follow the per-user and per-database GUC setting features: > > ALTER FUNCTION func(args) SET var = value > I was hoping this feature would make it easier for modules to install into any schema. Right now a module can either preprocess a SQL install script to install it into the schema you want, or hard-code the schema into the file and you're stuck with whatever schema the module authors chose (usually either the module name, or "public"). Can we also provide syntax which would be equivalent to setting "var" for the function to be whatever the current value happens to be when the ALTER FUNCTION is run? Possible syntax might be something like: ALTER FUNCTION func(args) SET var TO CURRENT; > I thought about ways to include GUC settings directly into CREATE > FUNCTION, but it seemed pretty ugly and inconsistent with the > existing syntax. So I'm thinking of supporting only the above > syntaxes, meaning it'll take at least two commands to create a secure > SECURITY DEFINER function. That seems a little awkward, because to avoid a security race condition, you'd have to wrap the CREATE/ALTER in a transaction block. However, we already have a similar situation with creating a security definer function and then revoking access, so maybe it's already expected. I don't have a strong opinion, I just wanted to bring that up. Regards, Jeff Davis ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Per-function search_path => per-function GUC settings
Jeff Davis <[EMAIL PROTECTED]> writes: > Can we also provide syntax which would be equivalent to setting "var" > for the function to be whatever the current value happens to be when the > ALTER FUNCTION is run? Possible syntax might be something like: > ALTER FUNCTION func(args) SET var TO CURRENT; Hmmm ... that's certainly do-able, though I'm not sure how much it helps the use-case you suggest. The search path still has to be set at the top of the module script, no? However, I like an explicit option of this sort a lot better than the automatic version Greg was suggesting ... I'm willing to do it if people want it. One problem is that we'd have to make CURRENT a reserved word to make it work exactly like that. Can anyone think of a variant syntax that doesn't need a new reserved word? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Per-function search_path => per-function GUC settings
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> This assumes that the search path at creation time has something to do >> with the path you'd like to use at execution, which is unlikely to be >> the case in existing pg_dump output, to name one example. I don't >> really want to get into doing the above. > pg_dump will have to do a ALTER FUNCTION SET command anyways, no? You're missing the point: this change will break existing pg_dump output, because pg_dump feels free to set the search_path for its own purposes. The same is true of other GUC variables that might be automatically absorbed into CREATE FUNCTION: there is not any very good reason to suppose that their values when the dump is restored are really what should be used. The argument is slightly more credible with respect to interactively-issued commands, but for pg_dump it's simply wrong. What we might change pg_dump to do in future is a separate topic, but we can't make that kind of change in the semantics of existing dumps. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Per-function search_path => per-function GUC settings
On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: > > Can we also provide syntax which would be equivalent to setting "var" > > for the function to be whatever the current value happens to be when the > > ALTER FUNCTION is run? Possible syntax might be something like: > > > ALTER FUNCTION func(args) SET var TO CURRENT; > > Hmmm ... that's certainly do-able, though I'm not sure how much it helps > the use-case you suggest. The search path still has to be set at the > top of the module script, no? > > However, I like an explicit option of this sort a lot better than the > automatic version Greg was suggesting ... I'm willing to do it if people > want it. > > One problem is that we'd have to make CURRENT a reserved word to make it > work exactly like that. Can anyone think of a variant syntax that > doesn't need a new reserved word? > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > +1 for being able to define the entire function in one command, +1 for not inheriting a bunch of GUC settings without the definer's explicit say-so. - Josh/Eggyknap ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCH] Lazy xid assingment V2
Heikki Linnakangas wrote: Tom Lane wrote: I had an idea this morning that might be useful: back off the strength of what we try to guarantee. Specifically, does it matter if we leak a file on crash, as long as it isn't occupying a lot of disk space? (I suppose if you had enough crashes to accumulate many thousands of leaked files, the directory entries would start to be a performance drag, but if your DB crashes that much you have other problems.) This leads to the idea that we don't really need to protect the open(O_CREAT) per se. Rather, we can emit a WAL entry *after* successful creation of a file, while it's still empty. This eliminates all the issues about logging an action that might fail. The WAL entry would need to include the relfilenode and the creating XID. Crash recovery would track these until it saw the commit or abort or prepare record for the XID, and if it didn't find any, would remove the file. That idea, like all other approaches based on tracking WAL records, fail if there's a checkpoint after the WAL record (and that's quite likely to happen if the file is large). WAL replay wouldn't see the file creation WAL entry, and wouldn't know to track the xid. We'd need a way to carry the information over checkpoints. Yes, checkpoints would need to include a list of created-but-yet-uncommitted files. I think the hardest part is figuring out a way to get that information to the backend doing the checkpoint - my idea was to track them in shared memory, but that would impose a hard limit on the number of concurrent file creations. Not nice :-( But wait... I just had an idea. We already got such a central list of created-but-uncommited files - pg_class itself. There is a small window between file creation and inserting the name into pg_class - but as Tom says, if we leak it then, it won't use up much space anyway. So maybe we should just scan pg_class on VACUUM, and obtain a list of files that are referenced only from DEAD tuples. Those files we can than safely delete, no? If we *do* want a strict no-leakage guarantee, than we'd have to update pg_class before creating the file, and flush the WAL. If we take Alvaro's idea of storing temporary relations in a seperate directory, we could skip the flush for those, because we can just clean out that directory after recovery. Having to flush the WAL when creating non-temporary relations doesn't sound too bad - those operations won't occur very often, I'd say. greetings, Florian Pflug ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Per-function search_path => per-function GUC settings
On Sep 1, 2007, at 1:36 PM, Brendan Jurd wrote: So if we integrated the GUC settings into CREATE FUNCTION, we'd end up writing something like CREATE FUNCTION foo(int) RETURNS int AS $$ ... $$ LANGUAGE plpgsql STABLE STRICT SECURITY DEFINER RESET search_path SET regex_flavor = 'cinnamon'; That doesn't seem especially horrible. In what way do you feel it is inconsistent with existing syntax? I like this and would really like to see way to set everything using CREATE FUNCTION. Using ALTER only requires maintaining a separate copy of of function arguments which can be a hassle for large argument lists. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCH] Lazy xid assingment V2
August Zajonc wrote: Yes, checkpoints would need to include a list of created-but-yet-uncommitted files. I think the hardest part is figuring out a way to get that information to the backend doing the checkpoint - my idea was to track them in shared memory, but that would impose a hard limit on the number of concurrent file creations. Not nice :-( I'm confused about this. As long as we assert the rule that the file name can't change on the move, then after commit the file can be in only one of two places. The name of the file is known (ie, pg_class). The directories are known. What needs to be carried forwarded past a checkpoint? We don't even look at WAL, so checkpoints are irrelevant it seems > If there is a crash just after commit and before the move, no harm. You just move on startup. If the move fails, no harm, you can emit warning and open in /pending (or simply error, even easier). If you're going to open the file from /pending, whats the point of moving it in the first place? The idea would have to be that you move on commit (Or on COMMIT-record replay, in case of a crash), and then, after recovering the whole wal, you could remove leftover files in /pending. The main problem is that you have to do the move *after* flushing the COMMIT record to disk - otherwise you're gonna leak the file if you crash between moving and flushing. But that implies that the transaction is *already* committed when you do the move. Others won't know that yet (You do the move *after* flushing, but *before* updating the CLOG) - but still, since the COMMIT-record is on disk, you cannot rollback anymore (Since if you crash, and replay the COMMIT record, the transaction *will* be committed). So, what are you going to do if the move fails? You cannot roll back, and you cannot update the CLOG (because than others would see your new table, but no datafile). The only option is to PANIC. This will lead to a server restart, WAL recovery, and probably another PANIC once the COMMIT-record is replayed (Since the move probably still won't be possible). It might be even worse - I'm not sure that a rename is an atomic operation on most filesystems. If it's not, then you might end up with two files if power fails *just* as you rename, or, worse with no file at all. Even a slight possibility of the second case seems unacceptable - I means loosing a committed transaction. I agree that we should eventually find a way to guarantee either no file leakage, or at least an upper bound on the amount of wasted space. But doing so at the cost of PANICing if the move fails seems like a bad tradeoff... greetings, Florian Pflug ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCH] Lazy xid assingment V2
"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > It might be even worse - I'm not sure that a rename is an atomic operation > on most filesystems. rename(2) is specified to be atomic by POSIX, but relinking a file into a different directory can hardly be --- it's not even provided as a single kernel call, is it? And there's still the problem that changing the filename on-the-fly is going to break tons of low-level stuff, most of which is not supposed to know about transactions at all, notably bgwriter. What I was thinking about was a "flag file" separate from the data file itself, a bit like what we use for archiver signaling. If is the new data file, then "touch .new" to mark the file as needing to be deleted on restart. Remove these files just *before* commit. This leaves you with a narrow window between removing the flag file and actually committing, but there's no risk of having to PANIC --- if the remove fails, you just abort the transaction. However, this has nonzero overhead compared to the current behavior. I'm still dubious that we have a problem that needs solving ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCH] Lazy xid assingment V2
Florian G. Pflug wrote: August Zajonc wrote: I'm confused about this. As long as we assert the rule that the file name can't change on the move, then after commit the file can be in only one of two places. The name of the file is known (ie, pg_class). The directories are known. What needs to be carried forwarded past a checkpoint? We don't even look at WAL, so checkpoints are irrelevant it seems If there is a crash just after commit and before the move, no harm. You just move on startup. If the move fails, no harm, you can emit warning and open in /pending (or simply error, even easier). If you're going to open the file from /pending, whats the point of moving it in the first place? Allow time for someone to sort out the disk situation without impacting things. Preserves the concept that after COMMIT a file exists on disk that is accessible, which is what people I think expect. The idea would have to be that you move on commit (Or on COMMIT-record replay, in case of a crash), and then, after recovering the whole wal, you could remove leftover files in /pending. I think so. What I was thinking was Limit to moves from spclocation/file.new to spclocation/file. So given a pg_class filename the datafile can only have two possible names. relfilenode or relfilenode.new you commit, then move. If crash occurs before commit, you leak a .new table. If move fails after commit you emit warning. The commit is still valid, because fopen can fall back to .new. The data is still there. On crash recovery move .new files that show up in pg_class to their proper name if the disk has been fixed and move can succeed. For .new files that don't exist in pg_class after log replay, delete them. Fallback open. fopen relfilenode, if ENOENT fopen relfilenode.new if ENOENT error elseif emit warning So, what are you going to do if the move fails? You cannot roll back, and you cannot update the CLOG (because than others would see your new table, but no datafile). The only option is to PANIC. This will lead to a server restart, WAL recovery, and probably another PANIC once the COMMIT-record is replayed (Since the move probably still won't be possible). That was the idea of the fallback generally, avoid this issue. You never rollback. If datafile is not where expected, it can only be one other place. It might be even worse - I'm not sure that a rename is an atomic operation on most filesystems. If it's not, then you might end up with two files if power fails *just* as you rename, or, worse with no file at all. Even a slight possibility of the second case seems unacceptable - I means loosing a committed transaction. Yes, atomic renames are an assumption. I agree that we should eventually find a way to guarantee either no file leakage, or at least an upper bound on the amount of wasted space. But doing so at the cost of PANICing if the move fails seems like a bad tradeoff... Agreed... greetings, Florian Pflug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCH] Lazy xid assingment V2
Tom Lane wrote: What I was thinking about was a "flag file" separate from the data file itself, a bit like what we use for archiver signaling. If is the new data file, then "touch .new" to mark the file as needing to be deleted on restart. Remove these files just *before* commit. This leaves you with a narrow window between removing the flag file and actually committing, but there's no risk of having to PANIC --- if the remove fails, you just abort the transaction. However, this has nonzero overhead compared to the current behavior. I'm still dubious that we have a problem that needs solving ... regards, tom lane Maybe just get back to the beginning: We are concerned about leaking files on *crashes*. So during recovery, the only time we are going to care, iterate through list of files that should exist (pg_class) after replay of log. Any files that don't belong (but fit the standard naming conventions) move to spclocation/trash or similar. For the admin who had critical data they needed to recover and is going to spend the time going to the disk too pull it out they still can access it. This also saves admins who create table like filenames in table spaces. For most other folks they can dump /trash. Does this avoid the dataloss worries? ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Per-function search_path => per-function GUC settings
On Sat, Sep 01, 2007 at 03:03:14PM -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > Can we also provide syntax which would be equivalent to setting "var"
> > for the function to be whatever the current value happens to be when the
> > ALTER FUNCTION is run? Possible syntax might be something like:
>
> > ALTER FUNCTION func(args) SET var TO CURRENT;
>
> Hmmm ... that's certainly do-able, though I'm not sure how much it helps
> the use-case you suggest. The search path still has to be set at the
> top of the module script, no?
Better one place than scores of places...
> However, I like an explicit option of this sort a lot better than the
> automatic version Greg was suggesting ... I'm willing to do it if people
> want it.
>
> One problem is that we'd have to make CURRENT a reserved word to make it
> work exactly like that. Can anyone think of a variant syntax that
> doesn't need a new reserved word?
I'm not good at the synonym game, but I did have an idea related to the
SET syntax, so I'll just post it here...
If you needed to set a bunch of GUCs on a function, having a load of SET
statements might be a bit tedious... I'm wondering if there's some way
to specify them like an array?
SET {'search_path=CURRENT', 'enable_seqscan=false', ...}
Or now that we have arrays of complex types, perhaps an array of type
GUC...
Either case would at least take care of CURRENT...
--
Decibel!, aka Jim Nasby[EMAIL PROTECTED]
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
pgpg1lqt11vA1.pgp
Description: PGP signature
Re: [HACKERS] Per-function search_path => per-function GUC settings
On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: > > Can we also provide syntax which would be equivalent to setting "var" > > for the function to be whatever the current value happens to be when the > > ALTER FUNCTION is run? Possible syntax might be something like: > > > ALTER FUNCTION func(args) SET var TO CURRENT; > > Hmmm ... that's certainly do-able, though I'm not sure how much it helps > the use-case you suggest. The search path still has to be set at the > top of the module script, no? > > However, I like an explicit option of this sort a lot better than the > automatic version Greg was suggesting ... I'm willing to do it if people > want it. > > One problem is that we'd have to make CURRENT a reserved word to make it > work exactly like that. Can anyone think of a variant syntax that > doesn't need a new reserved word? SET var FROM CURRENT SESSION -- marko ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Per-function search_path => per-function GUC settings
On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote: > I believe we had consensus that 8.3 needs to include an easier way for a > function to set a local value of search_path, as proposed here: > http://archives.postgresql.org/pgsql-hackers/2007-03/msg01717.php > I've been holding off actually implementing that because adding a column > to pg_proc would create merge problems for pending patches. But tsearch > was the last one with any major changes to pg_proc.h, so it's probably > time to get on with it. > > A few days ago, Simon suggested that we should generalize this notion > to allow per-function settings of any GUC variable: > http://archives.postgresql.org/pgsql-hackers/2007-08/msg01155.php > My reaction to that was more or less "D'oh, of course!" Stuff like > regex_flavor can easily break a function. So rather than thinking > only about search_path, it seems to me we should implement a facility > that allows function-local settings of any USERSET GUC variable, and > probably also SUSET ones if the function is SECURITY DEFINER and owned by > a superuser. > > The most straightforward way to support this syntactically seems to > be to follow the per-user and per-database GUC setting features: > > ALTER FUNCTION func(args) SET var = value Would it be hard to extend this into this? ALTER FUNCTION func(args) SET var = value [, var = value ...] > ALTER FUNCTION func(args) RESET var > > The RESET alternative is a lot cleaner than my previous suggestion > of "PATH NONE" to remove a non-default path setting, anyway. > > I thought about ways to include GUC settings directly into CREATE > FUNCTION, but it seemed pretty ugly and inconsistent with the > existing syntax. So I'm thinking of supporting only the above > syntaxes, meaning it'll take at least two commands to create a > secure SECURITY DEFINER function. With the extended syntax I proposed it could take just one command to create such a function :) Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Per-function search_path => per-function GUC settings
David Fetter <[EMAIL PROTECTED]> writes: > On Sat, Sep 01, 2007 at 12:41:28PM -0400, Tom Lane wrote: >> The most straightforward way to support this syntactically seems to >> be to follow the per-user and per-database GUC setting features: >> >> ALTER FUNCTION func(args) SET var = value > Would it be hard to extend this into this? > ALTER FUNCTION func(args) SET var = value [, var = value ...] Actually, it would be hard *not* to, because of the way the CREATE/ALTER FUNCTION syntax is already set up --- but without the commas. I've got it working now with SET and RESET as alternatives for common_func_opt_item. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Per-function search_path => per-function GUC settings
"Marko Kreen" <[EMAIL PROTECTED]> writes: > On 9/1/07, Tom Lane <[EMAIL PROTECTED]> wrote: >> One problem is that we'd have to make CURRENT a reserved word to make it >> work exactly like that. Can anyone think of a variant syntax that >> doesn't need a new reserved word? > SET var FROM CURRENT SESSION Seems a little verbose, but maybe we could do "SET var FROM CURRENT" or "SET var FROM SESSION"? One point worth noting here is that this'd more or less automatically apply to ALTER USER SET and ALTER DATABASE SET as well ... not sure how much use-case there is for those, but it'd fall out ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] synchronous_commit: Developer's View
On Thu, Aug 30, 2007 at 10:34:42PM +0100, Simon Riggs wrote: > Async Commit is a useful feature, yet it requires some additional > application code to be added to appropriate transactions. That code is > then clearly version dependent, which may not always be desirable. > > It would be good if there was a way to make that a DBA-controllable > setting, much the same as we might execute the following command: > > ALTER USER jimbob SET work_mem = ... > > The above commmand allows application SQL to be tuned without changes to > the application code itself. > > So I'm thinking, is there a way to decorate a transaction in such a way > that only that transaction knows to do > SET LOCAL synchronous_commit = off > > Perhaps it would be possible to do this > > ALTER FUNCTION fubar SET synchronous_commit = off; > > So that any invocation of the function would automatically set all of > the appropriate parameters prior to execution. > > Why do I mention this now? Well, on the 8.3 patch status list is the > concept of "per function search_path". search_path is a parameter, so > per function search path would seem to imply setting parameters on a per > function basis, exactly what I'm suggesting for enhancing async commit. > > Per function parameters could then also be used for other "Statement > Behaviour" parameters and other related ones, such as ... > > default_tablespace, temp_tablespaces, default_transaction_isolation, > statement_timeout, gin_fuzzy_search_limit, standard_conforming_strings, > regex_flavour, xmlbinary and xmloption. > > To do this, we would need to add a column to pg_proc named and defined: > procconfig text[] > named similarly to the rolconfig column of pg_authid > > This would then give us the flexibility to implement per function > search_path as well as the above mentioned uses. > > Thoughts? While we're at it, it would be very nice to be able to set default per-role, per-database settings. One obvious example of this is search_path, where in general no two databases in a cluster need share any common user-defined schema names. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Per-function GUC settings: trickier than it looked
So I coded up a patch for this, based on the idea of creating a quasi-subtransaction that affects only GUC while entering/exiting a function that has GUC settings attached. The specified settings are applied as if by SET LOCAL before starting function execution, and then they drop out during "subtransaction" exit. (I'll post the code to pgsql-patches in a moment.) But on reflection I realize that there are some interesting properties to this approach: * if you do "SET LOCAL foo" when you are in a function that has a "SET foo" property, the setting disappears at function exit. But if you do "SET foo" it persists. This might be OK, but it seems a bit odd. * in fact, if you do "SET LOCAL foo" when you are in a function that has any "SET" property at all, the setting disappears at function exit, whether foo was one of the variables SET by the function definition or not. We could perhaps get away with defining that as being the behavior, but it doubtless will surprise someone sometime. What *should* these interactions be like, and has anyone got an idea how to implement their suggestion? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] synchronous_commit: Developer's View
David Fetter <[EMAIL PROTECTED]> writes: > While we're at it, it would be very nice to be able to set default > per-role, per-database settings. Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCH] Lazy xid assingment V2
Tom Lane wrote: "Florian G. Pflug" <[EMAIL PROTECTED]> writes: It might be even worse - I'm not sure that a rename is an atomic operation on most filesystems. rename(2) is specified to be atomic by POSIX, but relinking a file into a different directory can hardly be --- it's not even provided as a single kernel call, is it? I'd have thought that they only guarantee that if the new name already exists it's atomically replaced. But I might be wrong And there's still the problem that changing the filename on-the-fly is going to break tons of low-level stuff, most of which is not supposed to know about transactions at all, notably bgwriter. Good point - I thought that we wouldn't have to care about this because we could close the relation before renaming in the committing backend and be done with it, because other backends won't see the new file before we update the clog. But you're right, bgwriter is a problem and one not easily solved... So that rename-on-commit idea seems to be quite dead... What I was thinking about was a "flag file" separate from the data file itself, a bit like what we use for archiver signaling. If is the new data file, then "touch .new" to mark the file as needing to be deleted on restart. Remove these files just *before* commit. This leaves you with a narrow window between removing the flag file and actually committing, but there's no risk of having to PANIC --- if the remove fails, you just abort the transaction. Hm.. we could call the file "nnn.xid.new", and delete it after the commit, silently ignoring any failures. During both database-wide VACUUM and after recovery we'd remove any leftover *.xid.new files, but only if the xid is marked committed in the clog. After that cleanup step, we'd delete any files which still have an associated flag file. Processing those nnn.xid.new files during VACUUM is just needed to avoid any problems because of xid wraparound - it could maybe be replaced by maybe naming the file nnn.epoch.xid.new However, this has nonzero overhead compared to the current behavior. I'm still dubious that we have a problem that needs solving ... I agree that file leakage is not a critical problem - if it were, they'd be much more complaints... But it's still something that a postgres DBA has to be aware of, because it might bite you quite badly. Since IMHO admin friendlyness is one of the strengths of postgresql, removing the possibility of leakage would be nice in the long term. Nothing that needs any rushing, though - and nothing that we'd want to pay for in terms of performance. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] synchronous_commit: Developer's View
On Sat, Sep 01, 2007 at 10:51:48PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > While we're at it, it would be very nice to be able to set default > > per-role, per-database settings. > > Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET? You can't set both at once. Let's imagine that you have two databases in a cluster: foo with schemas foo_1 and foo_2, and bar with schemas bar_1 and bar_2. There's no way (currently) to set a ROLE's foo search_path to foo_1,foo_2 and its bar search_path to bar_1, bar_2. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Per-function GUC settings: trickier than it looked
Tom Lane wrote: So I coded up a patch for this, based on the idea of creating a quasi-subtransaction that affects only GUC while entering/exiting a function that has GUC settings attached. The specified settings are applied as if by SET LOCAL before starting function execution, and then they drop out during "subtransaction" exit. (I'll post the code to pgsql-patches in a moment.) But on reflection I realize that there are some interesting properties to this approach: * if you do "SET LOCAL foo" when you are in a function that has a "SET foo" property, the setting disappears at function exit. But if you do "SET foo" it persists. This might be OK, but it seems a bit odd. That seems OK - the same happens inside a BEGIN/EXCEPTION/END block, no? * in fact, if you do "SET LOCAL foo" when you are in a function that has any "SET" property at all, the setting disappears at function exit, whether foo was one of the variables SET by the function definition or not. Hm... That is a bit surprising... Maybe all functions should create a such GUC-only substransaction-like thing. That might create problems for inlining - but only if you can actually change GUCs from plsql function, which maybe you cant... We could perhaps get away with defining that as being the behavior, but it doubtless will surprise someone sometime. What *should* these interactions be like, and has anyone got an idea how to implement their suggestion? What will happen if you have two functions, foo and bar, were the search-path is overridden for foo, and foo calls bar. I guess bar would be executed with foo's overridden searchpath. Thats seems a bit surprising - I'd make more sense to me if bar would use the session's search-path, but that seems hard to do... Especially because bar *should* use foo's searchpath if foo contained an explicit "SET LOCAL search_path" Or maybe I'm just crazy, and the current behavior is fine greetings, Florian Pflug ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] synchronous_commit: Developer's View
David Fetter <[EMAIL PROTECTED]> writes: > On Sat, Sep 01, 2007 at 10:51:48PM -0400, Tom Lane wrote: >> Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET? > You can't set both at once. Oh, you mean the cross-product case. Sorry, that was on the wish-list already, but no one saw it as a security issue, so it's not happening for 8.3. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] synchronous_commit: Developer's View
On Sat, Sep 01, 2007 at 11:07:55PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Sat, Sep 01, 2007 at 10:51:48PM -0400, Tom Lane wrote: > >> Er ... what deficiency do you see in ALTER ROLE SET and ALTER DATABASE SET? > > > You can't set both at once. > > Oh, you mean the cross-product case. Sorry, that was on the wish-list > already, but no one saw it as a security issue, so it's not happening > for 8.3. Sorry. I assumed we were talking about 8.4 stuff. Cheers, David -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCH] Lazy xid assingment V2
"Florian G. Pflug" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> rename(2) is specified to be atomic by POSIX, but relinking a file into >> a different directory can hardly be --- it's not even provided as a >> single kernel call, is it? > I'd have thought that they only guarantee that if the new name already > exists it's atomically replaced. But I might be wrong I reread the spec and realized that rename() does include moving a link into a different directory --- but it only promises that replacement of the target filename is atomic, not that (say) the link couldn't appear in both directories concurrently. Also it's not clear that the spec intends to make any hard guarantees about the filesystem state after crash-and-recovery. In any case I don't think we can make renaming of active data files work --- bufmgr and bgwriter need those file names to be stable. The flag-file approach seems more promising. There's also the plan B of scanning pg_class to decide which relfilenode values are legit. IIRC Bruce did up a patch for this about a year ago, which I vetoed because I was afraid of the consequences if it removed data that someone really needed. Someone just mentioned doing the same thing but pushing the unreferenced files into a "trash" directory instead of actually deleting them. While that answers the risk-of-data-loss objection, I'm not sure it does much for the goal of avoiding useless space consumption: how many DBAs will faithfully examine and clean out that trash directory? regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] GIST and GIN indexes on varchar[] aren't working in CVS.
There seems to be some behavior change in current CVS with respect to gist and gin indexes on varchar[]. Some side effect of the tsearch2 merge? \d search_pages Table "public.search_pages" Column |Type | Modifiers ---+-+--- page_name | character varying | cats | character varying[] | Indexes: "search_pages_page" UNIQUE, btree (page_name) create index search_pages_cats on search_pages using gin (cats); ERROR: missing support function 1 for attribute 1 of index "search_pages_cats" create index search_pages_cats on search_pages using gist (cats); ERROR: data type character varying[] has no default operator class for access method "gist" HINT: You must specify an operator class for the index or define a default operator class for the data type. This works fine in 8.2, for example: \d search_pages Table "public.search_pages" Column |Type | Modifiers ---+-+--- page_name | character varying | cats | character varying[] | Indexes: "search_pages_page" UNIQUE, btree (page_name) "search_pages_cats" gin (cats) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
