On 2019/03/22 14:13, Michael Paquier wrote:
> On Fri, Mar 22, 2019 at 01:28:19PM +0900, Amit Langote wrote:
>> It looked fine before, but the new lines added by patch makes it look
>> wrong/misplaced somehow.
>
> Okay, what do you think about the attached then?
Thanks, looks fine.
Regards,
Amit
Fix crash with pg_partition_root
Trying to call the function with the top-most parent of a partition tree
was leading to a crash. In this case the correct result is to return
the top-most parent itself.
Reported-by: Álvaro Herrera
Author: Michael Paquier
Reviewed-by: Amit Langote
Discussion: htt
On Fri, Mar 22, 2019 at 04:05:20PM +0900, Amit Langote wrote:
> Thanks, looks fine.
OK, committed.
--
Michael
signature.asc
Description: PGP signature
Collations with nondeterministic comparison
This adds a flag "deterministic" to collations. If that is false,
such a collation disables various optimizations that assume that
strings are equal only if they are byte-wise equal. That then allows
use cases such as case-insensitive or accent-insensi
Add IntegerSet, to hold large sets of 64-bit ints efficiently.
The set is implemented as a B-tree, with a compact representation at leaf
items, using Simple-8b algorithm, so that clusters of nearby values use
less memory.
The IntegerSet isn't used for anything yet, aside from the test code, but
w
Delete empty pages during GiST VACUUM.
To do this, we scan GiST two times. In the first pass we make note of
empty leaf pages and internal pages. At second pass we scan through
internal pages, looking for downlinks to the empty pages.
Deleting internal pages is still not supported, like in nbtree
Fix bug in the GiST vacuum's 2nd stage.
We mustn't assume that the IndexVacuumInfo pointer passed to bulkdelete()
stage is still valid in the vacuumcleanup() stage.
Per very pink buildfarm.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/d1b9ee4e44062cc540d8e406f49
Make the integerset test more verbose.
Buildfarm member 'woodlouse' failed one of the tests, and I'm not sure
which test failed. Better to print the names of the tests, so that it
will appear in the regression.diffs on failure.
Branch
--
master
Details
---
https://git.postgresql.org/pg/c
Make printf format strings in test_integerset portable.
Use UINT64_FORMAT for printing uint64s.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/32f8ddf7e1c8b24382f98c14f6b588cd7e17418c
Modified Files
--
src/test/modules/test_integerset/test_integerset.c
More portability fixes for integerset tests.
Use UINT64CONST for large constants.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c477c68c8f660550219c69fac2ab41beb86d7f45
Modified Files
--
src/test/modules/test_integerset/test_integerset.c | 24
On Fri, 8 Mar 2019 at 05:39, Robert Haas wrote:
> src/backend/partitioning/partprune.c | 7 +-
I've attached a small patch that fixes a couple of incorrect sizeof()
calculations new in this commit.
Perhaps only a problem if sizeof(int) is not the same as sizeof(Oid),
but incorrect never-the-l
Fix ICU tests for older ICU versions
Change the tests to use old-style ICU locale specifications so that
they can run on older ICU versions.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/638db07814f389e739b2cfde01b592aa9150b1be
Modified Files
--
src/t
Fix yet more portability bugs in integerset and its tests.
There were more large constants that needed UINT64CONST. And one variable
was declared as "int", when it needed to be uint64. These bugs were only
visible on 32-bit systems; clearly I should've tested on one, given that
this code does a lo
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 8:17 PM Tom Lane wrote:
>>> Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
>>> Might the problem actually be the order in which OIDs are originally
>>> assigned, or something like that?
>> No, because then things would have
I wrote:
> I'm fairly baffled as to why the output order would be unstable
> given the sort, and even more as to why the instability didn't
> emerge before. Any thoughts?
Well, after actually looking at the code, the answer to the first
part of that is obvious: the printed dependency list comes f
On Fri, Mar 22, 2019 at 9:32 AM Tom Lane wrote:
> Apparently, that case is indeed unstable, cf
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fulmar&dt=2019-03-22%2016%3A15%3A14
I had a feeling that that would happen.
> I'm fairly baffled as to why the output order would be unstable
On Fri, Mar 22, 2019 at 10:13 AM Tom Lane wrote:
> Options:
Obviously if we were going to de-revert 7d3bf73ac then it wouldn't
quite be a straight de-revert. There would also be a few new comments
about the issue in relevant test files.
> 1a seems a bit ambitious but maybe it's worth doing, cons
Peter Geoghegan writes:
> On Fri, Mar 22, 2019 at 10:13 AM Tom Lane wrote:
>> 1a seems a bit ambitious but maybe it's worth doing, considering
>> that right now there's a non-negligible chance of OOM if you
>> try to drop a role that owns a huge number of objects, or just
>> plain failure due to
On Fri, Mar 22, 2019 at 10:38 AM Tom Lane wrote:
> So that means that the de-revert is probably the best option for
> now. Will you do the honors?
I'll take care of that shortly.
Thanks
--
Peter Geoghegan
Don't copy PartitionBoundInfo in set_relation_partition_info.
I (tgl) remain dubious that it's a good idea for PartitionDirectory
to hold a pin on a relcache entry throughout planning, rather than
copying the data or using some kind of refcount scheme. However, it's
certainly the responsibility o
Go back to suppressing foreign_data DETAIL test output.
This is almost a straight revert of commit fff518d, which itself was a
revert of 7d3bf73ac.
It turns out that commit 8aa9dd74, which sorted dependent objects before
deletion in DROP OWNED BY, was not sufficient to make all remaining
unstable
Rearrange make_partitionedrel_pruneinfo to avoid work when we can't prune.
Postpone most of the effort of constructing PartitionedRelPruneInfos
until after we have found out whether run-time pruning is needed at all.
This costs very little duplicated effort (basically just an extra
find_base_rel()
Peter Eisentraut writes:
> Collations with nondeterministic comparison
Buildfarm member tern doesn't like this patch. I think the issue is
probably that the 012_collation.pl test script isn't being sufficiently
careful to force UTF8 database encoding.
regards, tom lane
Re: Tom Lane 2019-03-22 <[email protected]>
> Peter Eisentraut writes:
> > Collations with nondeterministic comparison
>
> Buildfarm member tern doesn't like this patch. I think the issue is
> probably that the 012_collation.pl test script isn't being sufficiently
> careful to force
Add gitignore entries for jsonpath_gram.h
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/4e274a043fc8310ce1148190ef674beca06e990c
Modified Files
--
src/backend/utils/adt/.gitignore | 1 +
src/include/utils/.gitignore | 1 +
2 files changed, 2 insertio
Make subscription collation test work independent of locale
We need to set the database to UTF8 encoding so that the test can use
Unicode escapes.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/87914e708aabb7e2cd9045fa95b4fed99ca458ec
Modified Files
--
Peter Eisentraut writes:
> Add gitignore entries for jsonpath_gram.h
No, this is wrong, you should revert it. Those files aren't
built anymore. You might have leftover copies in your tree
depending on how thoroughly you cleaned it before pulling
550b9d26f, but this isn't the appropriate solutio
Add options to enable and disable checksums in pg_checksums
An offline cluster can now work with more modes in pg_checksums:
- --enable enables checksums in a cluster, updating all blocks with a
correct checksum, and updating the control file at the end.
- --disable disables checksums in a cluster
Revert "Add gitignore entries for jsonpath_gram.h"
This reverts commit 4e274a043fc8310ce1148190ef674beca06e990c.
These files aren't actually built anymore since 550b9d26f.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/7b084b38310cfe9c8b58cc615a81df625c771f5d
Mod
Add option -N/--no-sync to pg_checksums
This is an option consistent with what pg_dump, pg_rewind and
pg_basebackup provide which is useful for leveraging the I/O effort when
testing things, not to be used in a production environment.
Author: Michael Paquier
Reviewed-by: Michael Banck, Fabien Coe
Hi,
On 2019-03-21 15:52:23 +, Tom Lane wrote:
> Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.
>
> These commands allow the argument type list to be omitted if there is
> just one object that matches by name. However, if that syntax was
> used with DROP IF EXISTS and
On Sat, 23 Mar 2019 at 15:33, Andres Freund wrote:
> I now get:
>
> /home/andres/src/postgresql/src/backend/parser/parse_func.c: In function
> ‘LookupFuncWithArgs’:
> /home/andres/src/postgresql/src/backend/parser/parse_func.c:2285:5: warning:
> this statement may fall through [-Wimplicit-fallth
Expand EPQ tests for UPDATEs and DELETEs
Previously there was basically no coverage for UPDATEs encountering
deleted rows, and no coverage for DELETE having to perform EPQ. That's
problematic for an upcoming commit in which EPQ is tought to integrate
with tableams. Also, there was no test for UPD
David Rowley writes:
> On Sat, 23 Mar 2019 at 15:33, Andres Freund wrote:
>> I now get:
>> /home/andres/src/postgresql/src/backend/parser/parse_func.c:2285:5: warning:
>> this statement may fall through [-Wimplicit-fallthrough=]
> hmm. Surprised your compiler can't see that's not possible. I gu
Add unreachable "break" to satisfy -Wimplicit-fallthrough.
gcc is a bit pickier about this than perhaps it should be.
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/fb50d3f03fe6876b878d636a31
35 matches
Mail list logo
