Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 06:42:31PM +0200, Manfred Koizar wrote: > On Wed, 28 Apr 2004 12:02:44 -0400, Alvaro Herrera > <[EMAIL PROTECTED]> wrote: > >In fact, I think we should mark ERROR as aborting the whole transaction > >tree, and create a new level which would abort the innermost > >subtransaction. We would then change whatever is appropiate to the new > >elevel. Doing otherwise would leave us open to unexpected conditions > >causing only subtrans abort, which could lead to unreliable behavior. > > Why? Subtransaction commit propagates an error state to the parent > transaction. And if a subtransaction is rolled back the parent can > continue cleanly no matter what was the reason for the subtrans abort. Not necessarily; consider can't-happen conditions, like everything that is marked elog(ERROR) rather than ereport(ERROR). Corrupt hashes, should-exist catalog entries that are not there, etc. They should not be frequent, be we should be prepared for them. -- Alvaro Herrera () "La virtud es el justo medio entre dos defectos" (Aristóteles) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 07:29:07PM +0200, Peter Eisentraut wrote: > Bruce Momjian wrote: > > I think his point was that there are some errors that should abort > > the outer transaction too. I think Alvaro mentioned out of memory, > > but that is a FATAL error. Alvaro, what error were you thinking of > > that should abort the outer transaction? > > Theoretically, if you abort the inner transaction, that could free up > memory for use by the outer transaction. Yes, this is planned to happen. -- Alvaro Herrera () "La tristeza es un muro entre dos jardines" (Khalil Gibran) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 02:42:23PM -0400, Tom Lane wrote: > In general I tend to agree with Manfred's point: if you have reason to > suspect global corruption of a backend's state then you should do FATAL > (or possibly PANIC). If you do not suspect this then you ought to just > ERROR. I do not see the use-case for abort-all-levels-of-xact-but- > don't-exit. Ok, I'm not wedded to the idea of a new elevel. So you think elog(ERROR) should rather be elog(FATAL) ? -- Alvaro Herrera () Y una voz del caos me habló y me dijo "Sonríe y sé feliz, podría ser peor". Y sonreí. Y fui feliz. Y fue peor. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 12:26:01AM -0400, Bruce Momjian wrote: > I don't understand your elog(ERROR) vs. ereport(ERROR) distinction. Was > that a typo? Nope. When Tom upgraded the error handling, he changed almost everything to ereport(), but in the places where there's a violation of expected conditions, he retained elog(). We don't provide special error code, nor there is space for errhints etc. Those unexpected conditions I thought we could just abort the transaction tree; but maybe we have to close the backend as Manfred and Tom say. I don't think there's space for PANIC though (unless we suspect shared state corruption ... is that checked for anywhere? I haven't looked.) -- Alvaro Herrera () "No single strategy is always right (Unless the boss says so)" (Larry Wall) ---(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: [PATCHES] Basic subtransaction facility
Bruce Momjian <[EMAIL PROTECTED]> writes: > Manfred Koizar wrote: >> Why? Subtransaction commit propagates an error state to the parent >> transaction. And if a subtransaction is rolled back the parent can >> continue cleanly no matter what was the reason for the subtrans abort. > I think his point was that there are some errors that should abort the > outer transaction too. I think Alvaro mentioned out of memory, but that > is a FATAL error. Nonsense. In the first place, out-of-memory hasn't been FATAL for years. In the second, there is no reason to think that we can't continue the outer transaction(s), as aborting the innermost one is likely to free quite a lot of memory. (And if it doesn't, well, the outer one will get its own out-of-memory ERROR soon enough.) In general I tend to agree with Manfred's point: if you have reason to suspect global corruption of a backend's state then you should do FATAL (or possibly PANIC). If you do not suspect this then you ought to just ERROR. I do not see the use-case for abort-all-levels-of-xact-but- don't-exit. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Basic subtransaction facility
Bruce Momjian wrote: > I think his point was that there are some errors that should abort > the outer transaction too. I think Alvaro mentioned out of memory, > but that is a FATAL error. Alvaro, what error were you thinking of > that should abort the outer transaction? Theoretically, if you abort the inner transaction, that could free up memory for use by the outer transaction. ---(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: [PATCHES] Basic subtransaction facility
Manfred Koizar wrote: > On Wed, 28 Apr 2004 12:02:44 -0400, Alvaro Herrera > <[EMAIL PROTECTED]> wrote: > >In fact, I think we should mark ERROR as aborting the whole transaction > >tree, and create a new level which would abort the innermost > >subtransaction. We would then change whatever is appropiate to the new > >elevel. Doing otherwise would leave us open to unexpected conditions > >causing only subtrans abort, which could lead to unreliable behavior. > > Why? Subtransaction commit propagates an error state to the parent > transaction. And if a subtransaction is rolled back the parent can > continue cleanly no matter what was the reason for the subtrans abort. I think his point was that there are some errors that should abort the outer transaction too. I think Alvaro mentioned out of memory, but that is a FATAL error. Alvaro, what error were you thinking of that should abort the outer transaction? -- 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
Re: [PATCHES] Basic subtransaction facility
On Wed, 28 Apr 2004 12:02:44 -0400, Alvaro Herrera <[EMAIL PROTECTED]> wrote: >In fact, I think we should mark ERROR as aborting the whole transaction >tree, and create a new level which would abort the innermost >subtransaction. We would then change whatever is appropiate to the new >elevel. Doing otherwise would leave us open to unexpected conditions >causing only subtrans abort, which could lead to unreliable behavior. Why? Subtransaction commit propagates an error state to the parent transaction. And if a subtransaction is rolled back the parent can continue cleanly no matter what was the reason for the subtrans abort. Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Basic subtransaction facility
Alvaro Herrera wrote: > On Mon, Apr 26, 2004 at 11:30:16PM -0400, Bruce Momjian wrote: > > > Alvaro, where are we on this patch. I think the suggestion was to > > throw FATAL rather than add a new error level. > > The assumption was that we would only want an additional level for > catching can't-happen conditions. ISTM this is not true. Consider an > out of memory error: do we want to only rollback the affected > subtransaction, or the whole transaction tree? If we want the latter we > will have to invent a new elevel. > > In fact, I think we should mark ERROR as aborting the whole transaction > tree, and create a new level which would abort the innermost > subtransaction. We would then change whatever is appropiate to the new > elevel. Doing otherwise would leave us open to unexpected conditions > causing only subtrans abort, which could lead to unreliable behavior. > > In short, I think all elog(ERROR) should have different behaviour from > ereport(ERROR), at least. And I don't think the answer should be > elog(FATAL) for the former. Agreed we need a new error code to abort a subtransaction rather than the entire transaction. I don't understand your elog(ERROR) vs. ereport(ERROR) distinction. Was that a typo? -- 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
Re: [PATCHES] Basic subtransaction facility
On Mon, Apr 26, 2004 at 11:30:16PM -0400, Bruce Momjian wrote: > Alvaro, where are we on this patch. I think the suggestion was to > throw FATAL rather than add a new error level. The assumption was that we would only want an additional level for catching can't-happen conditions. ISTM this is not true. Consider an out of memory error: do we want to only rollback the affected subtransaction, or the whole transaction tree? If we want the latter we will have to invent a new elevel. In fact, I think we should mark ERROR as aborting the whole transaction tree, and create a new level which would abort the innermost subtransaction. We would then change whatever is appropiate to the new elevel. Doing otherwise would leave us open to unexpected conditions causing only subtrans abort, which could lead to unreliable behavior. In short, I think all elog(ERROR) should have different behaviour from ereport(ERROR), at least. And I don't think the answer should be elog(FATAL) for the former. -- Alvaro Herrera () "Ni aun el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior" (Goethe) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Basic subtransaction facility
[ Tom will review.] Description from previous patch added to patched queue too. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Alvaro Herrera wrote: > I wrote ten seconds ago: > > > This version does. This patch includes both patches I > > posted and a few more changes, and does the following: > > I mean this one. > > -- > Alvaro Herrera () > "?Qu? importan los a?os? Lo que realmente importa es comprobar que > a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda) [ Attachment, skipping... ] -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Basic subtransaction facility
On Mon, Apr 26, 2004 at 11:30:16PM -0400, Bruce Momjian wrote: > > Alvaro, where are we on this patch. I think the suggestion was to > throw FATAL rather than add a new error level. > > Is this ready to be applied? I forgot to verify if it worked correctly with #undef SUBTRANSACTIONS --- it didn't. This version does. This patch includes both patches I posted and a few more changes, and does the following: - adds subtransaction state knowledge to xact.c - adds subtransaction support to smgr, portals (cursors) and async notifies. - adds a new memory context related to the subxact tree (is reset only on subtrans abort). - corrects a couple of bugs in the previous patches. - mantains a Xid list of committed subxacts, for use in future changes involving pg_clog - adds support for executing BEGIN inside an aborted transaction, not only as a simple query (1st patch did this) but also as messages of v3 protocol and prepared statements. - works cleanly with SUBTRANSACTIONS undefined (you get the current behavior, no BEGIN is allowed inside a running transaction) and defined (all of the above). - keeps the original behavior of using FATAL whenever an bug is found inside xact.c I feel this one is ready to be applied. Tom wanted to review it, of course. Still missing: - deal with prepared statements, deferred triggers - save state in pg_clog - visibility rules -- Alvaro Herrera () "La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos) ---(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: [PATCHES] Basic subtransaction facility
I wrote ten seconds ago:
> This version does. This patch includes both patches I
> posted and a few more changes, and does the following:
I mean this one.
--
Alvaro Herrera ()
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 26 Apr 2004 13:25:30 -
***
*** 189,194
--- 189,227
static void RecordTransactionAbort(void);
static void StartTransaction(void);
+ #ifdef SUBTRANSACTIONS
+ static void StartSubTransaction(void);
+ static void CommitSubTransaction(void);
+ static void AbortSubTransaction(void);
+ static void CleanupSubTransaction(void);
+ static void PushCurrentTransaction(void);
+ static void PopTransaction(void);
+ static bool IsSubTransaction(void);
+ static void ShowTransactionState(char *);
+ static void ShowTransactionStateRec(TransactionState, int);
+
+ static void AtSubStart_Memory(void);
+ static void AtSubCommit_Memory(void);
+ static void AtSubAbort_Memory(void);
+ static void AtSubCleanup_Memory(void);
+ static void AtSubCommit_Notifies(void);
+
+ static char *TransStateAsString(TransState);
+
+ #else /* SUBTRANSACTIONS */
+ #define StartSubTransaction()
+ #define CommitSubTransaction()
+ #define AbortSubTransaction()
+ #define CleanupSubTransaction()
+ #define PushCurrentTransaction()
+ #define PopTransaction()
+ #define IsSubTransaction() (false)
+ #define ShowTransactionState(foo)
+ #define ShowTransactionStateRec()
+ #endif /* SUBTRANSACTIONS */
+
+ static char *BlockStateAsString(TBlockState);
+
/*
*global variables holding the current transaction state.
*/
***
*** 198,205
0, /* scan command id */
0x0,/* start time */
TRANS_DEFAULT, /* transaction state */
! TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
--- 231,251
0, /* scan command id */
0x0,/* start time */
TRANS_DEFAULT, /* transaction state */
! TBLOCK_DEFAULT, /* transaction block state from the
client
* perspective */
+ #ifdef SUBTRANSACTIONS
+ 0, /* nesting level */
+ NULL, /* commit memory context */
+ NULL, /* deferred trigger queue */
+ #endif /* SUBTRANSACTIONS */
+ NIL,/* smgr pending deletes */
+ NIL /* async notifies */
+ #ifdef SUBTRANSACTIONS
+ ,
+ NULL, /* lightweight locks */
+ NIL,/* regular locks */
+ NULL/* parent transaction */
+ #endif
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
***
*** 281,287
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT)
return true;
return false;
--- 327,334
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT ||
! s->blockState == TBLOCK_SUBABORT)
return true;
return false;
***
*** 337,342
--- 384,484
return s->startTime;
}
+ /*
+ * TransactionGetPendingDeletes
+ */
+ List *
+ TransactionGetPendingDeletes(void)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ return s->pendingDeletes;
+ }
+
+ /*
+ * TransactionSetPendingDeletes
+ */
+ void
+ TransactionSetPendingDeletes(List *pending)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ s->pendingDeletes = pending;
+ }
+
+ #ifdef SUBTRANSACTIONS
+ /*
+ * TransactionGetParentPendingDeletes
+ */
+ List *
+ TransactionGetParentPendingDeletes(void)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ Assert(s->parent != NULL);
+ return s->parent->pendingDeletes;
+ }
+
+ /*
+ * Transaction
Re: [PATCHES] Basic subtransaction facility
Alvaro, where are we on this patch. I think the suggestion was to throw FATAL rather than add a new error level. Is this ready to be applied? --- Alvaro Herrera wrote: > On Mon, Apr 19, 2004 at 11:13:35AM -0400, Alvaro Herrera wrote: > > > I noticed that I sent an old version because of a system crash (the > > *one* time I don't review vi -r differences it bites me ... argh). It > > has several obvious mistakes. Please do not waste your time reviewing > > that; I'll submit a corrected version later, which will also contain > > some more changes. > > Ok, hopefully this one is better. > > I'm thinking that I'll to add a new elog level to signal a can't-happen > condition within the transaction machinery, which would abort the whole > transaction tree (more than ERROR) but would not take the whole backend > down (less than FATAL). What should it be called? Do people agree that > it's needed? > > -- > Alvaro Herrera () > "Et put se mouve" (Galileo Galilei) [ Attachment, skipping... ] -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Basic subtransaction facility
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I'm thinking that I'll to add a new elog level to signal a can't-happen > condition within the transaction machinery, which would abort the whole > transaction tree (more than ERROR) but would not take the whole backend > down (less than FATAL). What should it be called? Do people agree that > it's needed? If you think it's just for can't-happen conditions, FATAL (or even Assert) should cover it. 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: [PATCHES] Basic subtransaction facility
On Mon, Apr 19, 2004 at 11:13:35AM -0400, Alvaro Herrera wrote:
> I noticed that I sent an old version because of a system crash (the
> *one* time I don't review vi -r differences it bites me ... argh). It
> has several obvious mistakes. Please do not waste your time reviewing
> that; I'll submit a corrected version later, which will also contain
> some more changes.
Ok, hopefully this one is better.
I'm thinking that I'll to add a new elog level to signal a can't-happen
condition within the transaction machinery, which would abort the whole
transaction tree (more than ERROR) but would not take the whole backend
down (less than FATAL). What should it be called? Do people agree that
it's needed?
--
Alvaro Herrera ()
"Et put se mouve" (Galileo Galilei)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 20 Apr 2004 05:25:52 -
***
*** 189,194
--- 189,224
static void RecordTransactionAbort(void);
static void StartTransaction(void);
+ #ifdef SUBTRANSACTIONS
+ static void StartSubTransaction(void);
+ static void CommitSubTransaction(void);
+ static void AbortSubTransaction(void);
+ static void CleanupSubTransaction(void);
+ static void PushCurrentTransaction(void);
+ static void PopTransaction(void);
+ static bool IsSubTransaction(void);
+ static void ShowTransactionState(char *);
+ static void ShowTransactionStateRec(TransactionState, int);
+
+ static void AtSubStart_Memory(void);
+ static void AtSubCommit_Memory(void);
+ static void AtSubCleanup_Memory(void);
+
+ #else /* SUBTRANSACTIONS */
+ #define StartSubTransaction()
+ #define CommitSubTransaction()
+ #define AbortSubTransaction()
+ #define CleanupSubTransaction()
+ #define PushCurrentTransaction()
+ #define PopTransaction()
+ #define IsSubTransaction() (false)
+ #define ShowTransactionState(foo)
+ #define ShowTransactionStateRec()
+ #endif /* SUBTRANSACTIONS */
+
+ static char *BlockStateAsString(TBlockState);
+ static char *TransStateAsString(TransState);
+
/*
*global variables holding the current transaction state.
*/
***
*** 200,205
--- 230,247
TRANS_DEFAULT, /* transaction state */
TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
+ #ifdef SUBTRANSACTIONS
+ ,
+ 0, /* nesting level */
+ NULL, /* commit memory context */
+ NULL, /* deferred trigger queue */
+ NIL,/* smgr pending deletes */
+ NIL,/* async notifies */
+ NULL, /* lightweight locks */
+ NIL,/* regular locks */
+ NULL, /* parent transaction */
+
+ #endif
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
***
*** 281,287
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT)
return true;
return false;
--- 323,330
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT ||
! s->blockState == TBLOCK_SUBABORT)
return true;
return false;
***
*** 452,459
--- 495,544
ALLOCSET_DEFAULT_MAXSIZE);
MemoryContextSwitchTo(TopTransactionContext);
+
+ /*
+* This context will be used to hold data that survives
+* subtransaction commit but disappears on subtransaction end.
+* Most if not all of the transaction-local structures should
+* live here.
+*/
+ CommitContext = AllocSetContextCreate(TopTransactionContext,
+
"CommitContext",
+
ALLOCSET_DEFAULT_MINSIZE,
+
ALLOCSET_DEFAULT_INITSIZE,
+
ALLOCSET_DEFAULT_MAXSIZE);
}
+ #ifdef SUBTRANSACTIONS
+ /*
+ *StartSubTransaction stuff
+
Re: [PATCHES] Basic subtransaction facility
Patch withdrawn by author. --- Alvaro Herrera wrote: > Hackers, > > Here is a very preliminar patch that allows the user to say "BEGIN" > inside a transaction and have the system react accordingly. This is > only a modification to xact.c (and slightly to other places to allow it > to work); the important functions are empty. > > It compiles fine for me with both SUBTRANSACTIONS defined and not > defined; when not defined, the behavior is the same as the current code. > Please note that I have made some errors more fatal than they are now, > as bugs in this code will have much worse effects than a flaw in the > current transaction system. > > One quick note: there are two ENDABORT states for a subtransaction, > SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent > transaction should be aborted after the child transaction finishes or > not: an aborted subtransaction where the user issues COMMIT should > abort the parent transaction; if the user issues ROLLBACK, the parent > can be allowed to continue. > > > Please have a look and comment. This file does not move a lot so I > don't think it will suffer from a lot of code drift. > > -- > Alvaro Herrera () > "I think my standards have lowered enough that now I think 'good design' > is when the page doesn't irritate the living f*ck out of me." (JWZ) [ Attachment, skipping... ] > > ---(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 -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Basic subtransaction facility
On Sun, Apr 18, 2004 at 11:29:05AM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > If you want. When not #defined, the behavior is the same as the current > > code, so it shouldn't affect anything. However I posted mainly so > > people could comment on the modifications, and maybe Heikki Linnakangas > > could see how it affects his two phase commit patch. > > I have not reviewed it yet, but would like to do so before it goes in. I noticed that I sent an old version because of a system crash (the *one* time I don't review vi -r differences it bites me ... argh). It has several obvious mistakes. Please do not waste your time reviewing that; I'll submit a corrected version later, which will also contain some more changes. Thanks. -- Alvaro Herrera () "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge) ---(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: [PATCHES] Basic subtransaction facility
Added to queue until Tom's review and/or application. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Alvaro Herrera wrote: > Hackers, > > Here is a very preliminar patch that allows the user to say "BEGIN" > inside a transaction and have the system react accordingly. This is > only a modification to xact.c (and slightly to other places to allow it > to work); the important functions are empty. > > It compiles fine for me with both SUBTRANSACTIONS defined and not > defined; when not defined, the behavior is the same as the current code. > Please note that I have made some errors more fatal than they are now, > as bugs in this code will have much worse effects than a flaw in the > current transaction system. > > One quick note: there are two ENDABORT states for a subtransaction, > SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent > transaction should be aborted after the child transaction finishes or > not: an aborted subtransaction where the user issues COMMIT should > abort the parent transaction; if the user issues ROLLBACK, the parent > can be allowed to continue. > > > Please have a look and comment. This file does not move a lot so I > don't think it will suffer from a lot of code drift. > > -- > Alvaro Herrera () > "I think my standards have lowered enough that now I think 'good design' > is when the page doesn't irritate the living f*ck out of me." (JWZ) [ Attachment, skipping... ] > > ---(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 -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Basic subtransaction facility
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > If you want. When not #defined, the behavior is the same as the current > > code, so it shouldn't affect anything. However I posted mainly so > > people could comment on the modifications, and maybe Heikki Linnakangas > > could see how it affects his two phase commit patch. > > I have not reviewed it yet, but would like to do so before it goes in. OK, thanks. Yea, I think we should get it in rather than waiting for Alvaro to finish the whole project. This way, we have something in that can't drift. -- 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
Re: [PATCHES] Basic subtransaction facility
Alvaro Herrera <[EMAIL PROTECTED]> writes: > If you want. When not #defined, the behavior is the same as the current > code, so it shouldn't affect anything. However I posted mainly so > people could comment on the modifications, and maybe Heikki Linnakangas > could see how it affects his two phase commit patch. I have not reviewed it yet, but would like to do so before it goes in. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Basic subtransaction facility
On Sat, Apr 17, 2004 at 10:03:40AM -0400, Bruce Momjian wrote: > Do you want this applied? If you want. When not #defined, the behavior is the same as the current code, so it shouldn't affect anything. However I posted mainly so people could comment on the modifications, and maybe Heikki Linnakangas could see how it affects his two phase commit patch. Also, that code does not change a lot, so there's little risk of code drift to worry about; this makes it unlikely that I'd have a lot of work to do to update it to a future CVS tip. But maybe applying it means it gets more testing. > --- > > Alvaro Herrera wrote: > > Hackers, > > > > Here is a very preliminar patch that allows the user to say "BEGIN" > > inside a transaction and have the system react accordingly. This is > > only a modification to xact.c (and slightly to other places to allow it > > to work); the important functions are empty. > > > > It compiles fine for me with both SUBTRANSACTIONS defined and not > > defined; when not defined, the behavior is the same as the current code. > > Please note that I have made some errors more fatal than they are now, > > as bugs in this code will have much worse effects than a flaw in the > > current transaction system. > > > > One quick note: there are two ENDABORT states for a subtransaction, > > SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent > > transaction should be aborted after the child transaction finishes or > > not: an aborted subtransaction where the user issues COMMIT should > > abort the parent transaction; if the user issues ROLLBACK, the parent > > can be allowed to continue. > > > > > > Please have a look and comment. This file does not move a lot so I > > don't think it will suffer from a lot of code drift. -- Alvaro Herrera () "At least to kernel hackers, who really are human, despite occasional rumors to the contrary" (LWN.net) ---(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: [PATCHES] Basic subtransaction facility
Do you want this applied? --- Alvaro Herrera wrote: > Hackers, > > Here is a very preliminar patch that allows the user to say "BEGIN" > inside a transaction and have the system react accordingly. This is > only a modification to xact.c (and slightly to other places to allow it > to work); the important functions are empty. > > It compiles fine for me with both SUBTRANSACTIONS defined and not > defined; when not defined, the behavior is the same as the current code. > Please note that I have made some errors more fatal than they are now, > as bugs in this code will have much worse effects than a flaw in the > current transaction system. > > One quick note: there are two ENDABORT states for a subtransaction, > SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent > transaction should be aborted after the child transaction finishes or > not: an aborted subtransaction where the user issues COMMIT should > abort the parent transaction; if the user issues ROLLBACK, the parent > can be allowed to continue. > > > Please have a look and comment. This file does not move a lot so I > don't think it will suffer from a lot of code drift. > > -- > Alvaro Herrera () > "I think my standards have lowered enough that now I think 'good design' > is when the page doesn't irritate the living f*ck out of me." (JWZ) [ Attachment, skipping... ] > > ---(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 -- 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
[PATCHES] Basic subtransaction facility
Hackers,
Here is a very preliminar patch that allows the user to say "BEGIN"
inside a transaction and have the system react accordingly. This is
only a modification to xact.c (and slightly to other places to allow it
to work); the important functions are empty.
It compiles fine for me with both SUBTRANSACTIONS defined and not
defined; when not defined, the behavior is the same as the current code.
Please note that I have made some errors more fatal than they are now,
as bugs in this code will have much worse effects than a flaw in the
current transaction system.
One quick note: there are two ENDABORT states for a subtransaction,
SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent
transaction should be aborted after the child transaction finishes or
not: an aborted subtransaction where the user issues COMMIT should
abort the parent transaction; if the user issues ROLLBACK, the parent
can be allowed to continue.
Please have a look and comment. This file does not move a lot so I
don't think it will suffer from a lot of code drift.
--
Alvaro Herrera ()
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 14 Apr 2004 02:50:02 -
***
*** 189,194
--- 189,219
static void RecordTransactionAbort(void);
static void StartTransaction(void);
+ #ifdef SUBTRANSACTIONS
+ static void StartSubTransaction(void);
+ static void CommitSubTransaction(void);
+ static void AbortSubTransaction(void);
+ static void CleanupSubTransaction(void);
+ static void PushCurrentTransaction(void);
+ static void PopTransaction(void);
+ static bool IsSubTransaction(void);
+ static void ShowTransactionState(void);
+ static void ShowTransactionStateRec(TransactionState, int);
+ #else /* SUBTRANSACTIONS */
+ #define StartSubTransaction()
+ #define CommitSubTransaction()
+ #define AbortSubTransaction()
+ #define CleanupSubTransaction()
+ #define PushCurrentTransaction()
+ #define PopTransaction()
+ #define IsSubTransaction() (false)
+ #define ShowTransactionState()
+ #define ShowTransactionStateRec()
+ #endif /* SUBTRANSACTIONS */
+
+ static char *BlockStateAsString(TBlockState);
+ static char *TransStateAsString(TransState);
+
/*
*global variables holding the current transaction state.
*/
***
*** 200,205
--- 225,237
TRANS_DEFAULT, /* transaction state */
TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
+ #ifdef SUBTRANSACTIONS
+ ,
+ 0, /* nesting level */
+ NULL, /* top transaction memory
context */
+ NULL, /* commit memory context */
+ NULL/* parent transaction */
+ #endif
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
***
*** 281,287
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT)
return true;
return false;
--- 313,320
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT ||
! s->blockState == TBLOCK_SUBABORT)
return true;
return false;
***
*** 1145,1189
break;
/*
-* We should never experience this -- it means the STARTED
state
-* was not changed in the previous CommitTransactionCommand.
-*/
- case TBLOCK_STARTED:
- elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_STARTED");
- break;
-
- /*
-* We should never experience this -- if we do it means the
-* BEGIN state was not changed in the previous
-* CommitTransactionCommand(). If we get it, we print a
-* warning and change to the in-progress state.
-*/
- case TBLOCK_BEGIN:
- elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_BEGIN");
- s->blockState = TBLOCK_INPROGRESS;
- break;
-
- /*
