On Tue, 03 Apr 2018 17:37:04 -0400
Tom Lane wrote:
> I wrote:
> > Hm, it fails on my own machine too (RHEL6, perl 5.10.1), with the
> > same "cannot transform this Perl type to jsonb" symptoms. A bit
> > of tracing shows that SvTYPE(in) is returning SVt_PVIV in some
> > of the failing cases, and
Fix incorrect description of USE_SLICING_BY_8_CRC32C.
And a typo in the description of USE_SSE42_CRC32C_WITH_RUNTIME_CHECK,
spotted by Daniel Gustafsson.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/127f489c2c7e9ff0e6cd5f990dab497ea3cf7e87
Modified Files
Fix incorrect description of USE_SLICING_BY_8_CRC32C.
And a typo in the description of USE_SSE42_CRC32C_WITH_RUNTIME_CHECK,
spotted by Daniel Gustafsson.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/a3c64ed6ce0da2d18e56179cac8bd752cf79f4b7
Modified Files
Fix incorrect description of USE_SLICING_BY_8_CRC32C.
And a typo in the description of USE_SSE42_CRC32C_WITH_RUNTIME_CHECK,
spotted by Daniel Gustafsson.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/8989f52b1b0636969545e6c8f6c813bc563ebcf5
Modified Files
---
Fix incorrect description of USE_SLICING_BY_8_CRC32C.
And a typo in the description of USE_SSE42_CRC32C_WITH_RUNTIME_CHECK,
spotted by Daniel Gustafsson.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/7be511a767cf41f808ee77911bec0f341d04c5fc
Modified Files
Also fix the descriptions in pg_config.h.win32.
I missed pg_config.h.win32 in the previous commit that fixed these in
pg_config.h.in.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/638a199fa9459dac42b588ccfcf7003539f37416
Modified Files
--
src/include/
Also fix the descriptions in pg_config.h.win32.
I missed pg_config.h.win32 in the previous commit that fixed these in
pg_config.h.in.
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/0b650285269d6055d0f1c8b10e96a49b118a6d0d
Modified Files
--
src/i
Also fix the descriptions in pg_config.h.win32.
I missed pg_config.h.win32 in the previous commit that fixed these in
pg_config.h.in.
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/0d2012c9f04afe375200d16d539a9ec5c0093c07
Modified Files
--
src/i
Also fix the descriptions in pg_config.h.win32.
I missed pg_config.h.win32 in the previous commit that fixed these in
pg_config.h.in.
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/8ed5249afff499d79bb9414a0340c495fccf53b1
Modified Files
--
src/i
Use ARMv8 CRC instructions where available.
ARMv8 introduced special CPU instructions for calculating CRC-32C. Use
them, when available, for speed.
Like with the similar Intel CRC instructions, several factors affect
whether the instructions can be used. The compiler intrinsics for them must
be s
On Tue, Apr 3, 2018 at 10:48 PM, Michael Banck
wrote:
> Hi,
>
> On Tue, Apr 03, 2018 at 08:48:08PM +0200, Magnus Hagander wrote:
> > On Tue, Apr 3, 2018 at 8:29 PM, Tom Lane wrote:
> > I'd bet a good lunch that nondefault BLCKSZ would break it, as well,
> > > since the way in which the corruptio
Fix pg_bsaebackup checksum tests
Hopefully fix the fact that these checks are unstable, by introducing
the corruption in a separate table from pg_class, and also explicitly
disable autovacuum on those tables. Also make sure PostgreSQL is
stopped while the corruption is introduced to avoid possible
Fix the new ARMv8 CRC code for short and unaligned input.
The code before the main loop, to handle the possible 1-7 unaligned bytes
at the beginning of the input, was broken, and read past the input, if the
the input was very short.
Branch
--
master
Details
---
https://git.postgresql.org
Hi,
On Wed, Apr 04, 2018 at 11:38:35AM +0200, Magnus Hagander wrote:
> On Tue, Apr 3, 2018 at 10:48 PM, Michael Banck
> wrote:
>
> > Hi,
> >
> > On Tue, Apr 03, 2018 at 08:48:08PM +0200, Magnus Hagander wrote:
> > > On Tue, Apr 3, 2018 at 8:29 PM, Tom Lane wrote:
> > > I'd bet a good lunch that
On Thu, Mar 29, 2018 at 4:39 AM, Peter Geoghegan wrote:
>
>
> Suggested next steps to deal with this:
>
> * A minor point: I don't think you should call
> RelationSetTargetBlock() when the page P_ISROOT(), which, as I
> mentioned, is a condition that can coexist with P_ISLEAF() with very
> small
On Tue, 03 Apr 2018 17:37:04 -0400
Tom Lane wrote:
> I wrote:
> > Hm, it fails on my own machine too (RHEL6, perl 5.10.1), with the
> > same "cannot transform this Perl type to jsonb" symptoms. A bit
> > of tracing shows that SvTYPE(in) is returning SVt_PVIV in some
> > of the failing cases, and
Anthony Bykov writes:
> Tom Lane wrote:
>> This results in one change in the module's test results: the example
>> that thinks it's returning a regexp match result no longer fails,
>> but just returns the scalar result (0). I'm inclined to think that
>> this is correct/desirable and the existing
Fix platform and Perl-version dependencies in new jsonb_plperl code.
Testing SvTYPE() directly is more fraught with problems than one might
think, because depending on context Perl might be storing a scalar value
in one of several forms, eg both numeric and string values. This resulted
in Perl-ve
I wrote:
> Anthony Bykov writes:
>> I guess the right test will look a little bit different:
>> CREATE FUNCTION testRegexpToJsonb() RETURNS jsonb
>> LANGUAGE plperl
>> TRANSFORM FOR TYPE jsonb
>> AS $$
>> $a = qr//;
>> return ($a);
>> $$;
> This is testing something else. I don't object to addin
Remove less-portable-than-believed test case.
In commit 331b2369c I added a test to see what jsonb_plperl would do
with a qr{} result. Turns out the answer is Perl version dependent.
That fact doesn't bother me particularly, but coping with multiple
result possibilities is way more work than this
Skip full index scan during cleanup of B-tree indexes when possible
Vacuum of index consists from two stages: multiple (zero of more) ambulkdelete
calls and one amvacuumcleanup call. When workload on particular table
is append-only, then autovacuum isn't intended to touch this table. However,
user
Foreign keys on partitioned tables
Author: Álvaro Herrera
Discussion: https://postgr.es/m/20171231194359.cvojcour423ulha4@alvherre.pgsql
Reviewed-by: Peter Eisentraut
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/3de241dba86f3dd000434f70aebba725fb928032
Modified
Hi,
On 2018-04-03 08:32:45 -0700, Andres Freund wrote:
> Hi,
>
> On 2018-04-03 09:24:12 +, Simon Riggs wrote:
> > New files for MERGE
> > src/backend/executor/nodeMerge.c | 575 +++
> > src/backend/parser/parse_merge.c | 660
> > src/include/ex
On Wed, Apr 4, 2018 at 5:33 AM, Pavan Deolasee wrote:
> Ok. Adding a check for tree height and setting target block only if it's >=
> 2, as suggested by you and Simon later. Rahila helped me also ran another
> round of tests and this does not lead to any performance regression (we were
> worried a
Improve FSM management for BRIN indexes.
BRIN indexes like to propagate additions of free space into the upper pages
of their free space maps as soon as the new space is known, even when it's
just on one individual index page. Previously this required calling
FreeSpaceMapVacuum, which is quite an
On Wed, Apr 4, 2018 at 10:40 PM, Andres Freund wrote:
> Hi,
>
> On 2018-04-03 08:32:45 -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2018-04-03 09:24:12 +, Simon Riggs wrote:
> > > New files for MERGE
> > > src/backend/executor/nodeMerge.c | 575 +++
> > > src/backend/p
Hi,
On 2018-04-05 00:02:06 +0530, Pavan Deolasee wrote:
> Apologies from my end. Simon checked with me regarding your referenced
> email. I was in the middle of responding to it (with a add-on patch to take
> care of your review comments), but got side tracked by some high priority
> customer esca
On Wed, Apr 4, 2018 at 11:46 AM, Andres Freund wrote:
> Hows that an explanation for just going ahead and committing? Without
> even commenting on why one thinks the pointed out issues are something
> that can be resolved later or somesuch? This has an incredibly rushed
> feel to it.
I agree tha
On Thu, Apr 5, 2018 at 12:16 AM, Andres Freund wrote:
> Hi,
>
> On 2018-04-05 00:02:06 +0530, Pavan Deolasee wrote:
> > Apologies from my end. Simon checked with me regarding your referenced
> > email. I was in the middle of responding to it (with a add-on patch to
> take
> > care of your review
docs: update ltree URL for the DMOZ catalog
Reported-by: bbrin...@gmail.com
Discussion:
https://postgr.es/m/152283596377.1441.11672249301622760...@wrigleys.postgresql.org
Author: Oleg Bartunov
Backpatch-through: 9.3
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdi
docs: update ltree URL for the DMOZ catalog
Reported-by: bbrin...@gmail.com
Discussion:
https://postgr.es/m/152283596377.1441.11672249301622760...@wrigleys.postgresql.org
Author: Oleg Bartunov
Backpatch-through: 9.3
Branch
--
REL9_3_STABLE
Details
---
https://git.postgresql.org/pg/c
docs: update ltree URL for the DMOZ catalog
Reported-by: bbrin...@gmail.com
Discussion:
https://postgr.es/m/152283596377.1441.11672249301622760...@wrigleys.postgresql.org
Author: Oleg Bartunov
Backpatch-through: 9.3
Branch
--
REL9_6_STABLE
Details
---
https://git.postgresql.org/pg/c
docs: update ltree URL for the DMOZ catalog
Reported-by: bbrin...@gmail.com
Discussion:
https://postgr.es/m/152283596377.1441.11672249301622760...@wrigleys.postgresql.org
Author: Oleg Bartunov
Backpatch-through: 9.3
Branch
--
REL_10_STABLE
Details
---
https://git.postgresql.org/pg/c
docs: update ltree URL for the DMOZ catalog
Reported-by: bbrin...@gmail.com
Discussion:
https://postgr.es/m/152283596377.1441.11672249301622760...@wrigleys.postgresql.org
Author: Oleg Bartunov
Backpatch-through: 9.3
Branch
--
REL9_4_STABLE
Details
---
https://git.postgresql.org/pg/c
docs: update ltree URL for the DMOZ catalog
Reported-by: bbrin...@gmail.com
Discussion:
https://postgr.es/m/152283596377.1441.11672249301622760...@wrigleys.postgresql.org
Author: Oleg Bartunov
Backpatch-through: 9.3
Branch
--
REL9_5_STABLE
Details
---
https://git.postgresql.org/pg/c
Rewrite pg_dump TAP tests
This reworks how the tests to run are defined. Instead of having to
define all runs for all tests, we define those tests which should pass
(generally using one of the defined broad hashes), add in any which
should be specific for this test, and exclude any specific runs
Restore erroneously removed ONLY from PK check
This is a blind fix, since I don't have SE-Linux to verify it.
Per unwanted change in rhinoceros, running sepgsql tests. Noted by Tom
Lane.
Discussion: https://postgr.es/m/32347.1522865...@sss.pgh.pa.us
Branch
--
master
Details
---
https:
On 2018-04-04 19:38:57 +, Alvaro Herrera wrote:
> Restore erroneously removed ONLY from PK check
>
> This is a blind fix, since I don't have SE-Linux to verify it.
>
> Per unwanted change in rhinoceros, running sepgsql tests. Noted by Tom
> Lane.
>
> Discussion: https://postgr.es/m/32347.15
Andres Freund writes:
> Shouldn't the difference due to the ONLY be visible in cases with
> inheritance? As in, spuriously succeeding or such? Seems like
> something that a normal regression test would be good for?
Yeah, if it actually matters (which I think it does), it shouldn't be hard
to de
Hi!
On Wed, Apr 4, 2018 at 7:29 PM, Teodor Sigaev wrote:
> Skip full index scan during cleanup of B-tree indexes when possible
>
Thank you for committing this.
It appears that patch contains some redundant variabled. See warnings
produced
by gcc-7.
nbtpage.c: In function '_bt_update_meta_cle
On Wed, Apr 4, 2018 at 3:32 PM, Alexander Korotkov
wrote:
> Hi!
>
> On Wed, Apr 4, 2018 at 7:29 PM, Teodor Sigaev wrote:
>>
>> Skip full index scan during cleanup of B-tree indexes when possible
>
>
> Thank you for committing this.
>
> It appears that patch contains some redundant variabled. See
doc: Improve indentation of SQL examples
Some of these were indented using 8 spaces whereas the rest uses 4
spaces. Probably originally some difference in tab size.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/a56e26784d7f418015a5be471eb500614a2f24ee
Modified F
Peter Geoghegan writes:
> I also see an assertion failure within _bt_getrootheight():
> TRAP: FailedAssertion("!(metad->btm_version == 3)", File:
> "/home/pg/postgresql/root/build/../source/src/backend/access/nbtree/nbtpage.c",
> Line: 619)
Hm, buildfarm's not complaining --- what's the test cas
On Wed, Apr 04, 2018 at 08:58:14PM -0400, Tom Lane wrote:
> Peter Geoghegan writes:
> > I also see an assertion failure within _bt_getrootheight():
>
> > TRAP: FailedAssertion("!(metad->btm_version == 3)", File:
> > "/home/pg/postgresql/root/build/../source/src/backend/access/nbtree/nbtpage.c",
>
On Wed, Apr 04, 2018 at 10:10:46AM -0700, Andres Freund wrote:
> This needs at the very least a response to the issues pointed out in the
> referenced email that you chose to ignore without any sort of comment.
That's definitely not cool.
--
Michael
signature.asc
Description: PGP signature
On Wed, Apr 4, 2018 at 5:58 PM, Tom Lane wrote:
>> TRAP: FailedAssertion("!(metad->btm_version == 3)", File:
>> "/home/pg/postgresql/root/build/../source/src/backend/access/nbtree/nbtpage.c",
>> Line: 619)
>
> Hm, buildfarm's not complaining --- what's the test case?
This was discovered while tes
Install errcodes.txt for use by extensions.
Maintainers of out-of-tree PLs typically need access to the set of
error codes. To avoid the need to duplicate that information in some
form in PL source trees, provide errcodes.txt as part of a server
installation.
Thomas Munro, based on a suggestion f
Peter Geoghegan writes:
>>> TRAP: FailedAssertion("!(metad->btm_version == 3)", File:
>>> "/home/pg/postgresql/root/build/../source/src/backend/access/nbtree/nbtpage.c",
>>> Line: 619)
>> Hm, buildfarm's not complaining --- what's the test case?
> This was discovered while testing/reviewing the
On Wed, Apr 4, 2018 at 8:28 PM, Tom Lane wrote:
>> This was discovered while testing/reviewing the latest version of the
>> INCLUDE covering indexes patch. It now seems to be unrelated.
>
> Oh, wait ... I wonder if you saw that because you were running a new
> backend without having re-initdb'd?
49 matches
Mail list logo