Re: Odd usage of errmsg_internal in bufmgr.c - Mailing list pgsql-hackers

From Zsolt Parragi
Subject Re: Odd usage of errmsg_internal in bufmgr.c
Date
Msg-id CAN4CZFPugfT_HRsvO1-BbA6RYHuUPgJwR7BGdF8ECjgLsj=01g@mail.gmail.com
Whole thread
In response to Re: Odd usage of errmsg_internal in bufmgr.c  (Álvaro Herrera <alvherre@kurilemu.de>)
Responses Re: Odd usage of errmsg_internal in bufmgr.c
Re: Odd usage of errmsg_internal in bufmgr.c
List pgsql-hackers
> Perhaps gratuitously so ...  For instance, AFAICS the first block could
> be:


I also tried to play with a few variants for this, and I reached the
same conclusion: the cleanest version is when we simply repeat the
messages.
If we unify the messages a bit (the zeroing singular form is a bit
different compared to the others), we could introduce a helper
function but it doesn't seem that readable to me.

Also:

  if (result.status == PGAIO_RS_ERROR)
  {
  Assert(!zeroed_any); /* can't have invalid pages when zeroing them */
- affected_count = zeroed_or_error_count;
- msg_one = _("invalid page in block %u of relation \"%s\"");


* The comment after assert seems wrong, isn't it backwards? Can't have
zeroed pages with failed reads
* Is it really okay to classify read errors as "invalid pages"? This
is a read failure, so I imagine this can happen if we lost a disk
because of faulty/flaky hardware, or a user unmounting a partition, or
moving the file, or anything like that, so we weren't able to actually
try to read it. Shouldn't the error say something about read failure
or unreadable pages instead?



pgsql-hackers by date:

Previous
From: Alexandre Felipe
Date:
Subject: Re: Incremental View Maintenance, take 2
Next
From: Zsolt Parragi
Date:
Subject: Re: Improve OAuth discovery logging