Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: missing LockBuffer(buffer, BUFFER_LOCK_SHARE) in trigger.c GetTupleForTrigger?
Date: 2012-11-30 20:47:59
Message-ID: 23729.1354308479@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

BTW, on further inspection, there's yet another reason why we've not
heard about this from the field: even if all the wrong things happen and
GetTupleForTrigger manages to copy bogus data for the old tuple, that
data *is not passed to the trigger function*. The only thing we do with
it is decide whether to queue an event for the trigger. So if you've
got a WHEN condition for the trigger, that expression would see the bad
data, or if it's an RI trigger the bad data is passed to
RI_FKey_pk_upd_check_required or RI_FKey_fk_upd_check_required. But
unless the data is corrupt enough to cause a crash, the worst outcome
would be a wrong decision about whether the trigger needs to be run.

It's possible this explains some of the reports we've seen about RI
constraints being violated.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2012-11-30 20:49:51 Re: Hot Standby Feedback should default to on in 9.3+
Previous Message Heikki Linnakangas 2012-11-30 20:46:06 Re: Hot Standby Feedback should default to on in 9.3+