pgsql: Remove reindex_catalog test from test schedules.

2019-05-05 Thread Andres Freund
Remove reindex_catalog test from test schedules. As the test currently causes occasional deadlocks (due to the schema cleanup from previous sessions potentially still running), and the patch from f912d7dec2 has gotten a fair bit of buildfarm coverage, remove the test from the test schedules. There

pgsql: Remove reindex_catalog test from test schedules.

2019-05-05 Thread Andres Freund
Remove reindex_catalog test from test schedules. As the test currently causes occasional deadlocks (due to the schema cleanup from previous sessions potentially still running), and the patch from f912d7dec2 has gotten a fair bit of buildfarm coverage, remove the test from the test schedules. There

pgsql: Remove reindex_catalog test from test schedules.

2019-05-05 Thread Andres Freund
Remove reindex_catalog test from test schedules. As the test currently causes occasional deadlocks (due to the schema cleanup from previous sessions potentially still running), and the patch from f912d7dec2 has gotten a fair bit of buildfarm coverage, remove the test from the test schedules. There

pgsql: Remove reindex_catalog test from test schedules.

2019-05-05 Thread Andres Freund
Remove reindex_catalog test from test schedules. As the test currently causes occasional deadlocks (due to the schema cleanup from previous sessions potentially still running), and the patch from f912d7dec2 has gotten a fair bit of buildfarm coverage, remove the test from the test schedules. There

pgsql: Remove reindex_catalog test from test schedules.

2019-05-05 Thread Andres Freund
Remove reindex_catalog test from test schedules. As the test currently causes occasional deadlocks (due to the schema cleanup from previous sessions potentially still running), and the patch from f912d7dec2 has gotten a fair bit of buildfarm coverage, remove the test from the test schedules. There

Re: pgsql: MSVC: Build ~35% faster by calling dumpbin just once per directo

2019-05-05 Thread Noah Misch
On Sun, May 05, 2019 at 06:13:47PM -0400, Tom Lane wrote: > Noah Misch writes: > > MSVC: Build ~35% faster by calling dumpbin just once per directory. > > I happened to notice that dory seems to have gotten no benefit at > all from this patch, although the speed change is very apparent > on some

Re: pgsql: MSVC: Build ~35% faster by calling dumpbin just once per directo

2019-05-05 Thread Tom Lane
Noah Misch writes: > MSVC: Build ~35% faster by calling dumpbin just once per directory. I happened to notice that dory seems to have gotten no benefit at all from this patch, although the speed change is very apparent on some other MSVC critters such as whelk and woodlouse. Puzzling.

pgsql: Bring pg_nextoid()'s error messages into line with message style

2019-05-05 Thread Tom Lane
Bring pg_nextoid()'s error messages into line with message style guide. Noticed while reviewing nearby code. Given all the disclaimers about this not being meant as user-facing code, I wonder whether we should make these non-translatable? But in any case there's little excuse for them not to be

pgsql: Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.

2019-05-05 Thread Tom Lane
Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/69fc9430b892c737efa86e70fde7b4fd43974b10 Modified Files -- doc/src/sgml/release-11.sgml | 11 ++- 1 file changed, 6 insertions(+), 5 delet

pgsql: Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.

2019-05-05 Thread Tom Lane
Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0b41329a3a539c879e0c6731a0830778338777ed Modified Files -- doc/src/sgml/release-9.5.sgml | 379 ++ 1 file

pgsql: Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.

2019-05-05 Thread Tom Lane
Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f729175259f59d4a396a3c0dd19cc87ad4ccf4aa Modified Files -- doc/src/sgml/release-9.6.sgml | 393 ++ 1 file

pgsql: Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.

2019-05-05 Thread Tom Lane
Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22. Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/21de9ae15935c7bd5a40aeb1b93242cc1da446cb Modified Files -- doc/src/sgml/release-9.4.sgml | 336 ++ 1 file

pgsql: Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22.

2019-05-05 Thread Tom Lane
Release notes for 11.3, 10.8, 9.6.13, 9.5.17, 9.4.22. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1bf4858f86343ce102c8baf8ed79fbb4057645ab Modified Files -- doc/src/sgml/release-10.sgml | 509 +++ 1 file

pgsql: Add check for syscache lookup failure in update_relispartition()

2019-05-05 Thread Tom Lane
Add check for syscache lookup failure in update_relispartition(). Omitted in commit 05b38c7e6 (though it looks like the original blame belongs to 9e9befac4). A failure is admittedly unlikely, but if it did happen, SIGSEGV is not the approved method of reporting it. Per Coverity. Back-patch to v

pgsql: Fix style violations in syscache lookups.

2019-05-05 Thread Tom Lane
Fix style violations in syscache lookups. Project style is to check the success of SearchSysCacheN and friends by applying HeapTupleIsValid to the result. A tiny minority of calls creatively did it differently. Bring them into line with the rest. This is just cosmetic, since HeapTupleIsValid is

pgsql: Fix style violations in syscache lookups.

2019-05-05 Thread Tom Lane
Fix style violations in syscache lookups. Project style is to check the success of SearchSysCacheN and friends by applying HeapTupleIsValid to the result. A tiny minority of calls creatively did it differently. Bring them into line with the rest. This is just cosmetic, since HeapTupleIsValid is

pgsql: Add check for syscache lookup failure in update_relispartition()

2019-05-05 Thread Tom Lane
Add check for syscache lookup failure in update_relispartition(). Omitted in commit 05b38c7e6 (though it looks like the original blame belongs to 9e9befac4). A failure is admittedly unlikely, but if it did happen, SIGSEGV is not the approved method of reporting it. Per Coverity. Back-patch to v