On 2015-07-06 11:14:40 -0400, Tom Lane wrote:
> BEGIN;
> CREATE TABLE test (i int primary key);
> INSERT INTO test VALUES(-1);
> \copy test from /tmp/num.csv with csv
> COMMIT;
> SELECT COUNT(*) FROM test;
>
> The COUNT() correctly says 11 rows, but after crash-and-recover,
> only the row with -1 is there. This is because the INSERT writes
> out an INSERT+INIT WAL record, which we happily replay, clobbering
> the data added later by COPY.
ISTM any WAL logged action that touches a relfilenode essentially needs
to disable further optimization based on the knowledge that the relation
is new.
> We might have to give up on this COPY optimization :-(.
A crazy, not well though through, bandaid for the INSERT+INIT case would
be to force COPY to use a new page when using the SKIP_WAL codepath.
> I'm not sure what would be a safe rule for deciding that we can skip
> WAL logging in this situation, but I am pretty sure that it would
> require keeping information we don't currently keep about what's
> happened earlier in the transaction.
It'd not be impossible to add more state to the relcache entry for the
relation. Whether it's likely that we'd find all the places that'd need
updating that state, I'm not sure.
