Re: Transactions involving multiple postgres foreign servers

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Transactions involving multiple postgres foreign servers
Дата
Msg-id CAA4eK1Jk5Tqj0n+=h6BQRnDQdye4aqBpjiQKrYK57bD6WngLVw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Transactions involving multiple postgres foreign servers  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
On Thu, Jul 9, 2015 at 3:48 PM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote:
2. New catalog - This method takes out the need to have separate method for
C1, C5 and even C2, also the synchronization will be taken care of by row
locks, there will be no limit on the number of foreign transactions as well
as the size of foreign prepared transaction information. But big problem
with this approach is that, the changes to the catalogs are atomic with the
local transaction. If a foreign prepared transaction can not be aborted
while the local transaction is rolled back, that entry needs to retained.
But since the local transaction is aborting the corresponding catalog entry
would become invisible and thus unavailable to the resolver (alas! we do
not have autonomous transaction support). We may be able to overcome this,
by simulating autonomous transaction through a background worker (which can
also act as a resolver). But the amount of communication and
synchronization, might affect the performance.

Or you could insert/update the rows in the catalog with xmin=FrozenXid, ignoring MVCC. Not sure how well that would work.

I am not aware how to do that. Do we have any precedence in the code. Something like a reference implementation, which I can follow.

Does some thing on lines of Copy Freeze can help here?

However if you are going to follow this method, then I think you
need to also ensure when and how to clear those rows after
rollback is complete or once resolver has resolved those prepared
foreign transactions.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: 高增琦
Дата:
Сообщение: Re: buffer locking fix for lazy_scan_heap
Следующее
От: Rajeev rastogi
Дата:
Сообщение: Re: Autonomous Transaction is back