[BUG] Crash on pgbench initialization.

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

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 Herrera Breisgau, 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)

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

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

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

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