From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | linuxhippy(at)gmail(dot)com |
Subject: | BUG #18474: wal_writer_delay limited to arbitrary value of 10s |
Date: | 2024-05-22 18:11:31 |
Message-ID: | 18474-e2f89fa17c6ae72e@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 18474
Logged by: Clemens Eisserer
Email address: linuxhippy(at)gmail(dot)com
PostgreSQL version: 16.3
Operating system: Linux
Description:
wal_writer_delay has a hard-coded limit of 10000ms, however the limit seems
artificial because depending on the type of workload 10s are either very
long of very short.
As far as I know wal_writer_delay is the only option for scanrios where the
durability of recently commited data is not that important, yet
database-corruption - as it can happen with fsync=off - should be avoided.
E.g. I have postgresql running on a raspberry pi storing sensor data, and
every 250ms an additional row with sensor data is written. Because of
fsync=on I have huge amounts of write-amplification (gigabytes), and it
would be great if it batching e.g. 10min of sensor-data would be possible.
From | Date | Subject | |
---|---|---|---|
Next Message | Clemens Eisserer | 2024-05-22 18:22:12 | Re: Re: BUG #18471: Possible JIT memory leak resulting in signal 11:Segmentation fault on ARM |
Previous Message | Melanie Plageman | 2024-05-22 16:57:26 | Re: relfrozenxid may disagree with row XIDs after 1ccc1e05ae |