Re: pgsql: Silence perlcritic warning about missing return.

perlcritic coverage. Someone complained that we wouldn't know when we caused a breach of the policy, so I fixed that :-) cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Lower privilege level of programs calling regression_main

Lower privilege level of programs calling regression_main On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth

pgsql: Lower privilege level of programs calling regression_main

Lower privilege level of programs calling regression_main On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth

pgsql: Lower privilege level of programs calling regression_main

Lower privilege level of programs calling regression_main On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth

pgsql: Lower privilege level of programs calling regression_main

Lower privilege level of programs calling regression_main On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth

pgsql: Lower privilege level of programs calling regression_main

Lower privilege level of programs calling regression_main On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth

Re: pgsql: Add TAP tests for pg_verify_checksums

On 10/12/2018 05:52 PM, Andres Freund wrote: On 2018-10-12 17:46:17 -0400, Andrew Dunstan wrote: On 10/12/2018 05:14 PM, Andrew Dunstan wrote: On 10/11/2018 08:17 PM, Michael Paquier wrote: Add TAP tests for pg_verify_checksums All options available in the utility get coverage: - Tests

Re: pgsql: Add TAP tests for pg_verify_checksums

On 10/12/2018 05:14 PM, Andrew Dunstan wrote: On 10/11/2018 08:17 PM, Michael Paquier wrote: Add TAP tests for pg_verify_checksums All options available in the utility get coverage: - Tests with disabled page checksums. - Tests with enabled test checksums. - Emulation of corruption

Re: pgsql: Add TAP tests for pg_verify_checksums

://postgr.es/m/20181005012645.ge1...@paquier.xyz We have some failures here on Windows. I suspect we might need to do a little more surgery like was done in commit efd7f8e36553cd32e445061cbbc80d32028f4248 cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL

Re: pgsql: Remove deprecated abstime, reltime, tinterval datatypes.

DATE pg_catalog.pg_class SET relfrozenxid = '2643', relminmxid = '1' WHERE oid = '"public"."abstime_tbl"'::pg_catalog.regclass; cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Don't build static libraries on Cygwin

Don't build static libraries on Cygwin Cygwin has been building and linking against static libraries. Although a bug this has been relatively harmless until now, when this has caused errors due to changes in the way we build certain libraries. So this patch makes things work the way we always

Re: pgsql: Build src/port files as a library with -fPIC, and use that in li

it. If the buildfarm doesn't expose fatal problems with the approach, I'll extend it to the other cases. Looks like we have a bunch of failures, including prairiedog. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA

pgsql: Fast default trigger and expand_tuple fixes

Fast default trigger and expand_tuple fixes Ensure that triggers get properly filled in tuples for the OLD value. Also fix the logic of detecting missing null values. The previous logic failed to detect a missing null column before the first missing column with a default. Fixing this has

Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi

On 09/17/2018 12:13 PM, Tom Lane wrote: Andrew Dunstan writes: On 09/17/2018 10:48 AM, Tom Lane wrote: We've got a bit of a timing problem because we want to wrap 11beta4/rc1 (still TBD) in a few hours. I'll take a look and see if I can push a quick fix before that. When you do I'll

Re: pgsql: Allow concurrent-safe open() and fopen() in frontend code for Wi

of a timing problem because we want to wrap 11beta4/rc1 (still TBD) in a few hours. I'll take a look and see if I can push a quick fix before that. When you do I'll start a bowerbird run to check it. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development

pgsql: On all Windows platforms, not just Cygwin, use _timezone and _tz

On all Windows platforms, not just Cygwin, use _timezone and _tzname. Back-patch commit 868628e4f into the 9.5 branch, so that we can support building that branch with Visual Studio 2015. This patch itself could go further back, but other VS2015 patches such as 0fb54de9a and c8e81afc6 were only

pgsql: On all Windows platforms, not just Cygwin, use _timezone and _tz

