> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@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.
+1
The other downside is that the response time of transactions may degrade when they have to wait for a new WAL segment
tobe created. Tha might pop up as occasional slow or higher maximum response time, which is a mystery to users. Maybe
it'stime 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.
+1
> 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
> series.
I'm not sure about this. I know (many or not) users use continuous archiving with archive_command and archive_timeout
forbackups, and don't want to use streaming replication, because the system is not worth the cost and trouble of HA. I
heardfrom a few users that they were surprised when they knew that PostgreSQL generates WAL even when no update
transactionis happening. Is this still true?
Regards
Takayuki Tsunakawa
