Re: WIP: WAL prefetch (another approach)

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: WAL prefetch (another approach)
Date: 2020-05-28 21:14:25
Message-ID: 20200528211425.GA5942@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Munro escribió:

> @@ -1094,8 +1103,16 @@ WALRead(XLogReaderState *state,
> XLByteToSeg(recptr, nextSegNo, state->segcxt.ws_segsize);
> state->routine.segment_open(state, nextSegNo, &tli);
>
> - /* This shouldn't happen -- indicates a bug in segment_open */
> - Assert(state->seg.ws_file >= 0);
> + /* callback reported that there was no such file */
> + if (state->seg.ws_file < 0)
> + {
> + errinfo->wre_errno = errno;
> + errinfo->wre_req = 0;
> + errinfo->wre_read = 0;
> + errinfo->wre_off = startoff;
> + errinfo->wre_seg = state->seg;
> + return false;
> + }

Ah, this is what Michael was saying ... we need to fix WALRead so that
it doesn't depend on segment_open alway returning a good FD. This needs
a fix everywhere, not just here, and improve the error report interface.

Maybe it does make sense to get it fixed in pg13 and avoid a break
later.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Winand 2020-05-28 21:22:39 Conflict of implicit collations doesn't propagate out of subqueries
Previous Message Alexander Korotkov 2020-05-28 20:02:46 Re: Operator class parameters and sgml docs