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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-patches(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: [HACKERS] Fix mdsync never-ending loop problem
Date: 2007-04-12 15:42:20
Message-ID: 22503.1176392540@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I believe Itagaki-san's motivation for tackling this in the LDC patch
> was the fact that it can fsync the same file many times, and in the
> worst case go to an endless loop, and adding delays inside the loop
> makes it much more likely. After that is fixed, I doubt any of the
> optimizations of trying to avoid extra fsyncs make any difference in
> real applications, and we should just keep it simple, especially if we
> back-patch it.

I looked at the dynahash code and noticed that new entries are attached
to the *end* of their hashtable chain. While this maybe should be
changed to link them at the front, the implication at the moment is that
without a cycle counter it would still be possible to loop indefinitely
because we'd continue to revisit the same file(s) after removing their
hashtable entries. I think you'd need a constant stream of requests for
more than one file falling into the same hash chain, but it certainly
seems like a potential risk. I'd prefer a solution that adheres to the
dynahash API's statement that it's unspecified whether newly-added
entries will be visited by hash_seq_search, and will in fact not loop
even if they always are visited.

> That said, I'm getting tired of this piece of code :).

Me too.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-04-12 15:45:23 Re: [COMMITTERS] pgsql: RESET SESSION, plus related new DDL commands.
Previous Message Peter Eisentraut 2007-04-12 15:37:04 Re: Makefile patch to make gcov work on Postgres contrib modules

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-04-12 15:49:57 Re: Autovacuum PGPROCs in ProcGlobal? (was Re: autovacuum multiworkers)
Previous Message Jeff Frost 2007-04-12 15:35:24 Re: Slow Postgresql server