Re: Hot Standby: First integrated patch

On Fri, 2008-10-17 at 16:47 -0400, Merlin Moncure wrote:
> On Fri, Oct 17, 2008 at 10:38 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >
> > First integrated patch for Hot Standby, allowing queries to be executed
> > while in recovery mode.
> >
> > The patch tests successfully with the enclosed files:
> > * primary_setup_test.sql - run it on primary node
> > * standby_allowed.sql - run on standby - should all succeed
> > * standby_disallowed.sql - run on standby - should all fail
> > plus other manual testing.
> >
> > This is still WIP - its good enough to release for comments, though I am
> > not yet confident enough to claim it bug free.
> >
> > What this doesn't do YET:
> > * cope fully with subxid cache overflows (some parts still to add)
> > * cope with prepared transactions on master
> > * work correctly when running queries AND replaying WAL
> > * work correctly with regard to AccessExclusiveLocks, which should
> > prevent access to tables
> >
> > These last four points are what I'm working on over the next two weeks,
> > plus any other holes people point out along the way. I have worked out
> > designs for most of these aspects and will discuss them on -hackers,
> > though most design notes are in the Wiki. I'm still looking into
> > prepared transactions.
> >
> > Comments appreciated.
> 
> It appears to be working, at least in some fashion.  The supplied
> tests all pass.

Cool

Thanks for testing so far.

> At first glance it seems like I have to force changes to the standby
> with pg_switch_xlog().
> 
> hmm.

You'll have to explain some more. Normally files don't get sent until
they are full, so yes, you would need to do a pg_switch_xlog().

This is not "streaming replication". Others are working on that.

> This probably isn't right:
> postgres=# \d
> 
> No relations found.
> postgres=# select count(*) from foo;
>   count
> ---------
>  1000000
> (1 row)
> 
> I created a table, pg_switch_xlog, query several times,i dropped a
> table,  pg_switch_xlog, table is 'gone', but still returns data
> 
> exit/enter session, now its gone.  Sometimes I have to exit/enter
> session to get an up to date standby.  These are just first
> impressions...

Replaying and queries don't mix yet, so that is expected. I'm working on
this in phases. This patch is phase 1 - it is not the "finished patch".
Phase 2: working on correct block locking to allow concurrent DML
changes to occcur while we run queries.
Phase 3: working on correct relation locking/relcache to allow
concurrent DDL changes to occur while we run queries.
I have designs of the above and expect to complete in next two weeks.

The reason for the above behaviour is that DDL changes need to fire
relcache invalidation messages so that the query backend sees the
change. The reason the table is still there is because the files haven't
been dropped yet. So everything you have seen is expected, by me.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support