On all Windows platforms, not just Cygwin, use _timezone and _tzname. Back-patch commit 868628e4f into the 9.5 branch, so that we can support building that branch with Visual Studio 2015. This patch itself could go further back, but other VS2015 patches such as 0fb54de9a and c8e81afc6 were only

pgsql: Support building with Visual Studio 2015

Support building with Visual Studio 2015 Adjust the way we detect the locale. As a result the minumum Windows version supported by VS2015 and later is Windows Vista. Add some tweaks to remove new compiler warnings. Remove documentation references to the now obsolete msysGit. Michael Paquier,

pgsql: Support building with Visual Studio 2015

Support building with Visual Studio 2015 Adjust the way we detect the locale. As a result the minumum Windows version supported by VS2015 and later is Windows Vista. Add some tweaks to remove new compiler warnings. Remove documentation references to the now obsolete msysGit. Michael Paquier,

pgsql: Support building with Visual Studio 2017

Support building with Visual Studio 2017 Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich Backpatch to 9.6 Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f6c268c4894bba9d1bbc5338407febaaad0dbd04 Modified Files --

pgsql: Support building with Visual Studio 2017

Support building with Visual Studio 2017 Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich Now backpatched to 9.4 and 9.3 Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/48c978f3ed20961a69189eab2e26e0fa0f54986f Modified Files --

pgsql: Support building with Visual Studio 2017

Support building with Visual Studio 2017 Haribabu Kommi, reviewed by Takeshi Ideriha and Christian Ullrich Now backpatched to 9.4 and 9.3 Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/19acfd6528bcbf55ad996397177a1f2a16001c25 Modified Files --

pgsql: Revert changes in execMain.c from commit 16828d5c0273b

Revert changes in execMain.c from commit 16828d5c0273b These changes were put in at some stage of the development process, but are unnecessary and should not have made it into the final patch. Mea culpa. Per gripe from Andreas Freund Backpatch to REL_11_STABLE Branch -- REL_11_STABLE

pgsql: Revert changes in execMain.c from commit 16828d5c0273b

Revert changes in execMain.c from commit 16828d5c0273b These changes were put in at some stage of the development process, but are unnecessary and should not have made it into the final patch. Mea culpa. Per gripe from Andreas Freund Backpatch to REL_11_STABLE Branch -- master Details

pgsql: Remove SGMLism from commit 2d36a5e9dab6

Remove SGMLism from commit 2d36a5e9dab6 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ed0cfde2e7fca2c129e560491bbb15331f2ff2f4 Modified Files -- doc/src/sgml/auto-explain.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: Provide a log_level setting for auto_explain

Provide a log_level setting for auto_explain Up to now the log level has been hardcoded at LOG. A new auto_explain.log_level setting allows that to be modified. Discussion: https://postgr.es/m/CAPPfruyZh+snR2AdmutrA0B_caj=ywzklqxutzynjjcaq_w...@mail.gmail.com Tom Dunstan and Andrew Dunstan

Re: pgsql: Use access() to check file existence in GetNewRelFileNode()

On 07/08/2018 06:00 AM, Michael Paquier wrote: Reviewed-by: Peter Eisentraut, Michael Paquier I think if you're the committer you're assumed to have reviewed the patch :-) cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support

pgsql: Print DEBUG2 like that rather than as DEBUG

Print DEBUG2 like that rather than as DEBUG DEBUG is an alias for DEBUG2, but we want DEBUG2 to show in the settings no matter how it was spelled. Takeshi Ideriha Discussion: https://postgr.es/m/4E72940DA2BF16479384A86D54D0988A5678EC03@G01JPEXMBKW04 Branch -- master Details ---

pgsql: Use more modern instructions for creating a new dev cycle

Use more modern instructions for creating a new dev cycle Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/56b4da8c9d11f685f1fe2e11cf015e850913b6b8 Modified Files -- src/tools/RELEASE_CHANGES | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-)

