RE: 7.0.3(nofsync) vs 7.1

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Jan Wieck'" <janwieck(at)Yahoo(dot)com>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: 7.0.3(nofsync) vs 7.1
Date: 2000-12-14 00:14:17
Message-ID: 8F4C99C66D04D4118F580090272A7A234D31F9@sectorbase1.sectorbase.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2000-12-14 00:21:58 Re: Idea for reducing planning time
Previous Message Alfred Perlstein 2000-12-14 00:04:34 Re: Idea for reducing planning time