Re: Fast COPY after TRUNCATE bug and fix
От | Andrew Dunstan |
---|---|
Тема | Re: Fast COPY after TRUNCATE bug and fix |
Дата | |
Msg-id | 45E6DF32.1000804@dunslane.net обсуждение исходный текст |
Ответ на | Re: Fast COPY after TRUNCATE bug and fix (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Fast COPY after TRUNCATE bug and fix
(Andrew Dunstan <andrew@dunslane.net>)
Re: Fast COPY after TRUNCATE bug and fix ("Simon Riggs" <simon@2ndquadrant.com>) |
Список | pgsql-patches |
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 >> > >
В списке pgsql-patches по дате отправления: