Sorry for the confusion I caused. The question about connection management
and pg bouncer was a distraction and should have been addressed separately.
When having a mixture of OLTP and OLAP on the same primary databases, is
there any benefit to declaring long running report type connections
as SER
On Tue, Mar 8, 2022 at 11:47 AM Michael Lewis wrote:
>
> Thanks to you both. If other concurrent sessions are using default
> isolation level of Read committed, would putting long running reports
> (read-only) into that read-only serializable deferrable mode be impactful
> at all?
>
I'm tending
On 3/8/22 10:47 AM, Michael Lewis wrote:
Thanks to you both. If other concurrent sessions are using default
isolation level of Read committed, would putting long running reports
(read-only) into that read-only serializable deferrable mode be
impactful at all?
The documentation says that a tr
On Tue, Mar 8, 2022 at 9:27 AM Adrian Klaver
wrote:
> "PostgreSQL maintains this guarantee even when providing the strictest
> level of transaction isolation through the use of an innovative
> Serializable Snapshot Isolation (SSI) level."
>
> Then:
>
>
> https://www.postgresql.org/docs/current/tr
On 3/8/22 08:21, Tom Lane wrote:
Michael Lewis writes:
A transaction started with the first statement will not take any SI locks,
nor will it ever receive a serialization error.
What is the meaning of SI? Anything you are aware of in source code or a
blog post that discusses this?
There's
Michael Lewis writes:
>> A transaction started with the first statement will not take any SI locks,
>> nor will it ever receive a serialization error.
> What is the meaning of SI? Anything you are aware of in source code or a
> blog post that discusses this?
There's src/backend/storage/lmgr/READ
>
> A transaction started with the first statement will not take any SI locks,
> nor
> will it ever receive a serialization error.
>
What is the meaning of SI? Anything you are aware of in source code or a
blog post that discusses this?
On Tue, 2022-03-08 at 06:29 -0700, Michael Lewis wrote:
> "The DEFERRABLE transaction property has no effect unless the transaction is
> also
> SERIALIZABLE and READ ONLY. When all three of these properties are selected
> for a transaction,
> the transaction may block when first acquiring its sna
https://www.postgresql.org/docs/14/sql-set-transaction.html
"The DEFERRABLE transaction property has no effect unless the transaction
is also SERIALIZABLE and READ ONLY. When all three of these properties are
selected for a transaction, the transaction may block when first acquiring
its snapshot,
