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



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.



Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:


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:

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

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 [EMAIL PROTECTED] 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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to