Re: Transactional issue that begs for explanation

Tom Lane wrote:
> I suspect you're shooting yourself in the foot by repeatedly re-opening
> the backend's stdout and not fflush'ing anywhere along the line: somehow
> the data going to the log file is getting mangled.  I don't see any
> strange behavior here when using a less dangerous logging technique,
> such as
>
> CREATE or REPLACE FUNCTION logtrg() RETURNS trigger AS $$
> $key=$_TD->{old}{key};
> $val=$_TD->{old}{val};
> elog(NOTICE, "Firing on: $key $val\n");
> return;
> $$ LANGUAGE plperlu;
>
> (Actually, I don't see anything funny when using your original version
> of the function, either; but it's probably dependent on a lot of
> platform-specific libc details exactly how you got that result.)
>
>             regards, tom lane
>
Tom, you are a great guy. I didn't know about the elog function, I've
just tried to re-invent the wheel. Thanks for the pointer, I will try
with elog. Actually, I was trying to check what from the following
article is applicable to Postgres:

http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
http://tkyte.blogspot.com/2005/08/part-ii-seeing-restart.html
http://tkyte.blogspot.com/2005/09/part-iii-why-is-restart-important-to.html

What I did figure out is
a) Postgres doesn't restart the transaction the same way that Oracle
does or the trigger would fire twice.
b) There is no DBMS_OUTPUT, so I tried to re-invent the wheel.

I  still don't know what does Postgres do when the data in a block
needed by current transaction changes the value? Oracle simply restarts
the transaction, in order to have a clean slate.

--
Mladen Gogala
Sr. Oracle DBA
1500 Broadway
New York, NY 10036
(212) 329-5251
www.vmsinfo.com