> > a) We are already going from table to index to do unique checks. This is
> > same thing, which we will do to go and update the snapshot in the
> No, it is not the same thing. Updating index snapshots requires being
> able to *re-find* a previously made index entry for the current row.
> And it has to be done 100% reliably. The worst that happens if an index
> entry is not found when it should be during a uniqueness check is that
> the uniqueness constraint is not enforced properly; which is bad but it
> doesn't lead to internally-inconsistent data structures.
We are also going to indexes to maintain the referential integrity
constraints like foreign keys. Say there are constraints like 'On Delete
Cascade' and 'On Delete Restrict', they are maintained through the indexes
and if we say that indexes can return wrong results, then the referential
integrity is lost and we no longer are ACID compliant.
In response to
pgsql-hackers by date
|Next:||From: Greg Smith||Date: 2010-03-02 05:50:08|
|Subject: Re: Re: Hot Standby query cancellation and Streaming Replication
|Previous:||From: Bruce Momjian||Date: 2010-03-02 04:56:45|
|Subject: Re: Re: Hot Standby query cancellation and
Streaming Replication integration|