From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alfonso Moscato <alfonso.moscato@merqurio.it>
Cc: pgsql-admin@lists.postgresql.org
Subject: Re: R: repeated out of shared memory error - not related to max_locks_per_transaction
Date: Fri, 20 Jul 2018 11:06:35 -0400
Message-ID: <19852.1532099195@sss.pgh.pa.us> (raw)
In-Reply-To: <016801d42037$4f5d4630$ee17d290$@merqurio.it>
References: <00a601d4201a$e2291a10$a67b4e30$@merqurio.it>
<17662.1532096551@sss.pgh.pa.us>
<016801d42037$4f5d4630$ee17d290$@merqurio.it>
"Alfonso Moscato" <alfonso.moscato@merqurio.it> writes:
> I have some extensions installed, namely:
> "plpgsql"
> "mysql_fdw"
> "multicorn"
> "pg_cron"
> "tds_fdw"
> "pg_stat_statements"
plpgsql doesn't use any shared memory. pg_stat_statements does but it's a
one-time, fixed-size allocation. The others you mention perhaps deserve
investigation; I'm not familiar with their innards.
The fact that the problem seems to be related to the passage of time and
not to any particular application action might perhaps lead one to suspect
pg_cron. But that's a leap of logic unsupported by any facts.
> I have 200 connections and 384 max_locks_per_transaction in postgresql.conf,
> that brings the ttal number og locks to 76.800.
Right, or more accurately, enough shmem space for that many locks will
be reserved at postmaster start.
> I have surely very big queries, some with more than 50 tables, subqueries,
> and so on.
Well, 50-table queries are not your problem, no matter how much data
they process. Transactions that touch, say, 100000 different tables
might be your problem. I've heard of people having to raise
max_locks_per_transaction in order to run pg_dump against databases
with lots of tables, for example.
> As for your questions:
> 1) lock table entries needed: we check regularly the number of locks. It
> doesn't seem they usually exceed some hundreds. I will create a cron to
> check them regularly.
You would really need to catch the state of the lock table just when the
error is reported --- a check even a few seconds before that might not
show any distress.
> How could I understand which extension is consuming shared memory? I can't
> figure how.
AFAIK there isn't any good way except to check their source code for
ShmemAlloc* and ShmemInit* calls.
> Is there some way other than increasing max_locks_per_transaction to drive
> postgres to allocate more shared memory?
That's the only knob that wouldn't also produce a matching increase
in the size of postmaster-startup allocations. There isn't any real
downside to raising it; the only effect is to increase the size of
the shmem segment.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, alfonso.moscato@merqurio.it, pgsql-admin@lists.postgresql.org
Subject: Re: R: repeated out of shared memory error - not related to max_locks_per_transaction
In-Reply-To: <19852.1532099195@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox