From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Subject: | Re: Recovery inconsistencies, standby much larger than primary |
Date: | 2014-02-12 21:33:31 |
Message-ID: | 20918.1392240811@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> What I think we probably want to do is forcibly cause the target page
> to exist, using a P_NEW loop like what I committed, and then decide
> on the basis of whether it's all-zeroes whether to consider it invalid
> or not. This seems sane on the grounds that it's just the extension
> to the page level of the existing policy of creating the file whether
> it existed or not. It could only result in a large amount of wasted
> work if the passed-in target block is insane --- but since we got it
> out of a CRC-checked WAL record, I think it's safe to not worry too
> much about that.
Like the attached. A possible complaint is that if the WAL sequence
contains updates against large relations that are later dropped,
this will waste time and disk space replaying those updates as best
it can. Doesn't seem like that's a case to optimize for, however.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
get-the-mode-behavior-right.patch | text/x-diff | 5.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2014-02-12 21:34:47 | Re: Terminating pg_basebackup background streamer |
Previous Message | Andres Freund | 2014-02-12 21:30:17 | Re: narwhal and PGDLLIMPORT |