Re: Dividing progress/debug information in pg_standby, and stat before copy - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Dividing progress/debug information in pg_standby, and stat before copy
Date
Msg-id 4B5E3769.7060601@2ndquadrant.com
Whole thread Raw
In response to Re: Dividing progress/debug information in pg_standby, and stat before copy  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Maybe I'm missing something, but I thought pg_standby would be mostly
> dead once SR hits the streets.  Is it worth spending lots of time on?
>   

I have to do the work I outlined regardless, to support installs on 
earlier versions (luckily there's few backport issues for this code).  
Also, some people are going to have working WAL shipping installs they 
just don't want to mess with as part of the upgrade--particularly given 
the relative newness of the SR code--that they should be able to convert 
over easily.

One reason we hadn't really brought up merging these pg_standby changes 
into core yet is for the reason you describe.  Simon and I didn't think 
there'd be much community uptake on the idea given it's a less likely 
approach for future installs to use, didn't want to distract everyone 
with this topic.  But if it mainly occupies time from people who have 
similar requirements that drive working on it anyway, like Selena it 
appears, it would be nice to see a "final" pg_standby get shipped as a 
result that has less obvious rough parts.  Doubt much work will go into 
it beyond this release though.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Dividing progress/debug information in pg_standby, and stat before copy
Next
From: KaiGai Kohei
Date:
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns