On Sun, 2007-01-07 at 12:59 +0100, Martijn van Oosterhout wrote:
> On Sun, Jan 07, 2007 at 11:46:29AM +0000, Simon Riggs wrote:
> > On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
> > > "Simon Riggs" <simon@2ndquadrant.com> writes:
> > > > The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
> > > > well.
> > >
> > > I think you just talked yourself out of getting this patch applied.
> >
> > Maybe; what would be your explanation? Do you have a failure case you
> > know of? Perhaps if one exists, there is another route.
>
> One thing I pondered while looking at this: how do you know the user is
> going to commit the transaction after the COPY is complete. Could they
> run analyze or vacuum or some other DDL command on the table that would
> get confused by the disparity between the hint bits and the xlog.
If it crashes, we'll clean up the file. At end of statement it is synced
to disk. There is no failure condition where the rows continue to exist
on disk && the table relfilenode shows a committed transaction pointing
to the file containing the marked-valid-but-actually-not rows. There is
a failure condition where the new relfilenode is on disk, but the
version of the table that points to that will not be visible.
(You can't run a VACUUM inside a transaction block.)
Everybody else is locked out because the CREATE or TRUNCATE has taken an
AccessExclusiveLock.
I've just re-checked the conditions from tqual.c and they all check,
AFAICS. There would be a problem *if* it was possible to issue a
self-referential COPY, like this:
COPY foo FROM (select * from foo)
which would exhibit the Halloween problem. But this is not yet possible,
and if it were we would be able to check for that and avoid it.
I'm not saying I haven't made a mistake, but I've done lots of thinking
and checking to confirm that this is a valid thing to do. That in itself
is never enough, which is why I/we talk together. If somebody does find
a problem, its a small thing to remove that from the patch, since it is
an additional enhancement on top of the basic WAL removal.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
