| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pendingOps table is not cleared with fsync=off |
| Date: | 2020-08-06 17:35:54 |
| Message-ID: | 35a4a635-08c6-05cf-ebce-6a51cf0c91e6@iki.fi |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/08/2020 18:42, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> On 09/05/2020 02:53, Thomas Munro wrote:
>>> On Sat, May 9, 2020 at 9:21 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>>> I noticed that commit 3eb77eba5a changed the logic in
>>>> ProcessSyncRequests() (formerly mdsync()) so that if you have fsync=off,
>>>> the entries are not removed from the pendingOps hash table. I don't
>>>> think that was intended.
>
> I'm looking at this commit in connection with writing release notes
> for next week's releases. Am I right in thinking that this bug leads
> to indefinite bloat of the pendingOps hash table when fsync is off?
> If so, that seems much more worth documenting than the assertion
> failure.
That's correct.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-08-06 18:10:15 | Re: pendingOps table is not cleared with fsync=off |
| Previous Message | Robert Haas | 2020-08-06 16:43:17 | Re: new heapcheck contrib module |