AW: AW: Vacuum only with 20% old tuples

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'Hiroshi Inoue'" <Inoue(at)tpf(dot)co(dot)jp>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: AW: AW: Vacuum only with 20% old tuples
Date: 2000-07-26 08:44:22
Message-ID: 11C1E6749A55D411A9670001FA68796336802E@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> The trouble with depending on WAL to handle undo of external
> operations
> (ie, filesystem calls as opposed to DB record updates) is
> that you don't
> know all the facts if you have to recover/undo the operation.
> Consider
> the following not-too-implausible example:
>
> begin transaction;
> alter table foo rename to bar;
> create table foo ...;
> delete table bar;
> <crash>
>
> If we try to implement this by log entries, we will have log entries
> for rename, create, delete.

No, you have to have two for each. One before and one after each execution.

> We scan the log and come upon the rename.
> Hmm, there's a file foo and no file bar ... looks like the
> rename didn't get done, so do it. Ooops.

No again. You come upon "starting rename operation" and then either
no more log records (backend abort)
or
log record "rename succeeded"
or
log record "rename failed" --> transaction abort

In this scenario you can decide what to do without second guessing.

> Related nasty scenarios arise when there's a file there of the right
> name but the wrong contents, created by non-database operations.
> (Consider the risks involved with a table named "core", for example.)

I have always been asking for an extension for different object files
like .dat .idx .tmp ... , but this problem is imho present with any filename
be it oid's or named files.

> An even more serious problem is that you can't guarantee to be able
> to either repeat or undo an external operation, because there are
> factors not under your control (kernel permission checks, existing
> files getting in the way, etc). Sure, failures like that are not
> very likely, but that'll be cold comfort to someone whose database
> gets corrupted because a file rename needs to be undone and can't be.

Imho in such an event I rather have my db bail out (or switch to readonly
mode).
Any further modifications would give me the shivers in such an unstable
environment.
The dba then fixes the environment and restarts the postmaster.

>
> >> If *rename* is possible,are OID filenames necessary in the
> >> first place ?
>
> > no

this was only an answer to the question, not a suggestion.

> I think that OID filenames will be a far more reliable solution to
> the alter-table-rename problem than anything that involves trying
> to actually rename the files. There are other benefits too, like
> not being tied to filesystem-based naming restrictions for tables.

I was not arguing against oid filenames in this thread, only against
the addition of a version number in the filename.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeffery Collins 2000-07-26 13:03:28 Some questions on user defined types and functions.
Previous Message Zeugswetter Andreas SB 2000-07-26 08:20:56 AW: New Privilege model purposal