pgsql: perltidy run prior to branching

perltidy run prior to branching Branches REL_11_STABLE master Details --- https://git.postgresql.org/pg/commitdiff/d8421390996dcd762383a28e57d1f3f16cc5f76f Modified Files -- src/bin/pg_basebackup/t/010_pg_basebackup.pl | 5 - src/test/ssl/ServerSetup.pm

pgsql: Update typedefs list

Update typedefs list Branches REL_11_STABLE master Details --- https://git.postgresql.org/pg/commitdiff/2c64d200484c40c1bfbd532bf140bea672f267a1 Modified Files -- src/tools/pgindent/typedefs.list | 2 ++ 1 file changed, 2 insertions(+)

pgsql: pgindent run prior to branching

pgindent run prior to branching Branches REL_11_STABLE master Details --- https://git.postgresql.org/pg/commitdiff/1e9c8580904625576871eeb2efec7f04d4c3bc1c Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 19 +-

pgsql: Stamp HEAD as 12devel

Stamp HEAD as 12devel Let the hacking begin ... Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/feced1387f07c3fa6c47d36a68962750e6065486 Modified Files -- configure| 18 +- configure.in | 2 +-

pgsql: Mark binary_upgrade_set_missing_value as parallel_unsafe

Mark binary_upgrade_set_missing_value as parallel_unsafe per buildfarm. Bump catalog version again although in practice nobody is going to use this in a parallel query. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/123efbccea694626b36ad952086d883fa7469aa9

Re: pgsql: Allow for pg_upgrade of attributes with missing values

On 06/22/2018 11:03 PM, Tom Lane wrote: Andrew Dunstan writes: Allow for pg_upgrade of attributes with missing values Buildfarm results suggest that binary_upgrade_set_missing_value should have been marked proparallel => 'u'. Argh! I'll fix it in the morning, along with add

pgsql: Allow for pg_upgrade of attributes with missing values

Allow for pg_upgrade of attributes with missing values Commit 16828d5c02 neglected to do this, so upgraded databases would silently get null instead of the specified default in rows without the attribute defined. A new binary upgrade function is provided to perform this and pg_dump is adjusted

pgsql: Exclude files in .git from list of perl files

Exclude files in .git from list of perl files The .git directory might contain perl files, as hooks, for example. Since we have no control over these they should be excluded from things like our perlcritic checks. Per offline report from Mike Blackwell. Branch -- master Details ---

pgsql: Move perlcritic files to new perlcheck directory

