public inbox for [email protected]
help / color / mirror / Atom feedFrom: yudhi s <[email protected]>
To: sud <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Simon Elbaz <[email protected]>
Cc: pgsql-general <[email protected]>
Subject: Re: Long running query causing XID limit breach
Date: Thu, 13 Jun 2024 13:13:06 +0530
Message-ID: <CAEzWdqfF3Vk4OYE6DPP241rHV1D27vT82VjLu_Qju1bX_PiSdw@mail.gmail.com> (raw)
In-Reply-To: <CAD=mzVWy=0HtzkjtqqCZktRDA7w0AL+mVW5+dz_E1EHqiyRYkA@mail.gmail.com>
References: <CAD=mzVXR3GjM0vcthMBwEdbOKqSKcv8oojSS9coczWRi9BRYTA@mail.gmail.com>
<[email protected]>
<CAD=mzVVvK8xk-9m8h3Xu27cGN7BW329HKYdO+0EMXfWvSD3AGA@mail.gmail.com>
<[email protected]>
<CAD=mzVVqR-mKUFHetsejFWSPQPbLjTVhCmBebJTFX5XmYp+nGg@mail.gmail.com>
<[email protected]>
<CAD=mzVXRkNM6ATTtnCsZeA0sfD6S_UPU=i6vfMTfoTBuT0pKTw@mail.gmail.com>
<CAEzWdqdix_ftiUuPJp_LZ3QjB6rDmHVfxtdVMOn+akhMAWEOGw@mail.gmail.com>
<[email protected]>
<CAEzWdqdPnErdeg6xe=zf7aF-fGy0Z42vXEm6zE6Ok25o=f6a7Q@mail.gmail.com>
<[email protected]>
<CAD=mzVU7Ry7xhZ=Kra4N87ugvAUubwGFqnLtXbcvy8yJasOVPQ@mail.gmail.com>
<CAPOUM=cxpEaN9kSHnBAQFuiMKJ7iyD7+u4wS5djY-ZWRpo_Log@mail.gmail.com>
<CAD=mzVVhE4Y637XOkqK1yMzP6U2aRhBi5xTcEZw6_Ppppb6mqA@mail.gmail.com>
<[email protected]>
<CAEzWdqfzp7+buzXkpKnHqVpq=a2kaE33fWD-nXVeEdGiTBwGEQ@mail.gmail.com>
<CAD=mzVWy=0HtzkjtqqCZktRDA7w0AL+mVW5+dz_E1EHqiyRYkA@mail.gmail.com>
On Sat, Jun 8, 2024 at 2:51 PM sud <[email protected]> wrote:
>
> Thank You so much Laurenz and Yudhi.
>
> Yes its RDS and as you mentioned there does exist a space limitation of
> ~64TB but as Laurenz mentioned the only time the second standby may crash
> would be probably because of the storage space saturation and thus we need
> to have appropriate monitoring in place to find this and get alerted
> beforehand. And also a monitoring to see how much WAL gets generated per
> hour/day to get an idea of the usage. I am not sure how to do it , but will
> check on this.
>
Not exactly related but just for our information, While going through the
"aurora postgres" database docs in regards to similar concepts which are
getting discussed here, I am finding some interesting stuff.
https://aws.amazon.com/blogs/database/manage-long-running-read-queries-on-amazon-aurora-postgresql-c...
*Cancel the conflicting query on the reader node if the conflict lasts
longer than max_standby_streaming_delay (maximum 30 seconds). This is
different from Amazon RDS or self-managed PostgreSQL. With Amazon RDS or
self-managed PostgreSQL, the instance has its own physical copy of the
database, and you’re able to set the parameter max_standby_streaming_delay
as high as you want to prevent query cancellation.If the conflicting query
can’t cancel in time, or if multiple long-running queries are causing the
replication lag to go beyond 60 seconds, Aurora restarts the reader node to
ensure it’s not lagging far behind the primary node.*
So if i get it correct it means, even if hot_standby_feedback is set to OFF,
the constraints of max_standby_streaming_delay (30 seconds) and the
60-second replication lag limit applies. And thus Aurora may cancel
long-running queries or restart reader nodes to maintain synchronization
even if it just runs for >60seconds. So it's really odd but does that mean
, by no way you can guarantee a query to run >60 seconds on read replica in
aurora postgres?
view thread (8+ messages)
reply
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: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Long running query causing XID limit breach
In-Reply-To: <CAEzWdqfF3Vk4OYE6DPP241rHV1D27vT82VjLu_Qju1bX_PiSdw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox