Re: FDW-based dblink
От | Itagaki Takahiro |
---|---|
Тема | Re: FDW-based dblink |
Дата | |
Msg-id | 20090814104655.99DC.52131E4D@oss.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: FDW-based dblink (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: FDW-based dblink
|
Список | pgsql-hackers |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote: > Quite aside from the requirement for on-commit trigger, how exactly > would you use 2PC with the remote database? When would you issue PREPARE > TRANSACTION, and when would COMMIT PREPARED? What if the local database > crashes in between - is the remote transaction left hanging in prepared > state? I'm thinking prepareing remote transactions just before commit the local transaction in CommitTransaction(). The pseudo code is something like: 1. Fire deferred triggers and do works for just-before-commit. 2. AtEOXact_dblink() => prepare and commit remotetransactions. 3. HOLD_INTERRUPTS() We cannot rollback the local transaction after this. 4. do works for commit If we need more robust atomicity, we could use 2PC against the local transaction if there some remote transactions. i.e., expand COMMIT command into PREPARE TRANSACTION and COMMIT PREPARED internally: 1. Fire deferred triggers and do works for just-before-commit. 2. AtEOXact_dblink_prepare() -- prepare remotes 3. PrepareTransaction() -- prepare local 4. AtEOXact_dblink_commit() -- commit remotes 5. FinishPreparedTransaction(commit) -- commit local I'm using deferrable after trigger for the purpose in my present prototype, and it seems to work if the trigger is called at the end of deferrable event and local backend doesn't crash in final works for commit -- and we have some should-not-failed operations in the final works already (flushing WAL, etc.). Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
В списке pgsql-hackers по дате отправления: