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:
> 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

[ Attachment, skipping... ]

> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to [EMAIL PROTECTED] so that your
>        message can get through to the mailing list cleanly

  Bruce Momjian  <[EMAIL PROTECTED]>

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to