Re: [PATCHES] [subxacts] Fixing TODO items
On Tue, Jul 27, 2004 at 01:32:01PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > There are some likely controversial changes; the Xid caches, in the > > first place. > > No kidding ;-) Ok, here is another try. This patch includes both the Xid cache rewrite, source documentation (removed the big comment in xact.c and added a README file), htup.h comments updated, and some user documentation. BTW, the overflow bit is certainly a better approach than the negative cache. I am not sure about locking w.r.t. the XidCache though. Please take a look at it. -- Alvaro Herrera () Maybe there's lots of data loss but the records of data loss are also lost. (Lincoln Yeoh) diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/advanced.sgml 04pgproc/doc/src/sgml/advanced.sgml *** 00orig/doc/src/sgml/advanced.sgml 2004-04-14 16:45:53.0 -0400 --- 04pgproc/doc/src/sgml/advanced.sgml 2004-07-27 10:29:09.0 -0400 *** *** 257,262 --- 257,310 you are using. + + + It's possible to control the statements in a transaction in a more + granular fashion through the use of savepoints. Savepoints + allow you to selectively discard parts of the transaction, while + committing the rest. This is done be defining a savepoint with + SAVEPOINT, to which you can later roll back using + ROLLBACK TO. All statements between defining the savepoint + and rolling back to it will have no effect on the final transaction. + + + + After rolling back to a savepoint, it continues to be defined, so you can + roll back to it several times. Conversely, if you are sure you won't need + to roll back to a particular savepoint again, it can be released, so the + system can free some resources. Keep in mind that releasing a savepoint + will automatically release all savepoints that were defined after it. + + + + Remembering the bank database, suppose we debit $100.00 from Alice's + account, and credit Bob's account, only to find later that we wanted to + credit Wally's account. We could do it using savepoints like + + + BEGIN; + UPDATE accounts SET balance = balance - 100.00 + WHERE name = 'Alice'; + SAVEPOINT my_savepoint; + UPDATE accounts SET balance = balance + 100.00 + WHERE name = 'Bob'; + -- oops ... forget that and use Wally's account + ROLLBACK TO my_savepoint; + UPDATE accounts SET balance = balance + 100.00 + WHERE name = 'Wally'; + COMMIT; + + + + + This example is, of course, oversimplified, but there's a lot of control + to be had over a transaction block through the use of savepoints. + Moreover, ROLLBACK TO is the only way to regain control of a + transaction block that was automatically put on aborted state by the + system for some reason, short of rolling it back completely and starting + again. + + diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/allfiles.sgml 04pgproc/doc/src/sgml/ref/allfiles.sgml *** 00orig/doc/src/sgml/ref/allfiles.sgml 2004-06-26 00:28:45.0 -0400 --- 04pgproc/doc/src/sgml/ref/allfiles.sgml 2004-07-27 10:29:09.0 -0400 *** *** 88,96 --- 88,99 + + + diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/begin.sgml 04pgproc/doc/src/sgml/ref/begin.sgml *** 00orig/doc/src/sgml/ref/begin.sgml 2004-01-11 06:24:17.0 -0300 --- 04pgproc/doc/src/sgml/ref/begin.sgml2004-07-27 10:29:09.0 -0400 *** *** 145,150 --- 145,151 + diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/release.sgml 04pgproc/doc/src/sgml/ref/release.sgml *** 00orig/doc/src/sgml/ref/release.sgml1969-12-31 21:00:00.0 -0300 --- 04pgproc/doc/src/sgml/ref/release.sgml 2004-07-27 10:29:09.0 -0400 *** *** 0 --- 1,138 + + + + + RELEASE + SQL - Language Statements + + + + RELEASE + destroy a previously defined savepoint + + + + RELEASE + + + + savepoints + releasing + + + + + RELEASE savepoint_name + + + + + Description + + +RELEASE destroys a previously defined savepoint +in the current transaction. + + + +Destroying a savepoint makes it—and all savepoints established after +it was established—unavailable as rollback points, +but it has no other user visible behavior. It does not undo the +effects of command executed after the savepoint was established. +To do that, see . + + + +RELEASE also destroys all savepoints that were established +after the named savepoint was established. + + + + Parameters + + + + savepoint_name + + + The name of the savepoint to destroy. + + + + + + + + Notes + + +Specifying a savepoint name th
Re: [PATCHES] [subxacts] Fixing TODO items
On Tue, Jul 27, 2004 at 01:32:01PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > There are some likely controversial changes; the Xid caches, in the > > first place. > > No kidding ;-) > > Do you have any theoretical or practical evidence for the usefulness of > the negxids cache? Seems to me the shared memory space would be better > spent on allowing deeper nesting of the running-subxids list. Also, > what happened to marking whether the running-subxids list has > overflowed? If none of them have then there's no need to wonder whether > we have a still-running subxact. Oh, sure, I had forgot about the overflow flag. I am working on that now. > The apparent lack of any locking on these data structures seems wrong > too. Well, storing the main Xid of a transaction in PGPROC is regarded as "atomic" and it has no locking (other than SInvalLock in shared mode). I think the correct solution would be to lock both the main Xid and the XidCache with a per-backend LWLock, but you already rejected that idea. My current patch uses SInvalLock in shared mode to protect reading and writing the XidCaches. I am not sure this is a very good idea, but it doesn't seem unreasonable either. -- Alvaro Herrera () "Et put se mouve" (Galileo Galilei) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [subxacts] Fixing TODO items
Alvaro Herrera <[EMAIL PROTECTED]> writes: > There are some likely controversial changes; the Xid caches, in the > first place. No kidding ;-) Do you have any theoretical or practical evidence for the usefulness of the negxids cache? Seems to me the shared memory space would be better spent on allowing deeper nesting of the running-subxids list. Also, what happened to marking whether the running-subxids list has overflowed? If none of them have then there's no need to wonder whether we have a still-running subxact. The apparent lack of any locking on these data structures seems wrong too. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [subxacts] Fixing TODO items
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Here is a patch that fixes some of the TODO items in the nested xacts > list: > handle large objects On the large-objects stuff: it seems like a really bad idea to be fooling with CurrentResourceOwner like that. What that means is that if a subtransaction opens a LO and then fails, the associated low-level resources will remain allocated until the top transaction ends ... even though the LargeObjectDesc went away in subtransaction abort. In the worst case with repeated retries, it seems like this could run you out of free buffers, for example. It occurs to me that the only resource held for any long period in this code is the open relations (heap_r and index_r), and that it's pretty silly to have every open LO have its own reference to pg_largeobject. (I believe the code in inv_api.c is a holdover from a time when LOs could live in different tables; but that's been dead for a long time and seems quite unlikely to get resurrected.) Also, there's no urgent need to maintain a distinction between read and write access in terms of the kind of lock we take on pg_largeobject. There aren't any operations that anyone should be performing on pg_largeobject that would care about the difference between AccessShareLock and RowExclusiveLock. This means that upon first use of any LO within a main transaction, we can open pg_largeobject *once* and use it for all LOs for the rest of the transaction. This reference would be okay to assign to the top ResourceOwner. The resources acquired and released during inv_read, inv_write, etc, can be left with the normal CurrentResourceOwner so that they'll be dropped immediately in case of error. Any comments on this plan? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [subxacts] Fixing TODO items
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Nesting level report via a ParameterStatus message sent just before > ReadyForQuery (Z message). Hasn't this really been obsoleted by events? In the SAVEPOINT world I doubt that it's needed. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
