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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
