Re: [BUG] Crash on pgbench initialization.

2023-07-25 Thread Anton A. Melnikov

On 25.07.2023 06:24, Andres Freund wrote:

Thanks Anton / Victoria for the report and fix. Pushed.


Thanks!
Have a nice day!


--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




Re: [BUG] Crash on pgbench initialization.

2023-07-24 Thread Andres Freund
Hi,

On 2023-07-24 09:42:44 -0700, Andres Freund wrote:
> > I don't know this code at all, but I hope that this can be solved with
> > just Anton's proposed patch.
> 
> Yes, it's just that off-by-one.  I need to check if there's a similar bug for
> local / temp table buffers though.

Doesn't appear that way. We *do* fail if there's only 1 remaining buffer, but
we already did before my change (because we also need to pin the fsm). I don't
think that's an issue worth worrying about, if all-1 of local buffers are
pinned, you're going to have problems.

Thanks Anton / Victoria for the report and fix. Pushed.

Greetings,

Andres Freund




Re: [BUG] Crash on pgbench initialization.

2023-07-24 Thread Michael Paquier
On Mon, Jul 24, 2023 at 03:54:33PM +0200, Alvaro Herrera wrote:
> I see Michael marked it as such in the open items
> page, but did not CC Andres, so I'm doing that here now.

Indeed, thanks!
--
Michael


signature.asc
Description: PGP signature


Re: [BUG] Crash on pgbench initialization.

2023-07-24 Thread Andres Freund
Hi,

On 2023-07-24 15:54:33 +0200, Alvaro Herrera wrote:
> On 2023-Jul-24, Michael Paquier wrote:
> 
> > On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> > > After some research, found this happens when the LimitAdditionalPins() 
> > > returns exactly zero.
> > > In the current master, this will happen e.g. if shared_buffers = 10MB and 
> > > max_worker_processes = 40.
> > > Then the command "pgbench --initialize postgres" will lead to crash.
> > > See the backtrace attached.
> > > 
> > > There is a fix in the patch applied. Please take a look on it.
> > 
> > Nice catch, issue reproduced here so I am adding an open item for now.
> > (I have not looked at the patch, yet.)
> 
> Hmm, I see that all this code was added by 31966b151e6a, which makes
> this Andres' item.  I see Michael marked it as such in the open items
> page, but did not CC Andres, so I'm doing that here now.

Thanks - I had indeed not seen this.  I can't really keep up with the list at
all times...


> I don't know this code at all, but I hope that this can be solved with
> just Anton's proposed patch.

Yes, it's just that off-by-one.  I need to check if there's a similar bug for
local / temp table buffers though.

Greetings,

Andres Freund




Re: [BUG] Crash on pgbench initialization.

2023-07-24 Thread Alvaro Herrera
On 2023-Jul-24, Michael Paquier wrote:

> On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> > After some research, found this happens when the LimitAdditionalPins() 
> > returns exactly zero.
> > In the current master, this will happen e.g. if shared_buffers = 10MB and 
> > max_worker_processes = 40.
> > Then the command "pgbench --initialize postgres" will lead to crash.
> > See the backtrace attached.
> > 
> > There is a fix in the patch applied. Please take a look on it.
> 
> Nice catch, issue reproduced here so I am adding an open item for now.
> (I have not looked at the patch, yet.)

Hmm, I see that all this code was added by 31966b151e6a, which makes
this Andres' item.  I see Michael marked it as such in the open items
page, but did not CC Andres, so I'm doing that here now.

I don't know this code at all, but I hope that this can be solved with
just Anton's proposed patch.

-- 
Álvaro HerreraBreisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)




Re: [BUG] Crash on pgbench initialization.

2023-07-24 Thread Michael Paquier
On Sun, Jul 23, 2023 at 11:21:47PM +0300, Anton A. Melnikov wrote:
> After some research, found this happens when the LimitAdditionalPins() 
> returns exactly zero.
> In the current master, this will happen e.g. if shared_buffers = 10MB and 
> max_worker_processes = 40.
> Then the command "pgbench --initialize postgres" will lead to crash.
> See the backtrace attached.
> 
> There is a fix in the patch applied. Please take a look on it.

Nice catch, issue reproduced here so I am adding an open item for now.
(I have not looked at the patch, yet.)
--
Michael


signature.asc
Description: PGP signature


[BUG] Crash on pgbench initialization.

2023-07-23 Thread Anton A. Melnikov

Hello!

My colleague Victoria Shepard reported that pgbench might crash
during initialization with some values of shared_buffers and
max_worker_processes in conf.

After some research, found this happens when the LimitAdditionalPins() returns 
exactly zero.
In the current master, this will happen e.g. if shared_buffers = 10MB and 
max_worker_processes = 40.
Then the command "pgbench --initialize postgres" will lead to crash.
See the backtrace attached.

There is a fix in the patch applied. Please take a look on it.

With the best regards,

