Re: Transactions involving multiple postgres foreign servers, take 2

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Transactions involving multiple postgres foreign servers, take 2
Дата
Msg-id b4b3105f-39cc-df2b-55ac-4dcfa8c303da@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Transactions involving multiple postgres foreign servers, take 2  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Ответы Re: Transactions involving multiple postgres foreign servers, take 2  (Masahiro Ikeda <ikedamsh@oss.nttdata.com>)
Re: Transactions involving multiple postgres foreign servers, take 2  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список pgsql-hackers

On 2020/07/14 9:08, Masahiro Ikeda wrote:
>> I've attached the latest version patches. I've incorporated the review
>> comments I got so far and improved locking strategy.
> 
> Thanks for updating the patch!

+1
I'm interested in these patches and now studying them. While checking
the behaviors of the patched PostgreSQL, I got three comments.

1. We can access to the foreign table even during recovery in the HEAD.
But in the patched version, when I did that, I got the following error.
Is this intentional?

ERROR:  cannot assign TransactionIds during recovery

2. With the patch, when INSERT/UPDATE/DELETE are executed both in
local and remote servers, 2PC is executed at the commit phase. But
when write SQL (e.g., TRUNCATE) except INSERT/UPDATE/DELETE are
executed in local and INSERT/UPDATE/DELETE are executed in remote,
2PC is NOT executed. Is this safe?

3. XACT_FLAGS_WROTENONTEMPREL is set when INSERT/UPDATE/DELETE
are executed. But it's not reset even when those queries are canceled by
ROLLBACK TO SAVEPOINT. This may cause unnecessary 2PC at the commit phase.

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



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

Предыдущее
От: "movead.li@highgo.ca"
Дата:
Сообщение: Re: POC and rebased patch for CSN based snapshots
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Default setting for enable_hashagg_disk