agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@gmail.com>
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: WAL logging problem in 9.4.3?
Date: Mon, 6 Jul 2015 17:21:23 +0200
Message-ID: <20150706152123.GK8902@alap3.anarazel.de> (raw)
In-Reply-To: <27532.1436195680@sss.pgh.pa.us>
References: <CAHGQGwEXta1tMF6o-FcDcjMgCF=jnZLj3v3EoePvsEN4aexJnA@mail.gmail.com>
<20150703060137.GB20285@svana.org>
<CAHGQGwFtOMv5h8eKX6zf+9_0UxpcTsyH9xAnyv6KdGH4BonLiw@mail.gmail.com>
<28320.1435935120@sss.pgh.pa.us>
<CAHGQGwGzxAyKLUm+z2n43-ee6u976jLmQAz=pPBVzSueD3CAig@mail.gmail.com>
<20150703164931.GI3291@awork2.anarazel.de>
<20150703170229.GJ3291@awork2.anarazel.de>
<20150703172605.GM3291@awork2.anarazel.de>
<CAHGQGwGGM2OBh4WOTd8wWqxKzRy+WdJX+-fxxPCWNz4eeJ1aQQ@mail.gmail.com>
<27532.1436195680@sss.pgh.pa.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
view thread (244+ messages) latest in thread
Message-ID: <20150706152123.GK8902@alap3.anarazel.de>
Permalink: ../20150706152123.GK8902@alap3.anarazel.de/
Also on: postgresql.org/message-id/20150706152123.GK8902@alap3.anarazel.de
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andres@anarazel.de, tgl@sss.pgh.pa.us, masao.fujii@gmail.com, kleptog@svana.org
Subject: Re: WAL logging problem in 9.4.3?
In-Reply-To: <20150706152123.GK8902@alap3.anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox