| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: amcheck assert failure |
| Date: | 2019-04-24 18:59:46 |
| Message-ID: | CAH2-WzmG+iRikPw1NMx9ZhZc2i=xT5O=0xLVMQgXzCiDMU8zqA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Apr 24, 2019 at 1:50 AM Grigory Smolkin
<g(dot)smolkin(at)postgrespro(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2019-04-24 19:42:51 | BUG #15778: Replication slot peak query cause memory spike at the server when big transaction are running |
| Previous Message | Mike Lissner | 2019-04-24 17:07:45 | CREATE SUBSCRIPTION fails with long passwords |