Re: [GENERAL] Transaction Question

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: johnsw(at)wardbrook(dot)com, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [GENERAL] Transaction Question
Date: 2003-12-06 15:43:18
Message-ID: 200312061543.hB6FhIh04261@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers


[ General removed, hackers added.]

Where are we on nested transactions. Is it something we can get for 7.5?

---------------------------------------------------------------------------

Manfred Koizar wrote:
> On Wed, 3 Dec 2003 08:08:49 -0000 (GMT), "John Sidney-Woollett"
> <johnsw(at)wardbrook(dot)com> wrote:
> >Issue - nested transactions
>
> >This is an issue for us because some procedures make use of a function
> >which issues a row level lock on a table (select ... for update) in order
> >to read and then update a counter, and which then commits to release the
> >lock. The nested function returns the new counter value on return.
>
> AFAICS nested transactions - at least in the way we plan to implement
> them - won't help, because subtransaction commit will not release locks.
> We see a subtransaction as part of the main transaction. If a
> subtransaction commits but the main transaction aborts, the
> subtransaction's effects are rolled back.
>
> START TRANSACTION; -- main xact
> ...
> START TRANSACTION; -- sub xact
> UPDATE t SET n=n+1 WHERE i=42;
>
> This locks the row with i=42, because if another transaction wants to
> update this row, it cannot know whether to start with the old or the new
> value of n before our transaction commits or rolls back.
>
> COMMIT; --sub xact
>
> Here we are still in the main transaction. Nothing has changed for
> other backends, because they still don't know whether our main
> transaction will succeed or fail. So we have to keep the lock...
>
> >Is there a simple/elegant solution to this problem?
>
> Perhaps dblink? Just a thought, I don't have any personal experience
> with it.
>
> Servus
> Manfred
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mikolaj Kocikowski 2003-12-06 15:50:14 record and table size
Previous Message Tom Lane 2003-12-06 15:40:35 Re: transaction in progress

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2003-12-06 16:03:48 Double linked list with one pointer
Previous Message Bruce Momjian 2003-12-06 15:31:36 Re: request for feedback - read-only GUC variables, pg_settings