Re: Transactions involving multiple postgres foreign servers, take 2
От | Amit Kapila |
---|---|
Тема | Re: Transactions involving multiple postgres foreign servers, take 2 |
Дата | |
Msg-id | CAA4eK1+8rFeQLE2NORXeiw79pqH94Y5wp+xy6K46WKG5bJH6vw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Transactions involving multiple postgres foreign servers, take 2 (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>) |
Ответы |
Re: Transactions involving multiple postgres foreign servers, take 2
|
Список | pgsql-hackers |
On Fri, Jun 12, 2020 at 7:59 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote: > > On Thu, 11 Jun 2020 at 22:21, Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > I have another question about > > this field, why can't it be one of the status ('preparing', > > 'prepared', 'committing', 'aborting', 'in-doubt') rather than having a > > separate field? > > Because I'm using in-doubt field also for checking if the foreign > transaction entry can also be resolved manually, i.g. > pg_resolve_foreign_xact(). For instance, a foreign transaction which > status = 'prepared' and in-doubt = 'true' can be resolved either > foreign transaction resolver or pg_resolve_foreign_xact(). When a user > execute pg_resolve_foreign_xact() against the foreign transaction, it > sets status = 'committing' (or 'rollbacking') by checking transaction > status in clog. The user might cancel pg_resolve_foreign_xact() during > resolution. In this case, the foreign transaction is still status = > 'committing' and in-doubt = 'true'. Then if a foreign transaction > resolver process processes the foreign transaction, it can commit it > without clog looking. > I think this is a corner case and it is better to simplify the state recording of foreign transactions then to save a CLOG lookup. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: