Re: Hot Standby dev build (v8)
От | Simon Riggs |
---|---|
Тема | Re: Hot Standby dev build (v8) |
Дата | |
Msg-id | 1232369659.2327.62.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Hot Standby dev build (v8) (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Hot Standby dev build (v8)
Re: Hot Standby dev build (v8) |
Список | pgsql-hackers |
On Mon, 2009-01-19 at 14:00 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > GetSnapshotData() sets > > RecentGlobalXmin to the result of the snapshot's xmin. > > No. RecentGlobalXmin is set to the oldest *xmin* observed, across all > running transactions. TransactionXmin is the xid of the oldest running > transaction. IOW, RecentGlobalXmin is the xid of transaction that the > oldest running transaction sees as running. OK. That was fun. These WAL records are annoying, no matter what the exact value of latestRemovedXid is and they seem likely to conflict with many queries on the standby. If we don't use RecentGlobalXmin then I can't see any easily derived value that we can use in its place. It isn't worth the effort on the master to derive a more exact value, not when we don't even know if it matters yet. I suggest we handle this on the recovery side, not on the master, by deriving the xmin at the point the WAL record arrives. We would calculate it by looking at recovery procs only. That will likely give us a later value than we would get from the master, but that can't be helped. For me, this makes it essential now that I put in place the deferred cancellation mechanism. Some refactoring in this area is also required because we need to handle two other types of conflict to correctly support drop database and drop user, which is now underway. Btree deletes were an important optimisation when it first went it, but now we have HOT it is much less important. Another route might be to put an option to turn off btree delete on the master, default = on. We probably should consider turning it off entirely when it doesn't yield significant benefit. Lots of scanning to remove the odd row is probably pretty wasteful and likely adds contention at the very point we don't want it - index splits. Thoughts? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: