Re: Make pg_checksums complain if compiled BLCKSZ and data folder'sblock size differ
От | Fabien COELHO |
---|---|
Тема | Re: Make pg_checksums complain if compiled BLCKSZ and data folder'sblock size differ |
Дата | |
Msg-id | alpine.DEB.2.21.1903170857440.2506@lancre обсуждение исходный текст |
Ответ на | Re: Make pg_checksums complain if compiled BLCKSZ and data folder'sblock size differ (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Make pg_checksums complain if compiled BLCKSZ and data folder'sblock size differ
|
Список | pgsql-hackers |
> Something like "%s: database folder is incompatible" for the first > line sounds kind of better per the feedback gathered. And then on the > second line: > "The database cluster was initialized with block size %u, but > pg_checksums was compiled with block size %u." Ok. "%s" progname instead of "pg_checksums", or just "the command"? I'm not sure that prefixing the two lines with the comment line is very elegant, I'd suggest to put spaces, and would still try to shorten the second sentence, maybe: %s: incompatible database cluster of block size %u, while the command is compiled for block size %u. >> I think it would be better to adapt the checksum computation, but this is >> indeed non trivial because of the way the BLCKSZ constant is hardwired into >> type declarations. > > That's actually the possibility I was pointing out upthread. Yes, I was expressing my agreement. > I am not sure that the use cases are worth the effort though. Indeed, not for "pg_checksums" only. A few years I considered to have an dynamic initdb-set block size, but BLCKSZ is used a lot as a constant for struct declaration and to compute other constants, so that was a lot of changes. I think it would be worth the effort because the current page size is suboptimal especially on SSD where 4 KiB would provide over 10% better performance for OLTP load. However, having to recompile to change it is a pain and not very package friendly. -- Fabien.
В списке pgsql-hackers по дате отправления: