9.1 plperlu bug with null rows in trigger hash

From: Greg Sabino Mullane <greg(at)endpoint(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: 9.1 plperlu bug with null rows in trigger hash
Date: 2011-05-23 20:59:32
Message-ID: 20110523205931.GM4253@core.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I've not been able to duplicate this in a standalone script yet,
but in the guts of Bucardo is a trigger function called validate_goat()
that is giving this error on 9.1 HEAD, but not on previous versions:

"Failed to add table "public.pgbench_tellers": DBD::Pg::st execute
failed: ERROR: Modification of non-creatable hash value attempted,
subscript "pkey" at line 4."

I was able to simplify the function to just this and still produce
the error:

CREATE OR REPLACE FUNCTION bucardo.validate_goat()
RETURNS TRIGGER
LANGUAGE plperlu
AS
$bc$

my $new = $_TD->{new};
$new->{pkey} = 'foobar';

return 'MODIFY';

$bc$;

It's used like this:

CREATE TRIGGER validate_goat
BEFORE INSERT OR UPDATE ON bucardo.goat
FOR EACH ROW EXECUTE PROCEDURE bucardo.validate_goat();

The goat table has many text fields, of which one is
pkey. Setting it to any of those other columns will cause the error.
However, setting it to a text field that is NOT NULL DEFAULT will
*not* produce the error, so obviously something is setting
$_TD->{new}{somecol} to undef in the wrong way. I'm baffled as
to why I cannot reproduce it standalone, but wanted to get the
bug out there so I don't forget about it and in case anyone
wants to take a swing at it. Some Googling suggests it might
be because we are using &PL_sv_undef instead of a proper
newSV(0).

--
Greg Sabino Mullane greg(at)endpoint(dot)com
End Point Corporation
PGP Key: 0x14964AC8

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alex Hunsaker 2011-05-23 23:04:40 Re: 9.1 plperlu bug with null rows in trigger hash
Previous Message Heikki Linnakangas 2011-05-23 19:30:38 Re: Seg-fault in format(text)