Re: Help troubleshooting SubtransControlLock problems

From: Scott Frazer <sfrazer(at)couponcabin(dot)com>
To:
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Help troubleshooting SubtransControlLock problems
Date: 2018-03-07 21:20:30
Message-ID: CA+ey=amxyG=vvr5ednb+-PC=3nTWZ7TcNyrOGzSDRGZURaZ3mA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Mar 7, 2018 at 10:39 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:
>
> Laurenz Albe wrote:
> I think you could get in this situation if the range of open
> transactions exceeds what fits in the buffers for subtrans.c pages, and
> the subtransaction cache overflows (64 entries apiece;
> PGPROC_MAX_CACHED_SUBXIDS in src/include/storage/proc.h). Each page is
> 2048 transactions (4 bytes per xact, 8192 bytes per page;
> SUBTRANS_XACTS_PER_PAGE in src/backend/access/transam/subtrans.c), and
> we keep 32 pages (NUM_SUBTRANS_BUFFERS src/include/access/subtrans.h).
> So if your oldest transaction is over 64k XIDs old, and you have
> transactions with more than 64 subtransactions, you get in trouble.
>
> A simple solution is to increase NUM_SUBTRANS_BUFFERS and recompile.

Currently this seems to be happening when the server just starts taking
connections. It doesn't even need time to scale up anymore (previously it
took about 8 hours for the problem to re-appear)

It's only happening on the read replicas, though. I've just set my master
to handle all the traffic, but that's not really sustainable

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alvaro Herrera 2018-03-07 21:50:34 Re: Help troubleshooting SubtransControlLock problems
Previous Message PegoraroF10 2018-03-07 19:49:38 Re: Replication pull instead of push