Re: start of transaction

From: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: start of transaction
Date: 2003-11-17 10:43:28
Message-ID: 3FB8A650.9030603@persistent.co.in
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Hannu Krosing wrote:

> Tom Lane kirjutas E, 17.11.2003 kell 02:08:
>
>>Neil Conway <neilc(at)samurai(dot)com> writes:
>>
>>>Hmmm... I agree this behavior isn't ideal, although I can see the case
>>>for viewing this as a mistake by the application developer: they are
>>>assuming that they know exactly when transactions begin, which is not
>>>a feature provided by their language interface.
>>
>>Well, actually, it's a bug in the interface IMHO. But as I said in the
>>last thread, it's a fairly widespread bug.
>
>
> I'm not sure that it is a client-side bug. For example Oracle seems to
> _always_ have a transaction going, i.e. you can't be "outside" of
> transaction, and you use just COMMIT to commit old _and_start_new_
> transaction.
>
> IIRC the same is true for DB2.

Actually, in oracle a new transaction starts with first DDL after a commit. That
does not include DML BTW.

And Damn.. Actually I recently fixed a "bug" where I had to force a start of
transaction in Pro*C, immediately after commit. Otherwise a real start of
transaction could be anywhere down the line, causing some weird concurrency
issues. Rather than fiddling with oracle support, I would hack my source code,
especially this is not the first oracle bug I have worked around....:-(

The fact that I couldn't control exact transaction start was such a irritation
to put it mildly.. I sooooo missed 'exec sql begin work' in ecpg..:-)

>>We've been taking the
>>position that the interface libraries should get fixed, and that's not
>>happening. It's probably time to look at a server-side fix.

I hope that does not compramise transaction control I have with libpq/ecpg etc.

And when we are talking about interface libraries, how many of them are within
PG control and how many are not? With languages maintenend by postgresql group,
it should behave correctly, right? E.g pl/perl,pl/python etc.

And for other interface libraries, what are they exactly? php? Can't we just
send them a stinker/patch to get that damn thing right(Whatever wrong they are
doing. I have kinda lost thread on it..:-) Was it exact time of transaction
start v/s now()?)

Shridhar

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2003-11-17 11:15:00 Re: Background writer process
Previous Message Hannu Krosing 2003-11-17 10:28:34 Re: [PATCHES] SRA Win32 sync() code

Browse pgsql-performance by date

  From Date Subject
Next Message Andrew Sullivan 2003-11-17 14:42:43 Re: INSERT extremely slow with large data sets (fwd)
Previous Message Hannu Krosing 2003-11-17 10:19:06 Re: start of transaction (was: Re: [PERFORM] Help with