Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Fix mdsync never-ending loop problem

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] Fix mdsync never-ending loop problem
Date: 2007-04-10 18:41:02
Message-ID: 28448.1176230462@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
I wrote:
> This patch looks fairly sane to me; I have a few small gripes about
> coding style but that can be fixed while applying.  Heikki, you were
> concerned about the cycle-ID idea; do you have any objection to this
> patch?

Actually, on second look I think the key idea here is Takahiro-san's
introduction of a cancellation flag in the hashtable entries, to
replace the cases where AbsorbFsyncRequests can try to delete entries.

What that means is mdsync() doesn't need an outer retry loop at all:
the periodic AbsorbFsyncRequests calls are not a hazard, and retry of
FileSync failures can be handled as an inner loop on the single failing
table entry.  (We can make the failure counter a local variable, too,
instead of needing space in every hashtable entry.)

And with that change, it's no longer possible for an incoming stream
of fsync requests to keep mdsync from terminating.  It might fsync
more than it really needs to, but it won't repeat itself, and it must
reach the end of the hashtable eventually.  So we don't actually need
the cycle counter at all.

It might be worth having the cycle counter anyway just to avoid doing
"useless" fsync work.  I'm not sure about this.  If we have a cycle
counter of say 32 bits, then it's theoretically possible for an fsync
to fail 2^32 consecutive times and then be skipped on the next try,
allowing a checkpoint to succeed that should not have.  We can fix that
with a few more lines of logic to detect a wrapped-around value, but is
it worth the trouble?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Kris KennawayDate: 2007-04-10 18:43:04
Subject: Re: Anyone interested in improving postgresql scaling?
Previous:From: Tom LaneDate: 2007-04-10 17:36:20
Subject: Re: [PATCHES] Fix mdsync never-ending loop problem

pgsql-patches by date

Next:From: Gurjeet SinghDate: 2007-04-10 19:18:40
Subject: Re: [HACKERS] [Fwd: Index Advisor]
Previous:From: Tom LaneDate: 2007-04-10 17:36:20
Subject: Re: [PATCHES] Fix mdsync never-ending loop problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group