| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'J(dot) R(dot) Nield'" <jrnield(at)usol(dot)com> |
| Cc: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Tucker <richt(at)multera(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PITR, checkpoint, and local relations |
| Date: | 2002-08-02 23:42:57 |
| Message-ID: | 3705826352029646A3E91C53F7189E325185DA@sectorbase2.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Are you sure this is true for all ports?
Well, maybe you're right and it's not.
But with "after-image blocks in log after checkpoint"
you really shouldn't worry about block atomicity, right?
And ability to turn blocks logging on/off, as suggested
by Richard, looks as appropriate for everyone, ?
> And if so, why would it be cheaper for the kernel to do it in
> its buffer manager, compared to us doing it in ours? This just
> seems bogus to rely on. Does anyone know what POSIX has to say
> about this?
Does "doing it in ours" mean reading all data files through
our shared buffer pool? Sorry, I just don't see point in this
when tar ect will work just fine. At least for the first release
tar is SuperOK, because of there must be and will be other
problems/bugs, unrelated to how to read data files, and so
the sooner we start testing the better.
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-08-02 23:49:07 | Re: PITR, checkpoint, and local relations |
| Previous Message | Tatsuo Ishii | 2002-08-02 22:42:45 | Re: Build errors with current CVS |