Re: Detect supported SET parameters when pg_restore is run

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Detect supported SET parameters when pg_restore is run
Дата
Msg-id 2739.1475010752@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Detect supported SET parameters when pg_restore is run  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Ответы Re: Detect supported SET parameters when pg_restore is run  (Vitaly Burovoy <vitaly.burovoy@gmail.com>)
Re: Detect supported SET parameters when pg_restore is run  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Vitaly Burovoy <vitaly.burovoy@gmail.com> writes:
> On 9/27/16, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not exactly convinced that you did.  There's only one copy of
>> Archive->remoteVersion, and you're overwriting it long before the
>> dump process is over.

> It does not seem that I'm "overwriting it long before the dump process
> is over"...

There's a lot that happens during RestoreArchive.  Even if none of it
inspects remoteVersion today, I do not think that's a safe assumption to
make going forward.  The easiest counterexample is that this very bit of
code you want to add does so.  I really do not want to get into a design
that says "remoteVersion means the source server version until we reach
RestoreArchive, and the target version afterwards".  That way madness
lies.  If we're going to try altering the emitted SQL based on target
version, let's first create a separation between those concepts; otherwise
I will bet that we add more bugs than we remove.

(The other thing I'd want here is a --target-version option so that
you could get the same output alterations in pg_dump or pg_restore to
text.  Otherwise it's nigh undebuggable, and certainly much harder
to test than it needs to be.)
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: to_date_valid()
Следующее
От: David Steele
Дата:
Сообщение: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress