Re: recovery testing for beta - Mailing list pgsql-hackers

Hi,

On 2014-06-02 09:03:25 -0700, Jeff Janes wrote:
> On Fri, May 30, 2014 at 8:09 PM, Amit Kapila <amit.kapila16@gmail.com>
> wrote:
> 
> > On Sat, May 31, 2014 at 3:51 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> > > On Thu, May 29, 2014 at 8:15 PM, Amit Kapila <amit.kapila16@gmail.com>
> > wrote:
> > >> On Thu, May 29, 2014 at 10:09 PM, Jeff Janes <jeff.janes@gmail.com>
> > wrote:
> > >> >
> > >> > What features in 9.4 need more beta testing for recovery?
> > >>
> > >> Another feature which have interaction with recovery is reduced WAL
> > >> for Update operation:
> > >>
> > http://www.postgresql.org/message-id/E1WNqjM-0003cz-EL@gemulon.postgresql.org
> > >>
> > >> Commit: a3115f
> > >
> > >
> > > It looks like this is something which is "always on", so it should be
> > getting a good test without me taking any special steps.  But is there some
> > way, for example something in xlogdump, to assess how often this is getting
> > activated?
> >
> > Currently there is no simple way to get this information, but with
> > attached simple patch you can get this information by pg_xlogdump.
> >
> > It will give you information in below way:
> >
> > rmgr: Heap        len (rec/tot):     47/    79, tx:        690, lsn:
> > 0/0375B4A0,
> >  prev 0/0375B470, bkp: 0000, desc: hot_update: rel 1663/12125/24580; tid
> > 0/1 xma
> > x 690 ; new tid 0/2 xmax 0; *compressed tuple:* *suffix encoded*
> >
> > rmgr: Heap        len (rec/tot):     53/    85, tx:        691, lsn:
> > 0/0375B520,
> >  prev 0/0375B4F0, bkp: 0000, desc: hot_update: rel 1663/12125/24580; tid
> > 0/2 xma
> > x 691 ; new tid 0/3 xmax 0; *compressed tuple: prefix encoded*
> >
> > rmgr: Heap        len (rec/tot):     56/    88, tx:        692, lsn:
> > 0/0375B5A8,
> >  prev 0/0375B578, bkp: 0000, desc: hot_update: rel 1663/12125/24580; tid
> > 0/3 xma
> > x 692 ; new tid 0/4 xmax 0; *uncompressed tuple*
> >
> > I think this is useful information and can be even included in core
> > code.

I'd like to include something, but I think those are a bit long...

> Non-HOT updates can also be compressed, if they happen to land in the same
> page as the old version, so I copied that code into the non-HOT update
> section as well.

Right.

> GNU make does not realize that pg_xlogdump depends
> on src/backend/access/rmgrdesc/heapdesc.c.  (I don't know how or why it has
> that dependency, but changes did not take effect with a simple "make
> install") Is that a known issue?  Is there someway to fix it?

Hm. I can't reproduce this here. A simple 'touch heapdesc.c' triggers a
rebuild of pg_xlogdump for me. Could you include the make output?

> Also, pg_xlogdump -p .... insists on being given a start position.  I would
> be nice if it could just find the first file in the given directory.  Any
> reason it can't do that, other than just that no one implemented it yet?

It actually should accept getting a file passed instead of -s/-e.
pg_xlogdump [OPTION]... [STARTSEG [ENDSEG]]
That doesn't work for you?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services