Re: shared-memory based stats collector

Hello, Arthur.

At Thu, 21 Feb 2019 17:30:50 +0300, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> wrote in <db346d14-4130-57a5-5f46-9a57e9982bec(at)postgrespro(dot)ru>
> Hello,
>
> On 21.02.2019 10:05, Kyotaro HORIGUCHI wrote:
> > Done. This verison 16 looks as if the moving and splitting were
> > not happen. Major changes are:
> > - Restored old pgstats_* names. This largily shrinks the patch
> > size to less than a half lines of v15. More than that, it
> > gets easier to examine differences. (checkpointer.c and
> > bgwriter.c have a bit stale comments but it is an issue for
> > later.)
> > - Removed "oneshot" feature at all. This simplifies pgstat API
> > and let this patch far less simple.
> > - Moved StatsLock to LWTRANCHE_STATS, which is not necessary to
> > be in the main tranche.
> > - Fixed several bugs revealed by the shrinked size of the patch.
>
> I run regression tests. Unfortunately tests didn't pass, failed test
> is 'rangetypes':
>
> rangetypes ... FAILED (test process exited with exit code 2)
>
> It seems to me that an autovacuum process terminates because of
> segfault.
>
> Segfault occurs within get_pgstat_tabentry_relid(). If I'm not
> mistaken, somehow 'dbentry' hasn't valid pointer anymore.
>
> 'dbentry' is get in the line in do_autovacuum():
>
> dbentry = pgstat_fetch_stat_dbentry(MyDatabaseId);
>
> 'dbentry' becomes invalid after calling pgstat_vacuum_stat().

Thank you very much for the report. I haven't seen the error, but
I think you gave me enough information about the issue. I try to
reproduce it.

I found another problem commit_ts test reliably fails by dshash
corruption in startup process. I've not found why and will
investigate it, too.

regarsds.

--
Kyotaro Horiguchi
NTT Open Source Software Center