Re: Fast COPY after TRUNCATE bug and fix

Patch applied.  Thanks.

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


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@postgresql.org so that your
>        message can get through to the mailing list cleanly

--
  Bruce Momjian  <bruce@momjian.us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

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