Move perlcritic files to new perlcheck directory Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/85dd744a70d167ca86e83ea38f5ac3e1449bb028 Modified Files -- src/tools/{pgperlcritic => perlcheck}/perlcriticrc | 2 +- src/tools/{pgperlcritic =>

pgsql: Fix compile-time warnings on all perl code

Fix compile-time warnings on all perl code This patch does two things. First, it silences a number of compile-time warnings in the msvc tools files, mainly those due to the fact that in some cases we have more than one package per file. Second it supplies a dummy Perl library with just enough of

pgsql: Return a value from Install.pm's lcopy function

Return a value from Install.pm's lcopy function Commit 3a7cc727c was a little over eager about adding an explicit return to this function, whose value is checked in most call sites. This change reverses that and returns the expected value explicitly. It also adds a check to the one call site

pgsql: Avoid use of unportable hex constant in convutils.pm

Avoid use of unportable hex constant in convutils.pm Discussion: https://postgr.es/m/5a6d6de8-cff8-1ffb-946c-ccf381800...@2ndquadrant.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f963f80970641246cbba172e197068193ad65189 Modified Files --

pgsql: Don't fall off the end of perl functions

Don't fall off the end of perl functions This complies with the perlcritic policy Subroutines::RequireFinalReturn, which is a severity 4 policy. Since we only currently check at severity level 5, the policy is raised to that level until we move to level 4 or lower, so that any new infringements

pgsql: Don't force a blank line before comments in perl code

Don't force a blank line before comments in perl code Suggestion from Bruce Momjian Discussion: https://postgr.es/m/20180525190445.ga2...@momjian.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8a56ff484808e9c05df9656cf4244229e8c7960d Modified Files

pgsql: Preserve information on use of git-external-diff

Preserve information on use of git-external-diff Now that the Working with git wiki page no longer suggests producing context diffs, we should preserve the information on how to use git-external-diff for those people who want to view context format diffs. The most obvious place is in the script

pgsql: Prevent possibly spurious error when running perl -cw

Prevent possibly spurious error when running perl -cw Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3dacd9bf32873c80045a2b758d64c031d70dac83 Modified Files -- src/tools/msvc/Mkvcbuild.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

pgsql: perltidy some recent code changes before changing perltidy setti

perltidy some recent code changes before changing perltidy settings Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/286bb240e1c8e279efa2d805c7f700abfb771925 Modified Files -- src/backend/catalog/Catalog.pm | 2 +- src/tools/msvc/Install.pm | 10

pgsql: Restrict vertical tightness to parentheses in Perl code

Restrict vertical tightness to parentheses in Perl code The vertical tightness settings collapse vertical whitespace between opening and closing brackets (parentheses, square brakets and braces). This can make data structures in particular harder to read, and is not very consistent with our style

pgsql: Add a script and a config file to run perlcritic

Add a script and a config file to run perlcritic This is similar to what we do to run perltidy. For now we only run at severity level 5. Over time we can improve our perl code and reduce the severity level. Discussion: https://postgr.es/m/86aa2a3a-0c68-21fb-9560-84ad6914d...@2ndquadrant.com

pgsql: Clean up some perlcritic warnings

Clean up some perlcritic warnings In Catalog.pm, mark eval of a string instead of a block as allowed. Disallow perlcritic completely in Gen_dummy_probes.pl, as it's generated code. Protect a couple of lines in plperl code from perltidy, so that the annotation for perlcritic stays on the same

pgsql: Clear severity 5 perlcritic warnings from vcregress.pl

Clear severity 5 perlcritic warnings from vcregress.pl My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original. Branch -- REL9_6_STABLE Details ---

pgsql: Clear severity 5 perlcritic warnings from vcregress.pl

Clear severity 5 perlcritic warnings from vcregress.pl My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original. Branch -- master Details ---

pgsql: Clear severity 5 perlcritic warnings from vcregress.pl

Clear severity 5 perlcritic warnings from vcregress.pl My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original. Branch -- REL9_4_STABLE Details ---

pgsql: Clear severity 5 perlcritic warnings from vcregress.pl

Clear severity 5 perlcritic warnings from vcregress.pl My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original. Branch -- REL9_3_STABLE Details ---

pgsql: Clear severity 5 perlcritic warnings from vcregress.pl

Clear severity 5 perlcritic warnings from vcregress.pl My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original. Branch -- REL9_5_STABLE Details ---

pgsql: Clear severity 5 perlcritic warnings from vcregress.pl

Clear severity 5 perlcritic warnings from vcregress.pl My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original. Branch -- REL_10_STABLE Details ---

Re: pgsql: Fix precedence problem in new Perl code.

yesterday when looking at it against the buildfarm client code when I got this: Fatal error while critiquing "./run_build.pl": Not an ARRAY reference at /usr/share/perl5/vendor_perl/Perl/Critic/Policy/BuiltinFunctions/ProhibitUselessTopic.pm line 81. Oh, the irony. cheers andrew

Re: pgsql: Provide for testing on python3 modules when under MSVC

On Fri, May 4, 2018 at 7:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Andrew Dunstan <and...@dunslane.net> writes: >> Provide for testing on python3 modules when under MSVC > > The MSVC critters in the buildfarm seem not to like this. > It appears that the three f

Re: pgsql: Provide for testing on python3 modules when under MSVC

> On May 4, 2018, at 7:03 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Andrew Dunstan <and...@dunslane.net> writes: >> Provide for testing on python3 modules when under MSVC > > The MSVC critters in the buildfarm seem not to like this. > Will fix in an hour or two Cheers Andrew

Re: pgsql: Provide for testing on python3 modules when under MSVC

On Fri, May 4, 2018 at 3:58 PM, Andrew Dunstan <and...@dunslane.net> wrote: > Provide for testing on python3 modules when under MSVC > > This should have been done some years ago as promised in commit > c4dcdd0c2. However, better late than never. > > Along the way

pgsql: Provide for testing on python3 modules when under MSVC

Provide for testing on python3 modules when under MSVC This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant

pgsql: Provide for testing on python3 modules when under MSVC

Provide for testing on python3 modules when under MSVC This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant

pgsql: Provide for testing on python3 modules when under MSVC

Provide for testing on python3 modules when under MSVC This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant

pgsql: Provide for testing on python3 modules when under MSVC

Provide for testing on python3 modules when under MSVC This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant

pgsql: Provide for testing on python3 modules when under MSVC

Provide for testing on python3 modules when under MSVC This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant

pgsql: Provide for testing on python3 modules when under MSVC

Provide for testing on python3 modules when under MSVC This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant

pgsql: Allow MSYS as well as MINGW in Msys uname

Allow MSYS as well as MINGW in Msys uname Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is output by Msys. Allow either in pg_upgrade's test.sh. Backpatch to all live branches. Branch -- REL9_4_STABLE Details ---

pgsql: Allow MSYS as well as MINGW in Msys uname

Allow MSYS as well as MINGW in Msys uname Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is output by Msys. Allow either in pg_upgrade's test.sh. Backpatch to all live branches. Branch -- REL_10_STABLE Details ---

pgsql: Allow MSYS as well as MINGW in Msys uname

Allow MSYS as well as MINGW in Msys uname Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is output by Msys. Allow either in pg_upgrade's test.sh. Backpatch to all live branches. Branch -- REL9_3_STABLE Details ---

pgsql: Allow MSYS as well as MINGW in Msys uname

Allow MSYS as well as MINGW in Msys uname Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is output by Msys. Allow either in pg_upgrade's test.sh. Backpatch to all live branches. Branch -- master Details ---

pgsql: Allow MSYS as well as MINGW in Msys uname

Allow MSYS as well as MINGW in Msys uname Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is output by Msys. Allow either in pg_upgrade's test.sh. Backpatch to all live branches. Branch -- REL9_6_STABLE Details ---

pgsql: clean up pg_upgrade tmp_check under MSVC

clean up pg_upgrade tmp_check under MSVC Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bb779006f4e1881de2c80409225e57e3a3e17d40 Modified Files -- src/tools/msvc/clean.bat | 1 + 1 file changed, 1 insertion(+)

pgsql: Ignore file generated during pg_upgrade testing

Ignore file generated during pg_upgrade testing Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0146e32f9f54f8bc556307c4204a404f18c5663b Modified Files -- src/bin/pg_upgrade/.gitignore | 1 + 1 file changed, 1 insertion(+)

Re: pgsql: Fix incorrect handling of join clauses pushed into parameterized

ion. > > Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b23...@proxel.se > > Branch > -- > REL9_6_STABLE > Seems to have broken the buildfarm on 9.6. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Prevent segfault in expand_tuple with no missing values

Prevent segfault in expand_tuple with no missing values Commit 16828d5c forgot to check that it had a set of missing values before trying to retrieve a value from it. An additional query to add coverage for this code is added to the regression test. Per bug report from Andreas Seltenreich.

Re: pgsql: Optimize btree insertions for common case of increasing values

On 04/10/2018 06:33 PM, Peter Geoghegan wrote: > On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan <and...@dunslane.net> wrote: >> Committed with light editing. I didn't put the #define in the .h file - >> it's only used here and that seemed like unnecessary clutter. I m

pgsql: minor comment fixes in nbtinsert.c

minor comment fixes in nbtinsert.c Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8716b264ed845370e33943da93caf424dc3723b7 Modified Files -- src/backend/access/nbtree/nbtinsert.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-)

