Re: [REVIEW] Re: Compression of full-page-writes
От | Rahila Syed |
---|---|
Тема | Re: [REVIEW] Re: Compression of full-page-writes |
Дата | |
Msg-id | 1414509702440-5824613.post@n5.nabble.com обсуждение исходный текст |
Ответ на | Re: [REVIEW] Re: Compression of full-page-writes (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: [REVIEW] Re: Compression of full-page-writes
|
Список | pgsql-hackers |
>>>Do we release the buffers for compressed data when fpw is changed from "compress" to "on"? >> The current code does not do this. >Don't we need to do that? Yes this needs to be done in order to avoid memory leak when compression is turned off at runtime while the backend session is running. >You don't need to make the processes except the startup process allocate >the memory for uncompressedPages when fpw=on. Only the startup process >uses it for the WAL decompression I see. fpw != on check can be put at the time of memory allocation of uncompressedPages in the backend code . And at the time of recovery uncompressedPages can be allocated separately if not already allocated. >BTW, what happens if the memory allocation for uncompressedPages for >the recovery fails? The current code does not handle this. This will be rectified. >Which would prevent the recovery at all, so PANIC should >happen in that case? IIUC, instead of reporting PANIC , palloc can be used to allocate memory for uncompressedPages at the time of recovery which will throw ERROR and abort startup process in case of failure. Thank you, Rahila Syed -- View this message in context: http://postgresql.1045698.n5.nabble.com/Compression-of-full-page-writes-tp5769039p5824613.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
В списке pgsql-hackers по дате отправления: