Hello,
It seems that I am running into this issue as well.
Is it likely that this would ever be a config option?
Best,
Pierre Barre
On Fri, May 3, 2024, at 05:11, Riku Iki wrote:
> I did the testing and confirmed that this was the issue.
>
> I run following query:
>
> create table t as selec
On Thu, 26 Dec 2024 13:24:03 -0800
Will Storey wrote:
> My incident was actually not caused by autovacuum. A VACUUM was run
> against the primary by a cronjob. A web service running read queries
> against hot standbys went down for several minutes as its queries
> were stuck in a lock queue.
>
>
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
> > was replicated to a hot standby
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
> was replicated to a hot standby.
>
> When that outage happened it was from a VACUUM call in a cronjo
--setup
create table a(i int);
create table b(i int);
insert into a values (1);
insert into b values (1);
-- case 1
set synchronous_commit = off;
begin read write;
update a set i = i + 1;
commit;
set synchronous_commit = on;
begin read write;
update b set i = i + 1;
commit;
-- case 2
set synchro
Hi,
We are facing a similar problem using a docker from
https://hub.docker.com/_/postgres on AWS EC2 machine.
The version we are using is 17 (docker image "postgres:17")
The issue happens on our CI server, and it happens consistently.
The table is a big one (related to
https://www.postgresql.org/me