Re: pgsql: Optimize btree insertions for common case of increasing values

On 04/10/2018 03:30 PM, Peter Geoghegan wrote: > On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee > wrote: >> Hmm. I am a bit confused why we want to mention anything about something >> we're not even considering seriously, let alone any patch or work in that >>

pgsql: Adjustments to the btree fastpath optimization.

Adjustments to the btree fastpath optimization. This optimization was introduced in commit 2b272734. The changes include some additional comments and documentation, and also these more substantive changes: . ensure the optimization is only applied on the leaf node of a tree whose root is on level

Re: pgsql: Allow on-line enabling and disabling of data checksums

On Fri, Apr 6, 2018 at 7:07 PM, Magnus Hagander <mag...@hagander.net> wrote: > > > On Fri, Apr 6, 2018 at 2:03 AM, Andrew Dunstan > <andrew.duns...@2ndquadrant.com> wrote: >> >> On Fri, Apr 6, 2018 at 5:35 AM, Magnus Hagander <mag...@hagander.net

Re: pgsql: Allow on-line enabling and disabling of data checksums

raded cluster and if so enable them on the new cluster via initdb. When we decide on the best fix I will put out a new release. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql: Make fast_default regression tests locale independent

Make fast_default regression tests locale independent Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a437551a228a5099c305d1376188d6926c043724 Modified Files -- src/test/regress/expected/fast_default.out | 2 +- src/test/regress/sql/fast_default.sql

