Date: Wed, 27 Jun 2018 18:39:39 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: ENOSPC FailedAssertion("!(RefCountErrors == 0)"
Message-ID: <20180627233939.GA10276@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Precedence: bulk

While grepping logs, I came across this crash, which I caused while adding many
indices in a test environment.  I don't know that there's any reason to believe
one way or the other if this is specific to running on pg11b1.

< 2018-06-17 11:38:45.465 CDT pryzbyj >FATAL:  the database system is in recovery mode
< 2018-06-17 11:38:45.466 CDT pryzbyj >FATAL:  the database system is in recovery mode
< 2018-06-17 11:38:45.468 CDT  >FATAL:  could not extend file "base/17379/38665798": No space left on device
< 2018-06-17 11:38:45.468 CDT  >HINT:  Check free disk space.
< 2018-06-17 11:38:45.468 CDT  >CONTEXT:  WAL redo at 2AA/239676B8 for Heap/INSERT+INIT: off 1
< 2018-06-17 11:38:45.468 CDT  >WARNING:  buffer refcount leak: [2366] (rel=base/17379/38665798, blockNum=1241, flags=0x8a000000, refcount=1 1)
TRAP: FailedAssertion("!(RefCountErrors == 0)", File: "bufmgr.c", Line: 2523)

Unfortunately, I have neither a core nor stacktrace to share, as the DB was
(until after running out of space) on the same FS as /var :(

Jun 17 11:38:42 localhost abrt[30526]: Aborting dump: only 30MiB is available on /var/spool/abrt
Jun 17 11:38:45 localhost abrt[1261]: Aborting dump: only 16MiB is available on /var/spool/abrt

Not sure how useful it's to crash test ENOSPC (although I see there's
continuing patches for this case).

Justin