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