Excellent !
thanks a lot, it was exactly what I was looking for.
Marc MILLAS
Senior Architect
+33607850334
www.mokadb.com
On Tue, Dec 14, 2021 at 6:14 PM Laurenz Albe
wrote:
> On Tue, 2021-12-14 at 13:38 +0100, Marc Millas wrote:
> > but... when you do setup a streaming replication, there is,
On Tue, 2021-12-14 at 13:38 +0100, Marc Millas wrote:
> but... when you do setup a streaming replication, there is, in
> postgresql.conf, a variable:
> max_standby_streaming_delay = 30s # max delay before canceling queries when
> reading streaming WAL;
>
> as the secondary is, by nature, read o
On Tuesday, December 14, 2021, Marc Millas wrote:
>
>
> So, if its not a locking scheme, what can block hundreds of transaction to
> get to the secondary ???
>
The transactions are present on the secondary. It just realizes that
applying them may cause problems (think drop table or truncate) and
I did read this, before asking my question...
but... when you do setup a streaming replication, there is, in
postgresql.conf, a variable:
max_standby_streaming_delay = 30s # max delay before canceling queries when
reading streaming WAL;
as the secondary is, by nature, read only, I was wondering w
On Monday, December 13, 2021, Marc Millas wrote:
>
> I was wondering if for example, within a join, some kind of lock may be
> acquired so that the dataset concerned is not changed during execution ?
> (for example a delete then autovacuum ??)
>
Read this primer on MVCC from the docs:
https://ww
