Re: recovery testing for beta

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: recovery testing for beta
Дата
Msg-id CAMkU=1x19iKxY6Se8kzakU4oE8cJWbJ+YkSSXMjUXPKBpe6UXg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: recovery testing for beta  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: recovery testing for beta
Re: recovery testing for beta
Список 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 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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: plpython_unicode test (was Re: buildfarm / handling (undefined) locales)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: recovery testing for beta