Re: amcheck assert failure - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: amcheck assert failure
Date
Msg-id CAH2-WzmG+iRikPw1NMx9ZhZc2i=xT5O=0xLVMQgXzCiDMU8zqA@mail.gmail.com
Whole thread Raw
In response to Re: amcheck assert failure  (Grigory Smolkin <g.smolkin@postgrespro.ru>)
List pgsql-bugs
On Wed, Apr 24, 2019 at 1:50 AM Grigory Smolkin
<g.smolkin@postgrespro.ru> wrote:
> No, it was definitely amcheck:
> https://pastebin.postgrespro.ru/?2c8ddf5254b2c625#PTbr+jbxFPu2wfy5SFDWdiqaqPN/N5WX8t6mo5rDpmo=

Please just post the stack trace to the list in future. We value
having that directly available from the archives.

It looks like the assertion failure happens at the point where the
next tuple is being compared to the current one, in respect of the
next tuple. The assertion failure occurs in the core code,
technically, though it is pretty much under the direct control of
amcheck at the time.

This means that my exotic explanation was wrong, and the actual
explanation is quite simple. (I told you that everyone makes stupid
mistakes.)

-- 
Peter Geoghegan



pgsql-bugs by date:

Previous
From: Mike Lissner
Date:
Subject: CREATE SUBSCRIPTION fails with long passwords
Next
From: PG Bug reporting form
Date:
Subject: BUG #15778: Replication slot peak query cause memory spike at the server when big transaction are running