Re: WIP: WAL prefetch (another approach)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: WAL prefetch (another approach)
Дата
Msg-id 1431256.1639787893@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: WAL prefetch (another approach)  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> But the bigger question is. Are we really concerned about this flaky
> problem? Is it worth investing time and money on? I can get money to
> go buy a G4 or G5 and spend some time on it. It just seems a bit...
> niche. But if it's a real bug that represents something broken on
> other architectures that just happens to be easier to trigger here it
> might be worthwhile.

TBH, I don't know.  There seem to be three plausible explanations:

1. Flaky hardware in my unit.
2. Ancient macOS bug, as Andres suggested upthread.
3. Actual PG bug.

If it's #1 or #2 then we're just wasting our time here.  I'm not
sure how to estimate the relative probabilities, but I suspect
#3 is the least likely of the lot.

FWIW, I did just reproduce the problem on that machine with current HEAD:

2021-12-17 18:40:40.293 EST [21369] FATAL:  inconsistent page found, rel 1663/167772/2673, forknum 0, blkno 26
2021-12-17 18:40:40.293 EST [21369] CONTEXT:  WAL redo at C/3DE3F658 for Btree/INSERT_LEAF: off 208; blkref #0: rel
1663/167772/2673,blk 26 FPW 
2021-12-17 18:40:40.522 EST [21365] LOG:  startup process (PID 21369) exited with exit code 1

That was after only five loops of the regression tests, so either
I got lucky or the failure probability has increased again.

In any case, it seems clear that the problem exists independently of
Munro's patches, so I don't really think this question should be
considered a blocker for those.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: WIP: WAL prefetch (another approach)
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Column Filtering in Logical Replication