Re: recovery testing for beta

On Fri, May 30, 2014 at 8:09 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Sat, May 31, 2014 at 3:51 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > On Thu, May 29, 2014 at 8:15 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >> On Thu, May 29, 2014 at 10:09 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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.
>

Thanks.

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.

Taking a snapshot of a running pg_xlog directory, I found 25241
uncompressed and 14179 compressed tuples, so I think this feature is
getting exercised, though mostly in the non-HOT form.

Some side notes:

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?

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?

Thanks,

Jeff