Re: fix "Success" error messages

TAKATSUKA Haruka <harukat@sraoss.co.jp>

From: TAKATSUKA Haruka <harukat@sraoss.co.jp>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>
Date: 2019-11-21T01:42:57Z
Lists: pgsql-hackers
Hello, pgsql-hackers

I'm gathering information about the following error.

 FATAL: could not access status of transaction ..
 DETAIL: Could not read from file (pg_clog/.... or pg_xact/....) ...: Success.

This error has caused the server to fail to start with recovery.
I got a report that it happend repeatedly at the newly generated
standby cluster. I gave them advice to comfirm the low level server
environment.

However, in addition to improving the message, should we retry to read 
the rest of the data in the case reading too few bytes? 
What about a limited number of retries instead of a complete loop?

---
 Haruka Takatsuka / SRA OSS, Inc. Japan

On Fri, 27 Sep 2019 11:52:39 -0400
Bruce Momjian <bruce@momjian.us> wrote:

> On Tue, Sep  3, 2019 at 08:38:22AM +0200, Peter Eisentraut wrote:
> > On 2019-08-27 08:27, Michael Paquier wrote:
> > > Thanks for the new patch, and you are right that pg_checksums has been
> > > slacking here.  There is the same issue with pg_verify_checksums in
> > > 11.  Not sure that's worth a back-patch though.  Those parts could
> > > find their way to v12 easily.
> > 
> > Committed to master and PG12 with your suggested changes.
> 
> This "Success" has happened so many times I think we should tell people
> to report any such error message as a bug by emitting a special error
> message line.
> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
> 
> + As you are, so once was I.  As I am, so you will be. +
> +                      Ancient Roman grave inscription +




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Better error messages for short reads/writes in SLRU

  2. pg_checksums: Handle read and write returns correctly

  3. Use consistent style for checking return from system calls