On Fri, Jul 06, 2001 at 06:52:49AM -0400, Bruce Momjian wrote:
> Nathan wrote:
> > How hard would it be to turn these row records into updates against a
> > pg_dump image, assuming access to a good table-image file?
>
> pg_dump is very hard because WAL contains only tids. No way to match
> that
> > Also, isn't the WAL format rather bulky to archive hours and hours of?
If it were actually too bulky, then it needs to be made less so, since that
directly affects overall performance :-)
> > I would expect high-level transaction redo records to be much more compact;
> > mixed into the WAL
> > > > I imagine a daemon extracting redo log entries from WAL segments,
> > > > asynchronously. Mixing redo log entries into the WAL allows the WAL
> > > > to be the only synchronous disk writer in the system, a Good Thing.
> > >
> > > This comes up periodically now. WAL currently already h
> I imagine a daemon extracting redo log entries from WAL segments,
> asynchronously. Mixing redo log entries into the WAL allows the WAL
> to be the only synchronous disk writer in the system, a Good Thing.
This comes up periodically now. WAL currently already has all the info
that would be
> With stock PostgreSQL... how many committed transactions can one
lose
> on a simple system crash/reboot? With Oracle or Informix, the answer
> is zero. Is that true with PostgreSQL in fsync mode? If not, does it
> lose all in the log, or just those not yet written to the DB?
With WAL the theory
> With stock PostgreSQL... how many committed transactions can one lose
> on a simple system crash/reboot? With Oracle or Informix, the answer
> is zero. Is that true with PostgreSQL in fsync mode? If not, does it
It's true or better say should be, keeping in mind probability of bugs.
> lose all
