Horton

Thread

Commits

  1. Fix off-by-one in LimitAdditionalPins()

  1. [BUG] Crash on pgbench initialization.

    Anton A. Melnikov <aamelnikov@inbox.ru> — 2023-07-23T20:21:47Z

    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

  2. Re: [BUG] Crash on pgbench initialization.

    Michael Paquier <michael@paquier.xyz> — 2023-07-24T08:17:20Z

    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

  3. Re: [BUG] Crash on pgbench initialization.

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2023-07-24T13:54:33Z

    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)

  4. Re: [BUG] Crash on pgbench initialization.

    Andres Freund <andres@anarazel.de> — 2023-07-24T16:42:44Z

    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

  5. Re: [BUG] Crash on pgbench initialization.

    Michael Paquier <michael@paquier.xyz> — 2023-07-24T22:46:52Z

    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

  6. Re: [BUG] Crash on pgbench initialization.

    Andres Freund <andres@anarazel.de> — 2023-07-25T03:24:11Z

    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

  7. Re: [BUG] Crash on pgbench initialization.

    Anton A. Melnikov <aamelnikov@inbox.ru> — 2023-07-25T08:29:49Z

    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