Re: [REVIEW] Re: Compression of full-page-writes

From: Rahila Syed <rahilasyed90(at)gmail(dot)com>
To: Rahila Syed <rahilasyed(dot)90(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Date: 2014-11-04 05:03:54
Message-ID: CAH2L28sRXYh35nhAy_3RuOdRu=YzM61dpEUmObZkr+2v2TH-Gg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello ,

Please find updated patch with the review comments given above implemented.
The compressed data now includes all backup blocks and their headers except
the header of first backup block in WAL record. The first backup block
header in WAL record is used to store the compression information. This is
done in order to avoid adding compression information in WAL record header.

Memory allocation on SIGHUP in autovacuum is remaining. Working on it.

Thank you,
Rahila Syed

On Tue, Oct 28, 2014 at 8:51 PM, Rahila Syed <rahilasyed(dot)90(at)gmail(dot)com>
wrote:

>
> >>>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.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

Attachment Content-Type Size
compress_fpw_v3.patch application/octet-stream 31.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Feng Tian 2014-11-04 06:30:41 Re: Let's drop two obsolete features which are bear-traps for novices
Previous Message Noah Misch 2014-11-04 04:45:35 Re: TAP test breakage on MacOS X