Re: Two-phase commit issues
От | Tom Lane |
---|---|
Тема | Re: Two-phase commit issues |
Дата | |
Msg-id | 5331.1116521829@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Two-phase commit issues (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Two-phase commit issues
(Heikki Linnakangas <hlinnaka@iki.fi>)
|
Список | pgsql-hackers |
Heikki Linnakangas <hlinnaka@iki.fi> writes: > As Alvaro pointed out elsewhere, the multixacts are harder because a > backend doesn't know which multixactids it belongs to. AFAICS, the most > straightforward solution is to xlog every CreateMultixact call, so that > the multixact slru files can be completely reconstructed on recovery. I realized this morning that in fact it *can't* know that, since even after a particular transaction commits it's still possible for others to add it to new multixacts. In the case of a prepared xact it would continue to get added to new multixacts indefinitely :-(. So the idea of recording info about this in the state files is clearly a loser. I think we will indeed have to start xlogging multixact operations. > Third, we have to cater for PITR. I haven't given it much thought, but if > we want to do log shipping and PITR, I believe we must have everything in > the WAL. Hmm. All your other arguments for WAL-logging a prepare are bogus, but this one seems real. (It's also a reason why multixact stuff needs to be xlogged, I guess.) >> * I'm inclined to think that the "gid" identifiers for prepared >> transactions ought to be SQL identifiers (names), not string literals. >> Was there a particular reason for making them strings? > Sure. No Reason. While you're at it, do you think it's possible to make it > unlimited size? I couldn't think of a simple way. Actually, one reason for wanting them to be identifiers is so that there's a principled reason for saying what the max length is ;-) > I think the safest way to handle the GUC case as well is to just refuse to > prepare a transaction that has changed local GUC variables. That seems unnecessarily restrictive. > Another possibility is to rethink the contract of PREPARE TRANSACTION and > COMMIT/ROLLBACK PREPARED. If PREPARE TRANSACTION would put the backend to > a state where you can't do anything else than COMMIT/ROLLBACK the prepared > transaction, we could do more sensible things with GUC and temp tables. > That would have complications of it's own though. What would happen if > another backend then tries to COMMIT/ROLLBACK the transaction the original > backend is still tied to? Yeah, I do not think this is a useful answer. Allowing the commit to happen somewhere else and restricting what a prepared xact can do with temp tables seems much more useful in practice. regards, tom lane
В списке pgsql-hackers по дате отправления: