From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Make relcache init write errors not be fatal |
Date: | 2018-12-23 01:49:58 |
Message-ID: | CAMkU=1zSY40F45jyXF_3x2yjzk2qFz00pzCEFAT+7bfwCPk7mQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
After running a testing server out of storage, I tried to track down why it
was so hard to get it back up again. (Rather than what I usually do which
is just throwing it away and making the test be smaller).
I couldn't start a backend because it couldn't write the relcache init file.
I found this comment, but it did not carry its sentiment to completion:
/*
* We used to consider this a fatal error, but we might as well
* continue with backend startup ...
*/
With the attached patch applied, I could at least get a backend going so I
could drop some tables/indexes and free up space.
I'm not enamoured with the implementation of passing a flag down
to write_item, but it seemed better than making write_item return an error
code and then checking the return status in a dozen places. Maybe we could
turn write_item into a macro, so the macro can implement the "return" from
the outer function directly?
Cheers,
Jeff
Attachment | Content-Type | Size |
---|---|---|
relcache_init_v1.patch | application/octet-stream | 4.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-12-23 01:54:15 | Re: Make relcache init write errors not be fatal |
Previous Message | Heikki Linnakangas | 2018-12-23 00:45:05 | Re: Speeding up text_position_next with multibyte encodings |