Обсуждение: PL/perl elog(ERROR) Does not Abort Transaction
Hackers, Shouldn't a call to elog(NOTICE) invalidate the current tranaction? david=# begin; BEGIN Time: 0.178 ms david=# do language plperl $$ elog(ERROR, 'foo')$$; ERROR: foo at line 1. CONTEXT: PL/Perl anonymous code block david=# select true; bool ------ t (1 row) Time: 0.203 ms The docs say: > ERROR raises an error condition; if this is not trapped by the surrounding Perl code, the error propagates out to the callingquery, causing the current transaction or subtransaction to be aborted. So I'm surprised that the transaction is not aborted. Bug? David
On Thu, May 10, 2012 at 04:21:24PM -0700, David E. Wheeler wrote: > Hackers, > > Shouldn't a call to elog(NOTICE) invalidate the current tranaction? I assume you mean elog(ERROR)? > david=# begin; > BEGIN > Time: 0.178 ms > david=# do language plperl $$ elog(ERROR, 'foo')$$; > ERROR: foo at line 1. > CONTEXT: PL/Perl anonymous code block > david=# select true; > bool > ------ > t > (1 row) > > Time: 0.203 ms > > The docs say: > > > ERROR raises an error condition; if this is not trapped by the surrounding Perl code, the error propagates out to thecalling query, causing the current transaction or subtransaction to be aborted. > > So I'm surprised that the transaction is not aborted. Bug? Well, git head show an error: test=> begin;BEGINtest=> do language plperl $$ elog(ERROR, 'foo')$$;ERROR: foo at line 1.CONTEXT: PL/Perl anonymous codeblocktest=> select true;ERROR: current transaction is aborted, commands ignored until end oftransaction block -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On May 10, 2012, at 5:20 PM, Bruce Momjian wrote: >> >> Shouldn't a call to elog(NOTICE) invalidate the current tranaction? > > I assume you mean elog(ERROR)? Yes, sorry. > Well, git head show an error: > > test=> begin; > BEGIN > test=> do language plperl $$ elog(ERROR, 'foo')$$; > ERROR: foo at line 1. > CONTEXT: PL/Perl anonymous code block > test=> select true; > ERROR: current transaction is aborted, commands ignored until end of > transaction block Interesting. My build (from source): PostgreSQL 9.1.3 on x86_64-apple-darwin11.3.0, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc.build 5658) (LLVM build 2336.1.00), 64-bit (1 row) Best, David
On Thu, May 10, 2012 at 05:27:26PM -0700, David E. Wheeler wrote: > On May 10, 2012, at 5:20 PM, Bruce Momjian wrote: > > >> > >> Shouldn't a call to elog(NOTICE) invalidate the current tranaction? > > > > I assume you mean elog(ERROR)? > > Yes, sorry. > > > Well, git head show an error: > > > > test=> begin; > > BEGIN > > test=> do language plperl $$ elog(ERROR, 'foo')$$; > > ERROR: foo at line 1. > > CONTEXT: PL/Perl anonymous code block > > test=> select true; > > ERROR: current transaction is aborted, commands ignored until end of > > transaction block > > Interesting. My build (from source): > > PostgreSQL 9.1.3 on x86_64-apple-darwin11.3.0, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on AppleInc. build 5658) (LLVM build 2336.1.00), 64-bit > (1 row) OK, still an abort on 9.1.X head: $ psql testpsql (9.1.3)Type "help" for help.test=> begin;BEGINtest=> do language plperl $$ elog(ERROR, 'foo')$$;ERROR: fooat line 1.CONTEXT: PL/Perl anonymous code blocktest=> select true;ERROR: current transaction is aborted, commands ignoreduntil end oftransaction block -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On May 10, 2012, at 5:41 PM, Bruce Momjian wrote: > OK, still an abort on 9.1.X head: > > $ psql test > psql (9.1.3) > Type "help" for help. > > test=> begin; > BEGIN > test=> do language plperl $$ elog(ERROR, 'foo')$$; > ERROR: foo at line 1. > CONTEXT: PL/Perl anonymous code block > test=> select true; > ERROR: current transaction is aborted, commands ignored until end of > transaction block Ooh, heisenbug. What version of Perl? Mine is 5.14.2 compiled from source. David
On Thu, May 10, 2012 at 05:46:06PM -0700, David E. Wheeler wrote: > On May 10, 2012, at 5:41 PM, Bruce Momjian wrote: > > > OK, still an abort on 9.1.X head: > > > > $ psql test > > psql (9.1.3) > > Type "help" for help. > > > > test=> begin; > > BEGIN > > test=> do language plperl $$ elog(ERROR, 'foo')$$; > > ERROR: foo at line 1. > > CONTEXT: PL/Perl anonymous code block > > test=> select true; > > ERROR: current transaction is aborted, commands ignored until end of > > transaction block > > Ooh, heisenbug. What version of Perl? Mine is 5.14.2 compiled from source. I have: This is perl, v5.10.1 (*) built for x86_64-linux-gnu-thread-multi -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
> On Thu, May 10, 2012 at 05:27:26PM -0700, David E. Wheeler wrote:
>> Interesting. My build (from source):
>>
>> PostgreSQL 9.1.3 on x86_64-apple-darwin11.3.0, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on
AppleInc. build 5658) (LLVM build 2336.1.00), 64-bit
>> (1 row)
> OK, still an abort on 9.1.X head:
I can't reproduce this problem either. I tested HEAD and 9.1 branch tip
on my Mac laptop, using what appears to be the same compiler version
that David is using, as well as the Apple-supplied perl:
$ which perl
/usr/bin/perl
$ perl -v
This is perl 5, version 12, subversion 3 (v5.12.3) built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
Copyright 1987-2010, Larry Wall
I wonder whether David is using some other perl ...
regards, tom lane
"David E. Wheeler" <david.wheeler@iovation.com> writes:
> Ooh, heisenbug. What version of Perl? Mine is 5.14.2 compiled from source.
I also tried this on a Fedora 16 box, which has
$ perl -v
This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi
Works fine there too...
regards, tom lane
On May 10, 2012, at 6:18 PM, Tom Lane wrote:
> I also tried this on a Fedora 16 box, which has
>
> $ perl -v
> This is perl 5, version 14, subversion 2 (v5.14.2) built for x86_64-linux-thread-multi
>
> Works fine there too...
Hrm…I've also just replicated it on CentOS 6.2 with Perl 5.10.1:
reputation=# begin;
BEGIN
Time: 22.330 ms
reputation=# do language plperlu $$ elog(ERROR, 'foo')$$;
ERROR: foo at line 1.
CONTEXT: PL/Perl anonymous code block
reputation=# select true;bool
------t
(1 row)
Time: 18.392 ms
reputation=# rollback;
ROLLBACK
Time: 19.854 ms
reputation=# do language plperlu $$elog(NOTICE, $^V)$$;
NOTICE: v5.10.1
CONTEXT: PL/Perl anonymous code block
DO
Time: 20.459 ms
reputation=# select version(); version
--------------------------------------------------------------------------------------------------------------PostgreSQL
9.1.3on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3), 64-bit
(1 row)
Perhaps there is something funky in my configuration, though I tried a few different things and couldn't get it to
change.I can show you on my laptop next week if you want to see it in person. Not sure if that will help…
David
"David E. Wheeler" <david.wheeler@iovation.com> writes:
> Hrm�I've also just replicated it on CentOS 6.2 with Perl 5.10.1:
Interesting.
> Perhaps there is something funky in my configuration, though I tried a
> few different things and couldn't get it to change.
Yeah. If Bruce and I don't see it on a couple of configurations apiece,
and you do see it on two different machines, personal configuration
choices start to sound like a likely contributing factor. Could be
either PG configuration or Perl configuration (if there is any such
thing beyond installation-time decisions).
As for me, I was testing assert-enabled builds that were otherwise
entirely out-of-the-box, and I don't even know how to configure Perl.
regards, tom lane
On May 11, 2012, at 9:39 AM, Tom Lane wrote: >> Hrm∑I've also just replicated it on CentOS 6.2 with Perl 5.10.1: > > Interesting. Ah, it’s a psql configuration issue. I had replicated it on that box by connecting with psql on my Mac. When I SSHed to thebox and used the psql there, I was *not* able to replicate it. So then I tried psql from my Mac again, this time with -X, and the transaction was properly cancelled. Some more fiddling,and I find that this is the culprit: \set ON_ERROR_ROLLBACK interactive So I guess it transparently rolls back a savepoint for the previous statement. I had forgotten I turned that on. Apologiesfor the noise. David
On May 11, 2012, at 9:51 AM, David E. Wheeler wrote: > \set ON_ERROR_ROLLBACK interactive > > So I guess it transparently rolls back a savepoint for the previous statement. I had forgotten I turned that on. Apologiesfor the noise. OTOH, might it be useful to have psql show some sort of status message when it does this? David
"David E. Wheeler" <david@justatheory.com> writes:
> On May 11, 2012, at 9:51 AM, David E. Wheeler wrote:
>> \set ON_ERROR_ROLLBACK interactive
>>
>> So I guess it transparently rolls back a savepoint for the previous statement. I had forgotten I turned that on.
Apologiesfor the noise.
Ah-hah.
> OTOH, might it be useful to have psql show some sort of status message when it does this?
The same occurred to me, but after more thought I think it'd just be
horribly annoying after a short time. People who have this set will
(or should, anyway) be expecting errors to be nonfatal to their
transactions.
regards, tom lane