Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock

> On Aug 9, 2022, at 7:26 PM, Andres Freund <andres@anarazel.de> wrote:
> 
> The relevant code triggering it:
> 
> 	newbuf = XLogInitBufferForRedo(record, 1);
> 	_hash_initbuf(newbuf, xlrec->new_bucket, xlrec->new_bucket,
> 				  xlrec->new_bucket_flag, true);
> 	if (!IsBufferCleanupOK(newbuf))
> 		elog(PANIC, "hash_xlog_split_allocate_page: failed to acquire cleanup lock");
> 
> Why do we just crash if we don't already have a cleanup lock? That can't be
> right. Or is there supposed to be a guarantee this can't happen?

Perhaps the code assumes that when xl_hash_split_allocate_page record was written, the new_bucket field referred to an unused page, and so during replay it should also refer to an unused page, and being unused, that nobody will have it pinned.  But at least in heap we sometimes pin unused pages just long enough to examine them and to see that they are unused.  Maybe something like that is happening here?

I'd be curious to see the count returned by BUF_STATE_GET_REFCOUNT(LockBufHdr(newbuf)) right before this panic.  If it's just 1, then it's not another backend, but our own, and we'd want to debug why we're pinning the same page twice (or more) while replaying wal.  Otherwise, maybe it's a race condition with some other process that transiently pins a buffer and occasionally causes this code to panic?

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company