Re: Fast COPY after TRUNCATE bug and fix

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Simon Riggs wrote:
> It's been pointed out to me that I introduced a bug as part of the
> recent optimisation of COPY-after-truncate.
>
> The attached patch fixes this for me on CVS HEAD. It does this by making
> an explicit request for relcache hint cleanup at EOXact and takes a more
> cautious approach during RelationCacheInvalidate().
>
> Please can this be reviewed as soon as possible? Thanks.
>
> TRUNCATE was setting a flag to show that it had created a new
> relfilenode, but the flag was not cleared in all cases. This lead to a
> COPY that followed a truncation, yet was in a *separate* transaction
> from it and in a transaction on its own, to apparently lose data. The
> data loss was caused because the COPY inadvertently avoided writing WAL,
> which then led to skipping the recording of transaction commit, leaving
> the inserted rows showing as aborted.
>
> The failing test case was:
>
> TRUNCATE foo;
> COPY foo FROM ....;
> SELECT count(*) FROM foo;
>
> The returned count should be non-zero if the COPY succeeds, yet on CVS
> HEAD this currently returns 0.
>
> CLUSTER is not affected by this change, AFAICS, because its change of
> relfilenode doesn't wait until EOXact, so COPY doesn't optimise after a
> CLUSTER-in-same-trans.
>
> Thanks to various EDB colleagues for bringing this to my attention.
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
>

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +