Re: Hot Standby Design
От | Simon Riggs |
---|---|
Тема | Re: Hot Standby Design |
Дата | |
Msg-id | 1222275100.4445.612.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | Re: Hot Standby Design (Robert Treat <xzilla@users.sourceforge.net>) |
Список | pgsql-hackers |
On Wed, 2008-09-24 at 12:35 -0400, Robert Treat wrote: > On Wednesday 24 September 2008 03:27:44 Simon Riggs wrote: > > On Wed, 2008-09-24 at 00:30 -0400, Robert Treat wrote: > > > * "However, some WAL redo actions will be for DDL actions. These DDL > > > actions are repeating actions that have already committed on the primary > > > node, so they must not fail on the standby node. These DDL locks take > > > priority and will automatically cancel any read-only transactions that > > > get in their way." > > > > > > Some people will want the option to stack-up ddl transactions behind > > > long-running queries (one of the main use cases of a hot slave is > > > reporting stye and other long running queries) > > > > Scheduling tools can help here. Run set of queries on Standby, then when > > complete run DDL on Primary and have its changes filter through. > > > > true... i am just reminded of Oracle 8's log replay, where you had to stop > replay to run any queries... given that was a usefull feature, I suspect > we'll hear complaints about it not going that way. I think one could argue > that we might be able to provide such an option in the future, if not in the > first release. It probably sounds worse than it is. If you drop a table on the Primary, then somebody running a query against it on the Standby is in for a shock. But on the other hand, why are you dropping a table that people still consider worth reading? DROP TABLE should be carefully researched before use, so I don't think its a big problem. We could make it wait for a while before cancelling, as an option, if you think its important? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: