Re: recovery testing for beta - Mailing list pgsql-hackers
| From | Jeff Janes |
|---|---|
| Subject | Re: recovery testing for beta |
| Date | |
| Msg-id | CAMkU=1x19iKxY6Se8kzakU4oE8cJWbJ+YkSSXMjUXPKBpe6UXg@mail.gmail.com Whole thread Raw |
| In response to | Re: recovery testing for beta (Amit Kapila <amit.kapila16@gmail.com>) |
| Responses |
Re: recovery testing for beta
(Andres Freund <andres@2ndquadrant.com>)
Re: recovery testing for beta (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| List | pgsql-hackers |
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 withattached 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 xmax 690 ; new tid 0/2 xmax 0; compressed tuple: suffix encodedrmgr: 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 xmax 691 ; new tid 0/3 xmax 0; compressed tuple: prefix encodedrmgr: 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 xmax 692 ; new tid 0/4 xmax 0; uncompressed tupleI think this is useful information and can be even included in corecode.
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
pgsql-hackers by date: