> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas
> Considering those three factors, I think we should consider pushing the
> default value up somewhat higher for v10. Reverting to the 64MB size that
> we had prior to 47937403676d913c0e740eec6b85113865c6c8ab
> sounds pretty reasonable.
The other downside is that the response time of transactions may degrade when
they have to wait for a new WAL segment to be created. Tha might pop up as
occasional slow or higher maximum response time, which is a mystery to users.
Maybe it's time to use posix_fallocate() to create WAL segments.
> Possibly it would make sense for this to be configurable at initdb time
> instead of requiring a recompile; we probably don't save any significant
> number of cycles by compiling this into the server.
> 3. archive_timeout is no longer a frequently used option. Obviously, if
> you are frequently archiving partial segments, you don't want the segment
> size to be too large, because if it is, each forced segment switch
> potentially wastes a large amount of space (and bandwidth).
> But given streaming replication and pg_receivexlog, the use case for
> archiving partial segments is, at least according to my understanding, a
> lot narrower than it used to be. So, I think we don't have to worry as
> much about keeping forced segment switches cheap as we did during the 8.x
I'm not sure about this. I know (many or not) users use continuous archiving
with archive_command and archive_timeout for backups, and don't want to use
streaming replication, because the system is not worth the cost and trouble of
HA. I heard from a few users that they were surprised when they knew that
PostgreSQL generates WAL even when no update transaction is happening. Is this
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: