From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | sud <suds1434(at)gmail(dot)com> |
Cc: | pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Long running query causing XID limit breach |
Date: | 2024-05-23 08:15:41 |
Message-ID: | bed28c629a839b1f354e18f416a87fd5f4f78ba7.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, 2024-05-23 at 13:41 +0530, sud wrote:
> > Yes, that is correct. You cannot run such long-running queries with a
> > transaction rate like that.
>
> When you mean transaction ,does it mean one commit ? For example if it's
> inserting+committing ~1000 rows in one batch then all the 1000 rows will
> be marked as one XID rather than 1000 different XID. and so we should look
> for batch processing rather than row by row types processing.
> Is the understanding correct?
Yes, that would help.
> > One thing you could consider is running the long-running queries on a standby
> > server. Replication will get delayed, and you have to keep all the WAL
> > around for the standby to catch up once the query is done, but it should work.
> > You'd set "max_streaming_standby_delay" to -1 on the standby.
>
> We have the "Select query" running on a reader instance , but still the writer
> instance was showing up "MaximumUsedTransactionIDs" reaching 1.5billion, so it
> means both the instance as part of same cluster so sharing same XIDs
If a long running query on the standby influences the primary, that means that
you have "hot_standby_feedback" set to "on". Set it to "off".
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Torsten Förtsch | 2024-05-23 10:23:00 | Re: Backup failure Postgres |
Previous Message | sud | 2024-05-23 08:11:31 | Re: Long running query causing XID limit breach |