| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Magnus Hagander <magnus(at)hagander(dot)net> |
| Subject: | Re: Pg_upgrade speed for many tables |
| Date: | 2012-11-12 19:12:38 |
| Message-ID: | 1352747558.14335.5.camel@sussancws0025 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2012-11-12 at 10:29 -0800, Jeff Janes wrote:
> When I'm doing a pg_upgrade with thousands of tables, the shutdown
> checkpoint after restoring the dump to the new cluster takes a very
> long time, as the writer drains its operation table by opening and
> individually fsync-ing thousands of files.
This reminds me of the fix I did for initdb to sync the files. I think
we do need to make sure they are sync'd, because ext4 can keep buffers
around for quite a long time without cleaning them.
I ended up using sync_file_range(..., SYNC_FILE_RANGE_WRITE) on linux,
and posix_fadvise(..., POSIX_FADV_DONTNEED) on everything else, and that
made subsequent fsyncs more efficient.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-11-12 19:21:28 | Re: Proof of concept: standalone backend with full FE/BE protocol |
| Previous Message | Jeff Janes | 2012-11-12 18:29:39 | Re: Pg_upgrade speed for many tables |