Re: BUG #14999: pg_rewind corrupts control file global/pg_control

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: TipTop Labs <office(at)tiptop-labs(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Date: 2018-03-02 15:35:07
Message-ID: CA+q6zcWeFmGc=uC5CwL7HznL25nCqh0CvepgtyuGQo1duStE+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

> On 27 February 2018 at 02:24, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> Note that I am still not completely happy with the
> handling in errno in some newly-added code paths..

It maybe a stupid question, but why do you need to reset errno here? Is it to
avoid its value being carried from previous calls of `open_target_file`? In
this case if you put the code with `errno == EACCESS` under the if condition
`if (dstfd < 0)`, then as far as I remember you should always get relevant
errno. At the same time maybe it's valid to reset `errno` before `open`, like
with `getpriority`:

For some system calls and library functions (e.g., getpriority(2)), -1 is
a valid return on success. In such cases, a successful return can be
distinguished from an error return by setting errno to zero before the
call, and then, if the call returns a status that indicates that an error
may have occurred, checking to see if errno has a nonzero value.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Aiello 2018-03-02 18:11:28 RE: BUG #15091: to_number() returns incorrect value
Previous Message Tom Lane 2018-03-02 14:46:39 Re: BUG #15095: schema's owner can drop object's in his schema

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-03-02 15:35:58 Re: ON CONFLICT DO UPDATE for partitioned tables
Previous Message David Steele 2018-03-02 15:30:42 Re: autovacuum: change priority of the vacuumed tables