| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Marc Millas <marc(dot)millas(at)mokadb(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: locks within select |
| Date: | 2021-12-14 13:20:19 |
| Message-ID: | CAKFQuwYZRteawdWqqTeP9Kj8M8pvEbdiJotLDjTOgOiSAGS++g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tuesday, December 14, 2021, Marc Millas <marc(dot)millas(at)mokadb(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sanjay Minni | 2021-12-14 15:36:48 | timestamp default current_timestamp not working |
| Previous Message | Marc Millas | 2021-12-14 12:38:06 | Re: locks within select |