Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Дата
Msg-id CABAq_6HtzPS=Q=SnvYCpPypACG3ahxoesNmytJSa2GJahsqYCA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Список pgsql-hackers
On Mon, Aug 6, 2018 at 12:13 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Do you mean "incorrect results", or just "unstable results"?
> If the former, what's incorrect about it?

Incorrect, as in "the results are not sorted by type name." Here's an
example ordering that we saw -- but note that you won't be able to
repro since it relies on the Greenplum bug I mentioned.

...
pg_catalog.xlogloc_ops
public._tmp_table
public.a
public.a_star
<null>.abstime date
<null>.abstime int4
<null>.abstime time
<null>.abstime timestamp
<null>.abstime timestamptz
gporca_faults.foo
...

You can see the inversion between public._tmp_table (which is TABLE
DATA) and gporca_faults.foo (which is also TABLE DATA). I can try to
work on a Postgres-specific test case if you'd like, but since the
root cause is that we're not defining a valid ordering, quicksort may
or may not behave consistently for test purposes. We got "lucky" here;
otherwise we'd never have noticed.

--Jacob


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_dump: sortDumpableObjectsByTypeName() doesn't always do that
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Standby trying "restore_command" before local WAL