> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Zeugswetter Andreas SB
>
> > >> We can't "drop and recreate" without a solution to the relation
> > >> versioning issue (unless you are prepared to accept a nonfunctional
> > >> database after a failure partway through index rebuild on a system
> > >> table). I think we should do this, but it's not all that simple...
> >
> > > Is this topic independent of WAL in the first place ?
> >
> > Sure, unless Vadim sees some clever way of using WAL to eliminate
> > the need for versioned relations. But as far as I've seen in the
> > discussions, versioned relations are independent of WAL.
>
> WAL can solve the versioned relations problem.
> Remember that a sure new step in postmaster startup will be a
> rollforward of
> the WAL,
> since that will have the only sync write of our last txn's. Thus in this
> step it can also
> do any pending rename or delete of files.
Hmm,don't you allow DDL commands inside transaction block ?
If we allow DDL commands inside transaction block,WAL couldn't
postpone all rename/unlink operations until the end of transaction
without a resolution of the conflict of table file name.
For the following queries
begin; drop table t; create table t (..); insert into t values (...); commit;
the old table file of t must vanish(using unlink() etc) before 'create table
t'
unless new file name is different from old one(OID file name would
resolve the conflict in this case).
To unlink/rename the table file immediately isn't a problem for the
rollforward functionality. It seems a problem of rollback functionality.
> If a rename or delete fails we
> bail out, since we don't want postmaster running under such circumstances
> anyway.
No there's a significant difference between the failure of 'delete'
and that of 'rename'. We would have no consistency problem even
though 'delete' fails and wouldn't have to stop postmaster. But we
wouldn't be able to see the renamed relation in case of 'rename'
failure and an excellent(??) dba would have to recover the inconsistency.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
