| From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
|---|---|
| To: | kevin(at)sysexperts(dot)com |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Win32 Powerfail testing |
| Date: | 2003-03-08 00:05:30 |
| Message-ID: | 20030308.090530.104028095.t-ishii@sra.co.jp |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> But even then, we don't actually have to track the *names* of the
> files that have changed, just their RelFileNodes, since there's a
> mapping function from the RelFileNode to the filename.
Right. I have noticed that too and have made changes to my
implementaion.
BTW, you need to track the block number as well. Files > 1GB may be
splitted into separate files (segments).
> > Of course, if there are lots of files, sync() may be faster than
> > opening/fsync/closing all those files.
>
> This is true, and is something I hadn't actually thought of. So it
> sounds like some testing would be in order.
I regard the difference between sync() and fsync() does not affect too
much to the whole performance. Checkpoint process is performed as a
separate process and the fsync() part of checkpoint does nothing with
WAL, that means other backend processes, busy with WAL IO will
not be bothered.
--
Tatsuo Ishii
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Clift | 2003-03-08 00:16:55 | Re: Who puts the Windows binaries on the FTP server? |
| Previous Message | Brian Hirt | 2003-03-07 23:32:57 | Re: division by zero |