Re: [HACKERS] Transactions involving multiple postgres foreign servers

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Transactions involving multiple postgres foreign servers
Дата
Msg-id CA+TgmoaPsc7wQGp6h9aTiN6kAsTawHYsAiaBftJ6Vd7_vYYEUg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Transactions involving multiple postgres foreign servers  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Thu, Oct 26, 2017 at 4:11 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> Why do we want the the backend to linger behind, once it has added its
>> foreign transaction entries in the shared memory and informed resolver
>> about it? The foreign connections may take their own time and even
>> after that there is no guarantee that the foreign transactions will be
>> resolved in case the foreign server is not available. So, why to make
>> the backend wait?
>
> Because I don't want to break the current user semantics. that is,
> currently it's guaranteed that the subsequent reads can see the
> committed result of previous writes even if the previous transactions
> were distributed transactions.

Right, this is very important, and having the backend wait for the
resolver(s) is, I think, the right way to implement it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [HACKERS] WIP: BRIN bloom indexes
Следующее
От: Julien Rouhaud
Дата:
Сообщение: [HACKERS] unsafe tuple releasing in get_default_partition_oid