View Single Post

   
  #10 (permalink)  
Old 04-18-2008, 10:39 AM
Bruce Momjian
 
Posts: n/a
Default 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. +

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

Reply With Quote