Re: pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

hich probably is just collation related and will stably fail? > > Yeah, magpie is still showing that after the latest commits. > A bit of COLLATE "C" might fix it. > Just testing a fix along those lines now. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.c

Re: pgsql: Add catversion bump missed in 16828d5c0.

On Wed, Mar 28, 2018 at 12:39 PM, Andres Freund <and...@anarazel.de> wrote: > Add catversion bump missed in 16828d5c0. > > Given that pg_attribute changed its layout... Oops. Thanks. cheers andrew -- Andrew Dunstanhttps://www.2ndQuadrant.com PostgreSQL De

pgsql: Fast ALTER TABLE ADD COLUMN with a non-NULL default

argument, allowing it to detect a missing value if there is one. In many cases where it is known that there will not be any (e.g. catalog relations) NULL can be passed for this argument. Andrew Dunstan, heavily modified from an original patch from Serge Rielau. Reviewed by Tom Lane, Andres Freund, Tomas

pgsql: Remove two tests inadvertently added in 2b27273435

Remove two tests inadvertently added in 2b27273435 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1d494b622fa9dfdbd7213f357cd38def0125a322 Modified Files -- src/test/regress/expected/indexing.out | 16 src/test/regress/sql/indexing.sql

pgsql: Optimize btree insertions for common case of increasing values

Optimize btree insertions for common case of increasing values Remember the last page of an index insert if it's the rightmost leaf page. If the next entry belongs on and can fit in the remembered page, insert the new entry there as long as we can get a lock on the page. Otherwise, fall back on

Re: pgsql: Add tests for reinit.c

On Mon, Mar 19, 2018 at 11:33 PM, David Steele <da...@pgmasters.net> wrote: > On 3/19/18 4:15 AM, Andrew Dunstan wrote: >> >> The attached fixes it. We should probably put the function or something >> like it in TestLib.pm, though. The call to pwd is quite tricky - it

pgsql: Don't use an Msys virtual path to create a tablespace

Don't use an Msys virtual path to create a tablespace The new unlogged_reinit recovery tests create a new tablespace using TestLib.pm's tempdir. However, on msys that function returns a virtual path that isn't understood by Postgres. Here we add a new function to TestLib.pm to turn such a path

