On Fri, May 3, 2019 at 3:53 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-05-02 20:03, Jeff Janes wrote:
> > It looks like it was designed for early checking, it just wasn't placed
> > early enough. So changing it is pretty easy, as check_file_clone does
> > not need to
On 2019-05-02 20:03, Jeff Janes wrote:
> It looks like it was designed for early checking, it just wasn't placed
> early enough. So changing it is pretty easy, as check_file_clone does
> not need to be invented, and there is no additional code duplication
> over what was already there.
>
> This p
On Thu, May 2, 2019 at 12:28 PM Alvaro Herrera
wrote:
> On 2019-May-02, Jeff Janes wrote:
>
> >
> > When something is doomed to fail, we should report the failure as early
> as
> > feasibly detectable.
>
> I agree -- this check should be done before checking the database
> contents. Maybe even b
On 2019-May-02, Jeff Janes wrote:
> I think the error message wording is OK, I think it should be thrown
> earlier, before the "Creating dump of database schemas" (which can take a
> long time), and preferably before either database is even started. So
> ideally it would be something like:
>
>
On Thu, May 2, 2019 at 11:57 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2019-05-01 22:10, Jeff Janes wrote:
> > 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 o
On 2019-05-01 22:10, Jeff Janes wrote:
> 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 be
