| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| 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 15:42:00 |
| Message-ID: | 2629130.1596728520@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2020-08-06 15:48:51 | Re: recovering from "found xmin ... from before relfrozenxid ..." |
| Previous Message | Tom Lane | 2020-08-06 14:42:10 | Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689) |