Jeff Davis <pg...@j-davis.com> writes:
> In those terms, we can reframe the questions as: what do we do about
> reads during the load?
> Answers could include:
> (a) nothing -- reads during a load are potentially dirty
> (b) readers ignore hint bits during the load, and pay the penalty
> (c) allow only INSERT/COPY, and block unsafe SELECT/UPDATE/DELETE
Or (d) it's not a problem, since the inserting XID is still busy
according to the readers' snapshots.
The part I think is actually hard is how to clean up if the inserting
xact doesn't reach commit. I think what we're basically looking at here
is pushing more cost into that path in order to avoid cost in successful
cases. The first design that comes to mind is
(1) the inserting xact remembers which tables it's inserted pre-hinted
tuples into, and if it has to abort, it first seqscans those tables to
reset the hint bits;
(2) it also emits WAL entries that will cause crash recovery to perform
an identical scan, if WAL ends without finding a commit or abort record
for the inserting xact.
But there may be other better ways. One problem with the above sketch
is that you can't checkpoint till the insertion is committed, since a
checkpoint would prevent crash recovery from seeing the warning WAL
records.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
