| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Error while copying a large file in pg_rewind |
| Date: | 2017-07-03 18:50:16 |
| Message-ID: | c7262424-730e-a87f-9ed7-05335d3eaa9d@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7/3/17 09:53, Tom Lane wrote:
> Hm. Before we add a bunch of code to deal with that, are we sure we
> *want* it to copy such files? Seems like that's expending a lot of
> data-transfer work for zero added value --- consider e.g. a server
> with a bunch of old core files laying about in $PGDATA. Given that
> it's already excluded all database-data-containing files, maybe we
> should just set a cap on the plausible size of auxiliary files.
It seems kind of lame to fail on large files these days, even if they
are not often useful in the particular case.
Also, most of the segment and file sizes are configurable, and we have
had reports of people venturing into much larger file sizes.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-07-03 19:27:51 | Re: Error while copying a large file in pg_rewind |
| Previous Message | Emrul | 2017-07-03 18:46:51 | Re: Revisiting NAMEDATALEN |