Re: AW: [HACKERS] Begin statement again - Mailing list pgsql-hackers

From Michael Meskes
Subject Re: AW: [HACKERS] Begin statement again
Date
Msg-id 199803251557.QAA18249@gauss.topsystem.de
Whole thread Raw
In response to AW: [HACKERS] Begin statement again  (Zeugswetter Andreas <andreas.zeugswetter@telecom.at>)
Responses Re: AW: [HACKERS] Begin statement again  ("Jose' Soares Da Silva" <sferac@proxy.bazzanese.com>)
List pgsql-hackers
Zeugswetter Andreas writes:
> I am well accustomed to the deficiencies of Oracle. But in Oracle you don't have read locks,
> and so a read only program does no harm if it only does one commit when it exits
> (except maybe block the RBS if it did one small update).
> Since postgresql does have read locks, such a program will lock all resources as time goes by,
> if it does not do frequent commits. Not to speak of memory, that does not get freed.

You got a point with this.

> Hmmm ? you don't tell the backend when the program exits ?

So far I don't. Does anyone know whether there's a disconnect command
somewhere? In embedded SQL that is. Oracle uses 'commit work release'.

The function I have to call does exist already.

> Try Informix, and you will love the difference and speed in these points.
> The begin work statement is also a fundamental part of postgres. I simply would not hide it.

I do not hide it all. But I'd like to be as compatible to Oracle as
possible. Maybe we could add an autotransaction flag somehow.

Michael

--
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10

pgsql-hackers by date:

Previous
From: Zeugswetter Andreas
Date:
Subject: AW: AW: [HACKERS] Re: PostgreSQL reference manual
Next
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: AW: [HACKERS] Begin statement again