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

Re: unsafe use of hash_search(... HASH_ENTER ...)

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: unsafe use of hash_search(... HASH_ENTER ...)
Date: 2005-05-27 04:47:31
Message-ID: d768t0$1d9c$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes
> "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> "Unsafe" is a bit of an overstatement, when you evidently haven't
> analyzed the consequences of either choice of error level.  That is,
> why is this a bug?

Consider the senario like this:

Backends register some dirty segments in BgWriterShmem->requests; bgwrite
will AbsorbFsyncRequests() asynchornously but failed to record some one in
pendingOpsTable due to an "out of memory" error. All dirty segments
remembered in "requests" after this one will not have chance be absorbed by

Recall we have already removed those dirty segment by:

     BgWriterShmem->num_requests = 0;

So we will have no chance to pick up it again. That is, we will never fsync
some dirty segments (mdwrite() will not sync those files themselves either
because ForwardFsyncRequest() is successfully done).


In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2005-05-27 05:39:57
Subject: Re: foreign keys and RI triggers
Previous:From: Bruce MomjianDate: 2005-05-27 04:11:43
Subject: Re: Fix for timestamp rouding

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