Re: Transaction Snapshot Cloning
От | Tom Lane |
---|---|
Тема | Re: Transaction Snapshot Cloning |
Дата | |
Msg-id | 24020.1200081934@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Transaction Snapshot Cloning (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Transaction Snapshot Cloning
Re: Transaction Snapshot Cloning |
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes: > If we had a function > replace_serializable_snapshot(master_xid, txid_snapshot) > this would allow us to use the txid_snapshot values to replace our > transaction's serializable snapshot. ... whereupon we'd get wrong answers. Certainly you could not allow transaction xmin to go backwards, and I'm not sure what other restrictions there would be, but the whole thing gives me the willies. > What I'm thinking about is how we might use this to have multiple > sessions working simultaneously on tasks like unloading data, Then what you want is a function that says "clone the snapshot of that specified other transaction". Not a function that lets the user substitute random snapshot data and tell you he thinks it's valid. The user isn't going to have any legal way to transfer the data between backends anyway, since no transaction can see results of an uncommitted other transaction. There *has* to be some backdoor channel involved there, and you might as well make it carry the data without the user touching it. The whole thing seems a bit backwards anyway. What you'd really want for ease of use is some kind of "fork this session" operation, that is push the info to a new process not pull it. regards, tom lane
В списке pgsql-hackers по дате отправления: