On Thu, Aug 23, 2018 at 11:44 AM Joshua D. Drake <j...@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.

Reply via email to