On Fri, Sep 02, 2005 at 04:02:08PM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> THe only fundamental disadvantage that COPY labors under is having to
> >> write WAL records. It might be interesting to do something similar to
> >> the recent hacks for CREATE TABLE AS, so that a COPY into a table just
> >> created in the current transaction would skip writing WAL and instead
> >> fsync the table at the end.
>
> > Added to TODO:
> > o Allow COPY into an empty table to skip WAL logging
>
> It has to be a *new* table, not an *empty* table. If it's already
> visible to other xacts then somebody else could insert into it in
> parallel with you, because COPY doesn't take an exclusive lock.
What about the indexes? Logging one of the inserters and not the other
is certain to corrupt the whole thing. (Logging index insertion but not
the heap itself is silly, but perhaps an easy way out is to disable the
feature for tables with indexes.)
> Contrariwise, it doesn't really matter (I think) if there are WAL-logged
> records already in the table and COPY is adding more that aren't logged.
Only if the page is locked in a fashion that the bulk loader can't
insert tuples into a page that the other transaction is using. (Not
sure if this can happen in reality.) Else we risk both inserting a
tuple in the same page, and on recovery finding out that somebody else
used the tuple slot.
--
Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com
"Los románticos son seres que mueren de deseos de vida"
