Re: Serializable read only deferrable- implications

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Serializable read only deferrable- implications
Дата
Msg-id f893f742-7a8c-6cc5-4af6-c67475669ac6@aklaver.com
обсуждение исходный текст
Ответ на Re: Serializable read only deferrable- implications  (Michael Lewis <mlewis@entrata.com>)
Список pgsql-general
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 transaction ID is only assigned to a 
> connection once a write is done, but is the assignment or not of a txn 
> id actually impactful on anything? I ask partly because it doesn't seem 
> possible to reset that once assigned, through discard all; or something 
> else like that which might be used by a connection pooler such as pg 
> bouncer. is there any way to check if a session has "done writes/updates 
> up to this point"? It seems pg_my_temp_schema() also returns the same 
> value even after 'discard temp' or 'discard all' is executed. That was 
> surprising to me, but would it be considered an issue by anyone?

I'm not following what you are asking or trying to achieve. For instance 
how pg_my_temp_schema() fits into this? You will need to provide a more 
complete description of what it is you are doing.

-- 
Adrian Klaver
adrian.klaver@aklaver.com



В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Lewis
Дата:
Сообщение: Re: Serializable read only deferrable- implications
Следующее
От: hubert depesz lubaczewski
Дата:
Сообщение: Re: Interesting fail when migrating Pg from Ubuntu Bionic to Focal