> > > > Or - create tmp file and load with new content;
> > > > log "intent to relink table file";
> > > > relink table file; log "file is relinked".
> > > 
> > > It seems to me that whole content of the table should be
> > > logged before relinking or shrinking.
> > 
> > Why not just fsync tmp files?
> >
> 
> Probably I've misunderstood *relink*.
> If *relink* different from *rename* ?

I ment something like this - link(table file, tmp2 file); fsync(tmp2 file);
unlink(table file); link(tmp file, table file); fsync(table file);
unlink(tmp file). We can do additional logging (with log flush) of these
steps
if required, postpone on-recovery redo of operations till last relink log
record/
end of log/transaction abort etc etc etc.

Vadim

Wed, 21 Jun 2000 18:30:23 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: Big 7.1 open items 
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
> 
> > > > > Or - create tmp file and load with new content;
> > > > > log "intent to relink table file";
> > > > > relink table file; log "file is relinked".
> > > > 
> > > > It seems to me that whole content of the table should be
> > > > logged before relinking or shrinking.
> > > 
> > > Why not just fsync tmp files?
> > >
> > 
> > Probably I've misunderstood *relink*.
> > If *relink* different from *rename* ?
> 
> I ment something like this - link(table file, tmp2 file); 
> fsync(tmp2 file);
> unlink(table file); link(tmp file, table file); fsync(table file);
> unlink(tmp file).

I see,old file would be rolled back from tmp2 file on abort.
This would work on most platforms.
But cygwin port has a flaw that files could not be unlinked
if they are open. So *relink* may fail in some cases(including
rollback cases).

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

Thu, 22 Jun 2000 12:09:15 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: Big 7.1 open items 

> I ment something like this - link(table file, tmp2 file); fsync(tmp2 file);
> unlink(table file); link(tmp file, table file); fsync(table file);
> unlink(tmp file).

I don't see the purpose of the fsync() calls here: link() and unlink()
effect file system metadata, which with normal Unix (but not Linux)
filesystem semantics is written synchronously.

fsync() on a file forces outstanding data to disk; it doesn't effect
the preceding or subsequent link() and unlink() calls unless
McKusick's soft updates are in use.

If the intent is to make sure the files are in particular states
before each of the link() and unlink() calls (i.e. soft updates or
similar functionality are in use) then more than fsync() is required,
since the files can still be updated after the fsync() and before
link() or unlink().

On Linux I understand that a fsync() on a directory will force
metadata updates to that directory to be committed, but that doesn't
seem to be what this code is trying to do either?

Regards,

Giles




Thu, 22 Jun 2000 21:58:08 +1000
Giles Lean <giles@nemeton.com.au>
Re: Big 7.1 open items 
> 1) In the 'WAL Parameters' section, paragraph 3 there is the following
> sentence: "After a checkpoint has been made, any log segments written
> before the redo record may be removed/archived..."  What does the 'may'
> refer mean? Does the database administrator need to go into the 
> directory and remove the no longer necessary log files?  What does
> archiving have to do with this? If I archived all log files, could
> I roll forward a backup made previously? That is the only reason I can
> think of that you would archive log files (at least that is why you
> archive log files in Oracle).

Offline log segments are removed automatically at checkpoint time.
WAL based BAR is not implemented yet, so no archiving is made
currently.

> 2) The doc doesn't seem to explain how on database recovery 
> the database knows which log file to start with. I think walking
> through an example of how after a database crash, the log file is
> used for recovery, would be useful. At least it would make me as
> a user of postgres feel better if I understood how crashes are
> recovered from.

After checkpoint is made (log flushed) its position is saved in
pg_control file. So, on recovery backend first read pg_control,
than checkpoint record, than redo record (its position is saved
in checkpoint) and begins REDO op. Because of entire content of
pages is saved in log on first-after-checkpoint page modification
pages will be first restored to consistent stage.

Using pg_control to get checkpoint position speed up things but
to handle possible pg_control corruption we obviously should
implement reading existent log segments (from the last one -
newest - to oldest) to get last checkpoint.

Vadim

Wed, 24 Jan 2001 13:25:39 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: WAL documentation
Here's a patch to the wal.sgml text to take acocunt of Vadim's
explanations.




Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
                 ========================================
     "If anyone has material possessions and sees his
      brother in need but has no pity on him, how can the
      love of God be in him?"
                                    I John 3:17
Wed, 24 Jan 2001 22:12:32 +0000
"Oliver Elphick" <olly@lfix.co.uk>
Re: WAL documentation 
Oliver Elphick writes:

> Here's a patch to the wal.sgml text to take acocunt of Vadim's
> explanations.

I checked in your documentation plus some fixes at other places.  Does
somebody care to submit some new words to describe the fsync option
(http://www.postgresql.org/devel-corner/docs/postgres/runtime-config.htm)?

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/


Thu, 25 Jan 2001 00:27:06 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: WAL documentation 