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 по дате отправления: