Re: Upgrade/Downgrade
От | Achilleas Mantzios |
---|---|
Тема | Re: Upgrade/Downgrade |
Дата | |
Msg-id | 2bb082bc-9795-4bfe-f9c5-a0789b8b4c4e@matrix.gatewaynet.com обсуждение исходный текст |
Ответ на | Re: Upgrade/Downgrade (Nikolay Samokhvalov <samokhvalov@gmail.com>) |
Список | pgsql-general |
On 23/08/2018 22:40, Nikolay Samokhvalov wrote:
yes this is true for scripts, monitoring, but for app? I doubt many apps depend on wal/lsn related functions.On Thu, Aug 23, 2018 at 11:44 AM Joshua D. Drake <jd@commandprompt.com> wrote:On 08/23/2018 04:47 AM, Achilleas Mantzios wrote:
> On 23/08/2018 14:30, Sonam Sharma wrote:
>> No, I didn't. The version is not compatible with application, so need
>> to downgrade it
>
> Have you tried to tweak postgresql.conf ?
> What do you mean is not compatible? What's the problem?
My guess would be that they have a vendor supported application that is
*only* supported on 9.5. I run into this more often than I like.Same story.
I suppose it's related (at least partially) xlog->wal and **_location->**_lsn renamings in function names (full list made in Postgres 10: https://wiki.postgresql.org/wiki/New_in_postgres_10#Renaming_of_.22xlog.22_to_.22wal.22_Globally_.28and_location.2Flsn.29)Those 10's changes are really painful.I wish there were be some grace period, say 2-3 years, when both pg*_xlog_* function names would also work as aliases for pg*_wal_**.
BTW, if the reason of downgrading is really related only these renamings, it might be less stressful just to create function aleases, like:create function pg_catalog.pg_last_xlog_receive_location() returns pg_lsn as $$select pg_current_wal_lsn();$$ language sql;+ granting proper permissions to specified DB roles, where needed.Of course, it's hacky and should be only as a temporary solution until the app is adjusted to support Postgres 10+.But it gives an ability to have all good things added to Postgres 9.6 and 10.
-- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt
В списке pgsql-general по дате отправления: