On Thu, Nov 24, 2016 at 12:41 AM, Tsunakawa, Takayuki
<tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
>> Robert Haas <robertmh...@gmail.com> writes:
>> > I agree.  However, in many cases, the major cost of a fast shutdown is
>> > getting the dirty data already in the operating system buffers down to
>> > disk, not in writing out shared_buffers itself.  The latter is
>> > probably a single-digit number of gigabytes, or maybe double-digit.
>> > The former might be a lot more, and the write of the pgstat file may
>> > back up behind it.  I've seen cases where an 8kB buffered write from
>> > Postgres takes tens of seconds to complete because the OS buffer cache
>> > is already saturated with dirty data, and the stats files could easily
>> > be a lot more than that.
>> I think this is mostly FUD, because we don't fsync the stats files.  Maybe
>> we should, but we don't today.  So even if we have managed to get the system
>> into a state where physical writes are heavily backlogged, that's not a
>> reason to assume that the stats collector will be unable to do its thing
>> promptly.  All it has to do is push a relatively small amount of data into
>> kernel buffers.
> I'm sorry for my late reply, yesterday was a national holiday in Japan.
> It's not FUD.  I understand you hit the slow stats file write problem during 
> some regression test.  You said it took 57 seconds to write the stats file 
> during the postmaster shutdown.  That caused pg_ctl stop to fail due to its 
> 60 second timeout.  Even the regression test environment suffered from the 
> trouble.


Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to