--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company#1  0x7f9169557859 in __GI_abort () at abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x7f91696eabf7, sa_sigaction 
= 0x7f91696eabf7}, sa_mask = {__val = {1, 140262515851294, 3, 140727328224084, 
12, 140262515851298, 2, 3487533463194566656, 7292515507211941683, 
94490218952736, 7291953849184874368, 0, 6147461878018348800, 140727328224176, 
94490235583952, 140727328225056}}, sa_flags = 938440736, sa_restorer = 
0x7ffda268ef80}
sigs = {__val = {32, 0 }}
#2  0x55f03865f3a8 in ExceptionalCondition (conditionName=0x55f038846b8c 
"nblocks > 0", fileName=0x55f038846997 "md.c", lineNumber=534) at assert.c:66
No locals.
#3  0x55f038479e41 in mdzeroextend (reln=0x55f038ed6e38, 
forknum=MAIN_FORKNUM, blocknum=0, nblocks=0, skipFsync=false) at md.c:534
v = 0x55f038d96300
curblocknum = 0
remblocks = 0
__func__ = "mdzeroextend"
#4  0x55f03847c747 in smgrzeroextend (reln=0x55f038ed6e38, 
forknum=MAIN_FORKNUM, blocknum=0, nblocks=0, skipFsync=false) at smgr.c:525
No locals.
#5  0x55f03842fc72 in ExtendBufferedRelShared (eb=..., fork=MAIN_FORKNUM, 
strategy=0x55f038e1d7a8, flags=8, extend_by=0, extend_upto=4294967295, 
buffers=0x7ffda268ba30, extended_by=0x7ffda268b8fc) at bufmgr.c:2057
first_block = 0
io_context = IOCONTEXT_BULKWRITE
io_start = {ticks = 0}
__func__ = "ExtendBufferedRelShared"
#6  0x55f03842f512 in ExtendBufferedRelCommon (eb=..., fork=MAIN_FORKNUM, 
strategy=0x55f038e1d7a8, flags=8, extend_by=17, extend_upto=4294967295, 
buffers=0x7ffda268ba30, extended_by=0x7ffda268b9dc) at bufmgr.c:1805
first_block = 22000
#7  0x55f03842de78 in ExtendBufferedRelBy (eb=..., fork=MAIN_FORKNUM, 
strategy=0x55f038e1d7a8, flags=8, extend_by=17, buffers=0x7ffda268ba30, 
extended_by=0x7ffda268b9dc) at bufmgr.c:862
No locals.
#8  0x55f037f773fa in RelationAddBlocks (relation=0x7f91655d97b8, 
bistate=0x55f038e1d778, num_pages=17, use_fsm=false, did_unlock=0x7ffda268bb8d) 
at hio.c:324
victim_buffers = {1, 0, 953770752, 22000, -1570194736, 0, 955084344, 
22000, 955072168, 22000, 0, 0, -1570194800, 32765, 944220747, 22000, 16384, 0, 
955084344, 22000, 0, 0, 953770752, 22000, -1570194752, 32765, 944228643, 22000, 
-1570194752, 0, 955084344, 22000, 0, 0, 1700632504, 0, -1570194704, 32765, 
939296560, 22000, -1570194624, 0, 1700632504, 32657, 16384, 0, 0, 0, 
-1570194672, 32765, 943901980, 22000, 8000, 0, 1700632504, 32657, -1570194624, 
32765, 943923688, 22000, -1570194512, 0, 1700632504, 32657}
first_block = 4294967295
last_block = 4294967295
extend_by_pages = 17
not_in_fsm_pages = 17
buffer = 22000
page = 0xa268ba20 
__func__ = "RelationAddBlocks"
#9  0x55f037f77d01 in RelationGetBufferForTuple (relation=0x7f91655d97b8, 
len=128, otherBuffer=0, options=6, bistate=0x55f038e1d778, 
vmbuffer=0x7ffda268bc2c, vmbuffer_other=0x0, num_pages=17) at hio.c:749
use_fsm = false
buffer = 0
page = 0x6a268bc34 
nearlyEmptyFreeSpace = 8016
pageFreeSpace = 0
saveFreeSpace = 0
targetFreeSpace = 128
targetBlock = 4294967295
otherBlock = 4294967295
unlockedTargetBuffer = 127
recheckVmPins = false
__func__ = "RelationGetBufferForTuple"
#10 0x55f037f5e5e2 in heap_multi_insert (relation=0x7f91655d97b8, 
slots=0x55f038e37b08, ntuples=1000, cid=15, options=6, bistate=0x55f038e1d778) 
at heapam.c:2193
buffer = 32657
all_visible_cleared = false
all_frozen_set = false
nthispage = -1570194336
xid = 734
heaptuples = 0x55f038ed1e98
i = 1000
ndone = 0
scratch = {data = 
"мh\242\001\000\000\000\204\352}e\221\177\000\000\340\274h\242\375\177\000\000\v|F8\360U\000\000\020\275h\242\001\000\000\000\204\352}e\221\177\000\000\020\275h\242\375\177\000\000\211\233F8\360U\000\000\020\275h\001\000\000\224\223\200\352}e\221\177\000\000`\267\241\000\000\000\000
 
\000\000\000\000\001\000\000\000\260\275h\242\375\177\000\000\242\352B8\004\000\000\000P\275h\242\375\177\000\000\342\333J8\360U\000\000\000\000\000\000\002\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000p\177\000\000\330\344\336\070\360U\000\000\200\275h\242\375\177\000\000\333\334J8\360