On Thu, Sep 28, 2023 at 09:36:37AM +0900, Michael Paquier wrote:
> If none, I propose to apply the patch to switch to palloc() instead of
> palloc_extended(NO_OOM) in this code around the beginning of next
> week, down to 12.
Done down to 12 as of 6b18b3fe2c2f, then.
--
Michael
signature.asc
Des
On Tue, Sep 26, 2023 at 06:28:30PM -0700, Noah Misch wrote:
> On Wed, Sep 27, 2023 at 11:06:37AM +1300, Thomas Munro wrote:
>> What Michael wants to do now is remove the 2004-era assumption that
>> malloc failure implies bogus data. It must be pretty unlikely in a 64
>> bit world with overcommitte
On Wed, Sep 27, 2023 at 11:06:37AM +1300, Thomas Munro wrote:
> On Tue, Sep 26, 2023 at 8:38 PM Michael Paquier wrote:
> > Thoughts and/or comments are welcome.
>
> I don't have an opinion yet on your other thread about making this
> stuff configurable for replicas, but for the simple crash recov
On Wed, Sep 27, 2023 at 11:06:37AM +1300, Thomas Munro wrote:
> I don't have an opinion yet on your other thread about making this
> stuff configurable for replicas, but for the simple crash recovery
> case shown here, hard failure makes sense to me.
Also, if we conclude that we're OK with just fa
On Tue, Sep 26, 2023 at 8:38 PM Michael Paquier wrote:
> Thoughts and/or comments are welcome.
I don't have an opinion yet on your other thread about making this
stuff configurable for replicas, but for the simple crash recovery
case shown here, hard failure makes sense to me.
Here are some inte
Hi all,
(Thomas in CC.)
Now that becfbdd6c1c9 has improved the situation to detect the
difference between out-of-memory and invalid WAL data in WAL, I guess
that it is time to tackle the problem of what we should do when
reading WAL records bit fail on out-of-memory.
To summarize, currently the W
