On 16 Apr 2003 at 9:12, Joe Conway wrote:
> Shridhar Daithankar wrote:
> > I was just going thr. dblink code and noticed that dblink cursors are wrapped
> > in their own transaction.
>
> yup -- been that way since 7.3 was released.
>
> > If an application instantiates a transaction to do 10 things, one of which is
> > to fetch a cursor over dblink, how will it work?
>
> I guess it won't -- you're the first person who ever complained, so
> quite possibly you're the first who's needed it.
Well, actually I am not doing anything with it right now. Just happened to
notice it.
>
> > IMO the instantiation of transaction block should be left calling application,
> > as done with normal cursors. DBLink would have to detect whether or not they
> > are in a transaction block and abort accordingly.
> >
> > Or I misunderstood something?
>
> No, you seem to understand correctly. Patches gratefully accepted ;-)
I'll send later. The postgresql CVS tree is on linux partition..
> I think someone is working on nested transactions, which IIRC may make
> it into 7.4. In this case, the issue will be moot, no? If not, I will
> take a look at fixing it for 7.4. If you want to ensure that, submit a
> patch. I'd think the best thing to do would be the following:
>
> - detect transaction status
> - if not in an explicit transaction block, start one
Any idea how do you detect transaction status? I don't have tried it out but
any info. to start with would be good.
That is fine. But I would like to put out a huge warning board in dblink
documentation stating which function triggers a transaction and which function
commits it.
if a module starts a transaction without knowledge to calling application, that
is not good. It does not matter whether or not postresql supports nested
transactions. If it does it will work but that would still be an unforeseen
situation for the application.
ByeShridhar
--
Brogan's Constant: People tend to congregate in the back of the church and the
front of the bus.
