RE: 7.0.3(nofsync) vs 7.1 - Mailing list pgsql-hackers

From Mikheev, Vadim
Subject RE: 7.0.3(nofsync) vs 7.1
Date
Msg-id 8F4C99C66D04D4118F580090272A7A234D31F9@sectorbase1.sectorbase.com
Whole thread Raw
In response to 7.0.3(nofsync) vs 7.1  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
>     I  still don't see how dirty reads can solve the RI problems.
>     If Xact A deletes a PK while Xact B inserts  an  FK,  one  of
>     them  will  either  see the new reference or the PK gone. But
>     from a transactional POV it depends on if the  opposite  Xact
>     finally commits or not to tell if that really happened.
> 
>     With dirty read, you only get "maybe my PK is gone" or "maybe
>     there is a reference".

Yes, and so we'll write special function(s) to check was PK really
gone/FK inserted or not. This funcs will call
XactLockTableWait(t_xmin|t_xmax) for questionable tuple to wait for
concurrent transaction commit/rollback. It will work as long as we
call RI triggers *after* INSERT/UPDATE/DELETE op, so triggers can
see concurrent changes with dirty reads.

Vadim


pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: Idea for reducing planning time
Next
From: "Michael Richards"
Date:
Subject: Table File Format