Re: Proposing pg_hibernate - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proposing pg_hibernate
Date
Msg-id CAA4eK1LUmOddgKWJkLsDR1_XATtHh8pAMoNWTXjirc7PjssAPA@mail.gmail.com
Whole thread Raw
In response to Re: Proposing pg_hibernate  (Gurjeet Singh <gurjeet@singh.im>)
Responses Re: Proposing pg_hibernate  (Gurjeet Singh <gurjeet@singh.im>)
List pgsql-hackers
On Thu, Jun 12, 2014 at 9:31 AM, Gurjeet Singh <gurjeet@singh.im> wrote:
>
> I don't have intimate knowledge of recovery but I think the above
> assessment of recovery's operations holds true. If you still think
> this is a concern, can you please provide a bit firm example using
> which I can visualize the problem you're talking about.

Okay, let me try with an example:

Assume No. of shared buffers = 5
Before Crash:

1. Pages in shared buffers numbered 3, 4, 5 have write operations
    performed on them, followed by lot of reads which makes their
    usage_count as 5.
2. Write operation happened on pages in shared buffers numbered
    1, 2. Usage_count of these buffers is 1.
3. Now one read operation needs some different pages and evict
    pages in shared buffers numbered 1 and 2 and read the required
    pages, so buffers 1 and 2 will have usage count as 1.
4. At this moment shutdown initiated.
5. Bgwriter saved just buffers 1 and 2 and crashed.

After Crash:

1. Recovery will read in pages on which operations happened in
step-1 and 2 above.
2. Buffer loader (pg_hibernator) will load buffers on which operations
happened in step-3, so here it might needs to evict buffers which are
corresponding to buffers of step-1 before crash.  So what this
essentially means is that pg_hibernator can lead to eviction of more
useful pages.
 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Add CREATE support to event triggers
Next
From: Fabien COELHO
Date:
Subject: Re: make check For Extensions