On Thu 2024-12-26 12:21:08 -0800, Jeremy Schneider wrote:
> On Mon, 16 Dec 2024 16:25:06 -0800
> Will Storey wrote:
>
> > I would like to disable vacuum's truncate behaviour for autovacuum.
> > Previously I had an outage due to its access exclusive lock when it
&
On Tue 2024-12-17 08:30:19 +0100, Laurenz Albe wrote:
> > Would I need to disable the settings on catalog tables too? (To rule out
> > any possibility of it happening). Are there any other things I might be
> > missing?
>
> Potentially yes. But unless you are using temporary tables or create,
> a
Hi!
I would like to disable vacuum's truncate behaviour for autovacuum.
Previously I had an outage due to its access exclusive lock when it was
replicated to a hot standby.
When that outage happened it was from a VACUUM call in a cronjob rather
than autovacuum. I now run such VACUUMs with TRUNCAT
Hello!
I am running Postgres 16.6 on a primary and several standby servers. I
recently observed 3 queries being cancelled with this error:
ERROR: canceling statement due to conflict with recovery (SQLSTATE 40P01)
There was this detail with the error:
User transaction caused buffer deadlock with
On Sun 2019-09-01 20:58:30 -0400, Tom Lane wrote:
> >> A separate question is how come the particular query you're complaining
> >> about has (seemingly) a fairly wide window where it never does any
> >> CHECK_FOR_INTERRUPTS call before terminating. Perhaps there's someplace
> >> we need to sprink
On Sun 2019-09-01 19:46:19 -0400, Tom Lane wrote:
> I poked at this for awhile and concluded that what you must be seeing is
> that the statement timeout interrupt triggers, but no CHECK_FOR_INTERRUPTS
> call happens thereafter, until we get to the disable_statement_timeout()
> call in finish_xact_
On Sat 2019-08-17 10:32:40 -0700, Adrian Klaver wrote:
> > I know this query can time out, and it does, resulting in the error I
> > expect: "canceling statement due to statement timeout". The problem is
> > occasionally I see this other error: "canceling statement due to user
> > request".
> >
>
Hi!
I have a query that fails due to this error and I'm trying to understand
why.
My understanding is I should only see this error if I cancel a query
manually, such as with kill -INT or with pg_cancel_backend(). However I
can't find anything doing that.
The query looks like this:
SELECT *
