Re: Remove xmin and cmin from frozen tuples

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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 21:28:41
Message-ID: 200509022128.j82LSf017329@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Updated TODO:
>
> > o Allow COPY on a newly-created table to skip WAL logging
>
> > On crash recovery, the table involved in the COPY would
> > have its heap and index files truncated. One issue is
> > that no other backend should be able to add to the table
> > at the same time, which is something that is currently
> > allowed.
>
> This is simply wrong. (1) a table created in the current transaction
> isn't visible to anyone else, (2) the correct rollback state is for
> it not to be there, rather than be there and empty.

New text:

o Allow COPY on a newly-created table to skip WAL logging

On crash recovery, the table involved in the COPY would
removed or have its heap and index files truncated. One
issue is that no other backend should be able to add to
the table at the same time, which is something that is
currently allowed.

I think we can lock a zero-length table and do this optimization.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-09-02 21:35:33 Re: Remove xmin and cmin from frozen tuples
Previous Message Tom Lane 2005-09-02 21:18:09 Re: Remove xmin and cmin from frozen tuples