Re: Fast COPY after TRUNCATE bug and fix

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Fast COPY after TRUNCATE bug and fix
Date: 2007-03-01 14:17:38
Message-ID: 45E6E082.7080803@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches


I'm sorry. I misread the patch. I now see it used in index.c. return to
normal viewing ...

cheers

andrew

Andrew Dunstan wrote:
>
> what is the point of this?:
>
> + void
> + RelationCacheResetAtEOXact(void)
> + {
> + need_eoxact_work = true;
> + }
>
>
>
> and why is it declared extern in relcache.h when it is only used in
> relcache.c?
>
> ISTM that there isn't much reason to un-inline the statement, and the
> patch could be a lot smaller without it.
>
> cheers
>
> andrew
>
> Bruce Momjian wrote:
>> 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
>>>
>>
>>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2007-03-01 14:20:13 Re: [PATCHES] WIP Patch - Updateable Cursors
Previous Message Andrew Dunstan 2007-03-01 14:12:02 Re: Fast COPY after TRUNCATE bug and fix