Re: augmenting MultiXacts to improve foreign keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: augmenting MultiXacts to improve foreign keys
Date: 2011-08-09 20:40:15
Message-ID: 12383.1312922415@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
>> Right now, FKs aren't really very special, they are mostly just
>> syntactic sugar (right?). This proposal would make FKs special internal
>> mechanisms, and I don't see the benefit in doing so.

> Well, you can get the same behavior by adding the constraint triggers
> manually. But those triggers are written in C, so you could equally
> claim that they are "special internal" already. The SPI interface has
> some special entry points to allow them to work correctly (for example
> passing a snapshot for the checks to run with).

Yeah, the crosscheck-snapshot logic already puts the lie to any idea
that the RI triggers are equivalent to anything available at the SQL
level.

ISTM you could pass down the "please do this with FOR KEY UPDATE not
just FOR SHARE" flag similarly to the way the crosscheck snapshot is
passed down, or maybe even just do it if you see a crosscheck snapshot
is present in the executor state (though that's a bit ugly).

Like Florian, I'm considerably more concerned about the aspect of
deciding which columns are "key columns" and whether they changed.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-08-09 21:03:24 Re: augmenting MultiXacts to improve foreign keys
Previous Message Alvaro Herrera 2011-08-09 20:36:30 Re: Ignore lost+found when checking if a directory is empty