Re: locks within select - Mailing list pgsql-general

From David G. Johnston
Subject Re: locks within select
Date
Msg-id CAKFQuwYZRteawdWqqTeP9Kj8M8pvEbdiJotLDjTOgOiSAGS++g@mail.gmail.com
Whole thread Raw
In response to Re: locks within select  (Marc Millas <marc.millas@mokadb.com>)
List pgsql-general
On Tuesday, December 14, 2021, Marc Millas <marc.millas@mokadb.com> 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 so it chooses not to until local queries have completed.  Since WAL is strictly linear all sessions are affected.  There is no locking needed, or IIUC even possible, and MVCC is not applicable as it only concerns itself with the behavior lf the writable primary system.

I suspect there are better attempts at describing this than my half-conscious effort here, though I’ve captured the crux of it - streaming WAL is its own unique thing.

David J.

pgsql-general by date:

Previous
From: Marc Millas
Date:
Subject: Re: locks within select
Next
From: Sanjay Minni
Date:
Subject: timestamp default current_timestamp not working