| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Subject: | pg_upgrade --clone error checking |
| Date: | 2019-05-01 20:10:34 |
| Message-ID: | CAMkU=1yf4Z2xmD_Km0X3nAMH4_hfFDhC_kDtTBo0SOnjX-JgaQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
With the new pg_upgrade --clone, if we are going to end up throwing the
error "file cloning not supported on this platform" (which seems to depend
only on ifdefs) I think we should throw it first thing, before any other
checks are done and certainly before pg_dump gets run.
This might result in some small amount of code duplication, but I think it
would be worth the cost.
For cases where we might throw "could not clone file between old and new
data directories", I wonder if we shouldn't do some kind of dummy copy to
catch that error earlier, as well. Maybe that one is not worth it.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arthur Zakirov | 2019-05-01 20:20:05 | Re: to_timestamp docs |
| Previous Message | Andres Freund | 2019-05-01 19:39:47 | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 |