Re: [PATCHES] Updated instrumentation patch
Am Samstag, 30. Juli 2005 16:39 schrieb Magnus Hagander: * Added guc option disable_remote_admin, that disables any write operations (write, unlink, rename) even for the superuser. I think it would be better to avoid double negatives, so the option might be better named enable_remote_admin with the inverted logic. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] per user/database connections limit again
Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian: Would this not work in the context of the general user-specific ALTER USER ... SET something = something? No because it isn't a GUC variable, it is per-user/db value. GUC supports per-user/per-db values. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] per user/database connections limit again
Peter Eisentraut [EMAIL PROTECTED] writes: Am Montag, 1. August 2005 16:08 schrieb Bruce Momjian: Would this not work in the context of the general user-specific ALTER USER ... SET something = something? No because it isn't a GUC variable, it is per-user/db value. GUC supports per-user/per-db values. But not in the style that we'd want this to work. You couldn't just invent a single connection_limit variable, because a per-user setting would override a per-database setting, which is not the desired behavior. You'd have to invent two separate GUC variables, and there would be nothing except convention enforcing that they be set through ALTER USER and ALTER DATABASE rather than at other random places. We could do it that way, but it strikes me as messy and confusing, and I don't see any actual benefit other than saving a few lines of (already written) code. In what way would a GUC-based implementation be more useful than what's there? 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: [PATCHES] per user/database connections limit again
Peter Eisentraut wrote: GUC supports per-user/per-db values. We already had discussion here about GUC for this and we agreed that catalog change is better than new GUC variable in this case. -- Regards Petr Jelinek (PJMODOS) ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] PL/pgSQL: EXCEPTION NOSAVEPOINT
This was motivated by the SELECT INTO EXACT discussion at http://archives.postgresql.org/pgsql-patches/2005-07/msg00559.php. The idea is to allow a PL/pgSQL exception to not automatically rollback the work done by the current block. The benefit is that exception handling can be used as a program flow control technique, without invoking transaction management mechanisms. This also adds additional means to enhanced Oracle PL/SQL compatibility. The patch implements an optional NOSAVEPOINT keyword after the EXCEPTION keyword that begins the exception handler definition. Here is an excerpt from the patched documentation: beginning of excerpt--- If NOSAVEPOINT is not specified then a transaction savepoint is established immediately prior to the execution of statements. If an exception is raised then the effects of statements on the database are rolled back to this savepoint. If NOSAVEPOINT is specified then no savepoint is established. In this case a handled exception does not roll back the effects of statements. An unhandled exception, however, will still propagate out as usual, and any database effects may or may not be rolled back, depending on the characteristics of the enclosing block(s). Tip: Establishing a savepoint can be expensive. If you do not need the ability rollback the block's effect on the database, then either use the NOSAVEPOINT option, or avoid the EXCEPTION clause altogether. end of excerpt--- Implementation question: In pl_exec.c the new option causes the BeginInternalSubTransaction, ReleaseCurrentSubTransaction, and RollbackAndReleaseCurrentSubTransaction function calls to be skipped. However, the corresponding MemoryContextSwitchTo and related calls are still performed. Should these calls also be dependent on the new option? Would that be more correct, and/or a performance improvement? Index: doc/src/sgml/plpgsql.sgml === RCS file: /var/local/pgcvs/pgsql/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.75 diff -c -r1.75 plpgsql.sgml *** doc/src/sgml/plpgsql.sgml 2 Jul 2005 08:59:47 - 1.75 --- doc/src/sgml/plpgsql.sgml 3 Aug 2005 19:42:48 - *** *** 2086,2092 replaceabledeclarations/replaceable /optional BEGIN replaceablestatements/replaceable ! EXCEPTION WHEN replaceablecondition/replaceable optional OR replaceablecondition/replaceable ... /optional THEN replaceablehandler_statements/replaceable optional WHEN replaceablecondition/replaceable optional OR replaceablecondition/replaceable ... /optional THEN --- 2086,2092 replaceabledeclarations/replaceable /optional BEGIN replaceablestatements/replaceable ! EXCEPTION optionalNOSAVEPOINT/optional WHEN replaceablecondition/replaceable optional OR replaceablecondition/replaceable ... /optional THEN replaceablehandler_statements/replaceable optional WHEN replaceablecondition/replaceable optional OR replaceablecondition/replaceable ... /optional THEN *** *** 2104,2117 processing of the replaceablestatements/replaceable is abandoned, and control passes to the literalEXCEPTION/ list. The list is searched for the first replaceablecondition/replaceable ! matching the error that occurred. If a match is found, the ! corresponding replaceablehandler_statements/replaceable are ! executed, and then control passes to the next statement after ! literalEND/. If no match is found, the error propagates out ! as though the literalEXCEPTION/ clause were not there at all: ! the error can be caught by an enclosing block with ! literalEXCEPTION/, or if there is none it aborts processing ! of the function. /para para --- 2104,2140 processing of the replaceablestatements/replaceable is abandoned, and control passes to the literalEXCEPTION/ list. The list is searched for the first replaceablecondition/replaceable ! matching the error that occurred. If a match is found, then the ! exception is considered handled, and the corresponding ! replaceablehandler_statements/replaceable are executed. Control ! then passes to the next statement after literalEND/. If no match ! is found, the unhandled error propagates out as though the ! literalEXCEPTION/ clause were not there at all. The error can then ! be caught by an enclosing block with literalEXCEPTION/, or if there ! is none it aborts processing of the function. ! /para ! ! para ! If literalNOSAVEPOINT/literal is not specified then a transaction ! savepoint is established immediately prior to the execution of ! replaceablestatements/replaceable. If an exception is raised then ! the effects of replaceablestatements/replaceable on the database ! are rolled back to
Re: [PATCHES] PL/pgSQL: EXCEPTION NOSAVEPOINT
Matt Miller [EMAIL PROTECTED] writes: The idea is to allow a PL/pgSQL exception to not automatically rollback the work done by the current block. This fundamentally breaks the entire backend. You do not have the option to continue processing after elog(ERROR); the (sub)transaction rollback is necessary to clean up inconsistent state. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] PL/pgSQL: EXCEPTION NOSAVEPOINT
On Wed, 2005-08-03 at 16:25 -0400, Tom Lane wrote: The idea is to allow a PL/pgSQL exception to not automatically rollback the work done by the current block. This fundamentally breaks the entire backend. Yeah, but besides that, can you quick commit this to HEAD so I don't have to keep track of it locally? Just kidding. You do not have the option to continue processing after elog(ERROR); the (sub)transaction rollback is necessary to clean up inconsistent state. Okay, I'll look at this more closely. Can you give me an example of what can go wrong? ---(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: [PATCHES] PL/pgSQL: EXCEPTION NOSAVEPOINT
Matt Miller [EMAIL PROTECTED] writes: On Wed, 2005-08-03 at 16:25 -0400, Tom Lane wrote: You do not have the option to continue processing after elog(ERROR); the (sub)transaction rollback is necessary to clean up inconsistent state. Okay, I'll look at this more closely. Can you give me an example of what can go wrong? Well, for example, failure to release locks and buffer pins held by an abandoned query. Memory leaks. Row versions inserted into the database that will be seen as good because they're marked as being generated by the outer transaction, rather than coming from a subtransaction that can be separately marked as aborted. Pretty much everything done by AbortSubTransaction can be seen as cleanup... The only way you could get the effect you are after would be to run a new subtransaction for each executed query; which is not impossible but the overhead would be appalling :-( regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
