Re: Remove xmin and cmin from frozen tuples

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
Subject: Re: Remove xmin and cmin from frozen tuples
Date: 2005-09-02 20:27:59
Message-ID: 17726.1125692879@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On Fri, Sep 02, 2005 at 04:02:08PM -0400, Tom Lane wrote:
>> 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.

Good point, but that fits in just fine with the restriction to
just-created tables.

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

What other transaction? The point I was making is that
BEGIN;
CREATE TABLE ...
INSERT ...
COPY ...
is still optimizable. There isn't going to be anyone competing with
the COPY while it runs.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-09-02 20:29:32 Re: Procedural language definitions (was Re: 8.1 and syntax checking at create time)
Previous Message Andrew Dunstan 2005-09-02 20:21:34 Re: Procedural language definitions (was Re: 8.1 and syntax