Re: pgsql: Move strtoint() to common

On Fri, Mar 16, 2018 at 1:12 PM, Tom Lane wrote: > Alvaro Herrera writes: > > ah, but bowerbird is OK on ecpg, this is only failing on thrips, whelk, > > woodlouse. It sounds related to 32 vs. 64 bits ... > > BTW, the reason why bowerbird was green

Re: pgsql: Remove pg_class.relhaspkey

On Thu, Mar 15, 2018 at 9:41 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > Tom Lane wrote: >> Andrew Dunstan <and...@dunslane.net> writes: >> > Basing an MV on pg_class could always be difficult for pg_upgrade. Maybe >> > that's not a brilliant t

Re: pgsql: Remove pg_class.relhaspkey

On Thu, Mar 15, 2018 at 7:43 AM, Andres Freund wrote: > Hi, > > On 2018-03-14 19:35:40 +, Peter Eisentraut wrote: > > Remove pg_class.relhaspkey > > > > It is not used for anything internally, and it cannot be relied on for > > external uses, so it can just be removed.

Re: pgsql: Centralize json and jsonb handling of datetime types

On 01/17/2018 12:34 AM, Amit Langote wrote: > On Wed, Jan 17, 2018 at 9:29 AM, Andrew Dunstan <and...@dunslane.net> wrote: >> Centralize json and jsonb handling of datetime types > [ ... ] > >> src/include/utils/date.h | 4 +- > I noticed that these chang

pgsql: Fix compiler warnings due to commit cc4feded

Fix compiler warnings due to commit cc4feded Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/585e166e46a1572b59eb9fdaffc2d4b785000f9e Modified Files -- src/include/utils/date.h | 1 + 1 file changed, 1 insertion(+)

pgsql: Centralize json and jsonb handling of datetime types

Centralize json and jsonb handling of datetime types The creates a single function JsonEncodeDateTime which will format these data types in an efficient and consistent manner. This will be all the more important when we come to jsonpath so we don't have to implement yet more code doing the same

pgsql: Implement TZH and TZM timestamp format patterns

Implement TZH and TZM timestamp format patterns These are compatible with Oracle and required for the datetime template language for jsonpath in an upcoming patch. Nikita Glukhov and Andrew Dunstan, reviewed by Pavel Stehule. Branch -- master Details --- https://git.postgresql.org/pg

pgsql: Fix use of config-specific libraries for Windows OpenSSL

Fix use of config-specific libraries for Windows OpenSSL Commit 614350a3 allowed for an different builds of OpenSSL libraries on Windows, but ignored the fact that the alternative builds don't have config-specific libraries. This patch fixes the Solution file to ask for the correct libraries.

pgsql: Allow leading zero on exponents in pgbench test results

Allow leading zero on exponents in pgbench test results Following commit 7a727c18 this is found to be necessary on at least some Windows platforms. per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0aa1d489ea756b96b6d5573692ae9cd5d143c2a5 Modified

pgsql: Fix walsender timeouts when decoding a large transaction

Fix walsender timeouts when decoding a large transaction The logical slots have a fast code path for sending data so as not to impose too high a per message overhead. The fast path skips checks for interrupts and timeouts. However, the existing coding failed to consider the fact that a

pgsql: Fix walsender timeouts when decoding a large transaction

Fix walsender timeouts when decoding a large transaction The logical slots have a fast code path for sending data so as not to impose too high a per message overhead. The fast path skips checks for interrupts and timeouts. However, the existing coding failed to consider the fact that a

pgsql: Fix walsender timeouts when decoding a large transaction

Fix walsender timeouts when decoding a large transaction The logical slots have a fast code path for sending data so as not to impose too high a per message overhead. The fast path skips checks for interrupts and timeouts. However, the existing coding failed to consider the fact that a

<    4   5   6   7   8   9   10   >