Re: Fsync request queue

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fsync request queue
Date: 2018-04-25 06:19:52
Message-ID: e9a01f61-2ecd-e194-7bbf-d84685122f33@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24/04/18 21:00, Andres Freund wrote:
> Right now if the queue is full and can't be compacted we end up
> fsync()ing on every single write, rather than once per checkpoint
> afaict. That's a fairly horrible.
>
> For the case that there's no space in the map, I'd suggest to just do
> 10% or so of the fsync in the poor sod of a process that finds no
> space. That's surely better than constantly fsyncing on every single
> write.

Clever idea. In principle, you could do that even with the current
queue, without changing it to a hash table.

Is this a problem in practice, though? I don't remember seeing any
reports of the fsync queue filling up, after we got the code to compact
it. I don't know if anyone has been looking for that, so that might also
explain the absence of reports, though.

> The fsync request queue often is fairly large. 20 bytes for each
> shared_buffers isn't a neglebible overhead.

Ok, I guess that's a reason to do this, even if the current system works.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nick Dro 2018-04-25 06:21:25 Racing DEADLOCK on PostgreSQL 9.3
Previous Message Christophe Pettus 2018-04-25 05:34:35 Re: Built-in connection pooling