From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Hot Standby Design |
Date: | 2008-09-24 16:51:40 |
Message-ID: | 1222275100.4445.612.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-09-24 16:56:34 | Re: parallel pg_restore |
Previous Message | Robert Treat | 2008-09-24 16:35:28 | Re: Hot Standby Design |