From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> |
Cc: | "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Transactional issue that begs for explanation |
Date: | 2010-09-11 02:23:04 |
Message-ID: | 5703.1284171784@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com> writes:
> To make the story more interesting, I added the following:
> CREATE or REPLACE FUNCTION logtrg() RETURNS trigger AS $$
> open(STDOUT,">>/tmp/logfile") or die("Cannot open log:$!\n");
> $key=$_TD->{old}{key};
> $val=$_TD->{old}{val};
> print "Firing on: $key $val\n";
> return;
> $$ LANGUAGE plperlu;
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mladen Gogala | 2010-09-11 03:32:30 | Re: Transactional issue that begs for explanation |
Previous Message | Thomas Kellerer | 2010-09-10 18:15:09 | Re: PostgreSQL article online - PDF |