Re: [HACKERS] Breakage with VACUUM ANALYSE + partitions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Breakage with VACUUM ANALYSE + partitions
Date: 2016-04-12 08:51:49
Message-ID: alpine.DEB.2.10.1604120929180.15815@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


Hello Andres,

> I can think of a number of relatively easy ways to address this:
> 1) Just zap (or issue?) all pending flush requests when getting an
> smgrinval/smgrclosenode
> 2) Do 1), but filter for the closed relnode
> 3) Actually handle the case of the last open segment not being
> RELSEG_SIZE properly in _mdfd_getseg() - mdnblocks() does so.
>
> I'm kind of inclined to do both 3) and 1).

Alas I'm a little bit outside my area of expertise. Just for suggestion
purpose, possibly totally wrong (please accept my apology if this is the
case), the ideas I had while thinking about these issues, some may be
quite close to your suggestions above:

- keep track of file/segment closing/reopenings (say with a counter), so
that if a flush is about a file/segment which has been closed or
reopened, it is just skipped. I'm not sure this is enough, because one
process may do the file cleaning and another may want to flush, although
I guess there is some kind of locking/shared data structures to manage
such interactions between pg processes.

- because of "empty the bucket when filled behavior" of the current
implementation, a buffer to be flused may be kept for a very
long time in the bucket. I think that flushing advices become stale
after a while so should not be issued (the buffer may have been
written again, ...), or the bucket should be flushed after a while
even of not full.

Also, a detail in "pg_flush_data", there are a serie of three if/endif,
but it is not obvious to me whether they are mutually exclusive while
looking at the source, so I was wondering whether the code could try
several flushings approaches one after the other... This is probably not
the case, but I would be more at ease with a if/elif/elif/endif structure
there so that is clearer.

--
Fabien.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2016-04-12 13:00:57 Re: [HACKERS] Breakage with VACUUM ANALYSE + partitions
Previous Message Tom Lane 2016-04-11 22:49:19 Re: BUG #14082: Unexpected time adjustment for output using "at time zone"

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2016-04-12 08:54:24 Re: Choosing parallel_degree
Previous Message Pavel Stehule 2016-04-12 08:18:21 Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.