Message-ID: <f045c8f7-ee24-ead6-3679-c04a43d21351@gmail.com>
Date: Thu, 26 Oct 2023 07:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: Is this a problem in GenericXLogFinish()?
Content-Language: en-US
To: Jeff Davis <pgsql@j-davis.com>, Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@postgresql.org
References: <d2c31606e6bb9b83a02ed4835d65191b38d4ba12.camel@j-davis.com>
 <146426fc662f88604c700a72a3833b1919922f9e.camel@j-davis.com>
 <CA+TgmobvdZMWj5=fextXP_Q81eS9g0sbVbVE4qiKAtJs8dMjyA@mail.gmail.com>
 <08b4f1f7dcf321d38373f06acc65a8d62cc2f017.camel@j-davis.com>
 <CA+TgmoZ24f5eNNJFV6chv+xjCOOy9-uZqwPwrWVvQMZfHUsMxQ@mail.gmail.com>
 <6d23aff2-7151-65b1-528b-2189ffa6e2df@iki.fi>
 <57c59f08bbb92875251dc97dbc47600fa237712c.camel@j-davis.com>
 <50bebdf8bbf79475e3fc0fff398d77b1577c1b97.camel@j-davis.com>
 <bf396b45-318a-4940-87eb-3d295a93da8b@iki.fi>
 <b1f2d0f230d60fa8df33bb0b2af3236fde9d750d.camel@j-davis.com>
 <CA+TgmoZ54E0w5vCXYRAFKnunZy_SKB-4rbFq+7L=qUgFUYdtfQ@mail.gmail.com>
 <d54c5738052eead54d65e4fd3667f161aa447680.camel@j-davis.com>
 <CA+TgmoY+dagCyrMKau7UQeQU6w4LuVEu+yjsmJBoXKAo6XbUUA@mail.gmail.com>
 <4b2dfe9c67713413a06be761f677bc34222afcb4.camel@j-davis.com>
 <CA+TgmobjyWDQfiMLj1_Lf0GheiY0SaOEPbFEepfa3G-XOLmHOA@mail.gmail.com>
 <23d87b531fab74e69fd753791a7e5047f17da9ab.camel@j-davis.com>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <23d87b531fab74e69fd753791a7e5047f17da9ab.camel@j-davis.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/f045c8f7-ee24-ead6-3679-c04a43d21351%40gmail.com>
Precedence: bulk

Hello hackers,

24.10.2023 03:45, Jeff Davis wrote:
> Committed.

I've encountered a case with a hash index, when an assert added by the
commit fails:

CREATE TABLE t (i INT);
CREATE INDEX hi ON t USING HASH (i);
INSERT INTO t SELECT 1 FROM generate_series(1, 1000);

BEGIN;
INSERT INTO t SELECT 1 FROM generate_series(1, 1000);
ROLLBACK;

CHECKPOINT;

VACUUM t;

Leads to:
Core was generated by `postgres: law regression [local] VACUUM                                       '.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/211944' in core file too small.
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=139924569388864) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=139924569388864) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=139924569388864) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=139924569388864, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007f42b99ed476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007f42b99d37f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x000055f128e83f1b in ExceptionalCondition (conditionName=0x55f128f33520 "BufferIsExclusiveLocked(buffer) && 
BufferIsDirty(buffer)", fileName=0x55f128f333a8 "xloginsert.c", lineNumber=262) at assert.c:66
#6  0x000055f1287edce3 in XLogRegisterBuffer (block_id=1 '\001', buffer=1808, flags=8 '\b') at xloginsert.c:262
#7  0x000055f128742833 in _hash_freeovflpage (rel=0x7f42adb95c88, bucketbuf=1808, ovflbuf=1825, wbuf=1808, 
itups=0x7ffc3f18c010, itup_offsets=0x7ffc3f18bce0, tups_size=0x7ffc3f18ccd0, nitups=0, bstrategy=0x55f12a562820)
     at hashovfl.c:671
#8  0x000055f128743567 in _hash_squeezebucket (rel=0x7f42adb95c88, bucket=6, bucket_blkno=7, bucket_buf=1808, 
bstrategy=0x55f12a562820) at hashovfl.c:1064
#9  0x000055f12873ca2a in hashbucketcleanup (rel=0x7f42adb95c88, cur_bucket=6, bucket_buf=1808, bucket_blkno=7, 
bstrategy=0x55f12a562820, maxbucket=7, highmask=15, lowmask=7, tuples_removed=0x7ffc3f18fb28,
     num_index_tuples=0x7ffc3f18fb30, split_cleanup=false, callback=0x55f1289ba1de <vac_tid_reaped>, 
callback_state=0x55f12a566778) at hash.c:921
#10 0x000055f12873bfcf in hashbulkdelete (info=0x7ffc3f18fc30, stats=0x0, callback=0x55f1289ba1de <vac_tid_reaped>, 
callback_state=0x55f12a566778) at hash.c:549
#11 0x000055f128776fbb in index_bulk_delete (info=0x7ffc3f18fc30, istat=0x0, callback=0x55f1289ba1de <vac_tid_reaped>, 
callback_state=0x55f12a566778) at indexam.c:709
#12 0x000055f1289ba03d in vac_bulkdel_one_index (ivinfo=0x7ffc3f18fc30, istat=0x0, dead_items=0x55f12a566778) at 
vacuum.c:2480
#13 0x000055f128771286 in lazy_vacuum_one_index (indrel=0x7f42adb95c88, istat=0x0, reltuples=-1, vacrel=0x55f12a4b9c30) 
at vacuumlazy.c:2768
#14 0x000055f1287704a3 in lazy_vacuum_all_indexes (vacrel=0x55f12a4b9c30) at vacuumlazy.c:2338
#15 0x000055f128770275 in lazy_vacuum (vacrel=0x55f12a4b9c30) at vacuumlazy.c:2256
...

It looks like the buffer is not dirty in the problematic call.

Best regards,
Alexander