Re: A micro-optimisation for walkdir() - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: A micro-optimisation for walkdir()
Date
Msg-id CA+hUKG+o2FXKJUw7iNwQ33S1sv2mT6V6K21sB8+CRWtfeSNCew@mail.gmail.com
Whole thread Raw
In response to Re: A micro-optimisation for walkdir()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A micro-optimisation for walkdir()
List pgsql-hackers
On Fri, Sep 4, 2020 at 3:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Hmm.  Well I had it like that in an earlier version, but then I
> > couldn't figure out the right way to write code that would work in
> > both frontend and backend code, without writing two copies in two
> > translation units, or putting the whole thing in a header.  What
> > approach do you prefer?
>
> Well, there are plenty of places in src/port/ where we do things like
>
> #ifndef FRONTEND
>         ereport(ERROR,
>                 (errcode_for_file_access(),
>                  errmsg("could not get junction for \"%s\": %s",
>                         path, msg)));
> #else
>         fprintf(stderr, _("could not get junction for \"%s\": %s\n"),
>                 path, msg);
> #endif
>
> I don't see a compelling reason why this function couldn't report
> stat() failures similarly, especially if we're just going to have
> the callers do exactly the same thing as that anyway.

Ok, so the main weird thing is that you finish up having to pass in an
elevel, but that has different meanings in FE and BE code.  Note that
you still need a PGFILE_ERROR return value, because we don't log
messages at a level that exits non-locally (and that concept doesn't
even exist for FE logging).

Attachment

pgsql-hackers by date:

Previous
From: Anastasia Lubennikova
Date:
Subject: Re: history file on replica and double switchover
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: On login trigger: take three