On Thu, May 29, 2025 at 12:43 AM John Hutchins
<John.Hutchins@wicourts.gov> wrote:
>
> Hi,
> Thanks very much for your reply.
>
> > The configuration details would help the investigation.
>
> Here are all configs which may be relevant:
>
> wal_level = logical
> max_replication_slots = 20
> max_logical_replication_workers = 14
> max_wal_senders = 20
> wal_keep_size = 4096
> max_wal_size = 4GB
> min_wal_size = 1GB
> wal_sender_timeout = 300s
> archive_mode = on
> archive_command = 'true'
> archive_timeout = 3600
> max_worker_processes = 18
> max_connections = 1000
> shared_buffers = 10GB
> maintenance_work_mem = 2GB
> work_mem = 26214kB
> effective_cache_size = 30GB
> effective_io_concurrency = 200
>
> > IIUC this issue could happen especially if there are many concurrent
> > transactions that perform DDLs. Does this match the workload on your
> > server?
>
> I'm not sure if our workload would contain "many concurrent transactions that perform DDLs." Our workload includes
DDLsto create temporary tables and also "ALTER TABLE ENABLE/DISABLE TRIGGER" statements that are single-threaded, but
mayrun concurrently with other DML operations. So, in our workloads, there is a possibility of overlap between DDL
(triggermanagement and temporary table creation) and DML from other sessions.
>
It can happen in this workload due to the reason explained in email
[1]. We are talking about the right fix for the problem.
[1] - https://www.postgresql.org/message-id/CAA4eK1LMgqeT_bPZ3MH-VKvwOqpZyfJmF7knZhu1rqt2Pqsnwg%40mail.gmail.com
--
With Regards,
Amit Kapila.
