Re: Fast COPY after TRUNCATE bug and fix - Mailing list 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@postgresql.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
>