From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_basebackup failure after setting default_table_access_method option |
Date: | 2019-06-11 05:33:37 |
Message-ID: | 20190611053337.klqzlsk65e32o3b7@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-06-10 16:37:33 +0900, Michael Paquier wrote:
> On Sat, Jun 08, 2019 at 08:26:07AM -0700, Andres Freund wrote:
> > We have plenty other callbacks that aren't bulletproof, so I don't think
> > this is really something we should / can change in isolation here.
>
> Good point. I was looking at the check callbacks in guc.c for similar
> changes, and missed these. After testing, only these parameters fail
> with the same error:
> - default_table_access_method
> - default_text_search_config
>
> For the second one it's much older.
Yea, that's where the default_table_access_method code originates from,
obviously. I'll backpatch the default_text_search_config fix separately
(and first).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-06-11 05:45:04 | Re: [pg_rewind] cp: cannot stat ‘pg_wal/RECOVERYHISTORY’: No such file or directory |
Previous Message | Andres Freund | 2019-06-11 05:09:59 | Re: pgbench rate limiting changes transaction latency computation |