I wrote:
> If you don't want an ORDER BY, maybe turn off enable_hashagg for
> these queries? But you'll get the same plan either way.
Or not ... I forgot it has a better model of the rowcount changes now:
regression=# explain SELECT few.dataa, count(*), min(id), max(id),
unnest('{1,1,3}'::int[]
Andres Freund writes:
> Termite is also failing due to differing row orders from the rest of the
> animals. I'd intentionally left those undefined, because I wanted some
> queries without an ORDER BY. Haven't decided what the best fix is yet.
Looks to me like all the bigendian critters are unhap
On 2017-01-18 19:34:52 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Adapt python regression tests to 69f4b9c85f16.
>
> Drat. I tested everything *but* plpython. You too, evidently :-(
Yea. I had taken it out of my configure invoking script because of a
packaging bug a while back :(.
Term
Andres Freund writes:
> Adapt python regression tests to 69f4b9c85f16.
Drat. I tested everything *but* plpython. You too, evidently :-(
regards, tom lane
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
Adapt python regression tests to 69f4b9c85f16.
Hopefully this'll unbreak the buildfarm.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/8b07aee8c5d803801c00103f0d61e32356aaf29c
Modified Files
--
src/pl/plpython/expected/plpython_setof.out | 7 ++-
1 f
Doc: improve documentation of new SRF-in-tlist behavior.
Correct a misstatement about how things used to work: we did allow nested
SRFs before, as long as no function had more than one set-returning input.
Also, attempt to document the fact that the new implementation changes the
behavior for SRF
Move targetlist SRF handling from expression evaluation to new executor node.
Evaluation of set returning functions (SRFs_ in the targetlist (like SELECT
generate_series(1,5)) so far was done in the expression evaluation (i.e.
ExecEvalExpr()) and projection (i.e. ExecProject/ExecTargetList) code.
Improve comment in hashsearch.c.
Typo fix from Mithun Cy; other improvements by me.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/e37360d5df240443bb6e997d26d54f59146283fc
Modified Files
--
src/backend/access/hash/hashsearch.c | 21 +++--
Reset the proper GUC in create_index test.
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add su
Reset the proper GUC in create_index test.
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add su
Reset the proper GUC in create_index test.
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add su
Reset the proper GUC in create_index test.
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add su
Reset the proper GUC in create_index test.
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add su
Reset the proper GUC in create_index test.
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add su
Change some test macros to return true booleans
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnin
Change some test macros to return true booleans
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnin
Change some test macros to return true booleans
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnin
Change some test macros to return true booleans
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnin
Change some test macros to return true booleans
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnin
Change some test macros to return true booleans
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnin
Implement array version of jsonb_delete and operator
This makes it possible to delete multiple keys from a jsonb value by
passing in an array of text values, which makes the operaiton much
faster than individually deleting the keys (which would require copying
the jsonb structure over and over aga
Disable transforms that replaced AT TIME ZONE with RelabelType.
These resulted in wrong answers if the relabeled argument could be matched
to an index column, as shown in bug #14504 from Evgeniy Kozlov. We might
be able to resurrect these optimizations by adjusting the planner's
treatment of Rela
Disable transforms that replaced AT TIME ZONE with RelabelType.
These resulted in wrong answers if the relabeled argument could be matched
to an index column, as shown in bug #14504 from Evgeniy Kozlov. We might
be able to resurrect these optimizations by adjusting the planner's
treatment of Rela
Disable transforms that replaced AT TIME ZONE with RelabelType.
These resulted in wrong answers if the relabeled argument could be matched
to an index column, as shown in bug #14504 from Evgeniy Kozlov. We might
be able to resurrect these optimizations by adjusting the planner's
treatment of Rela
Avoid use of DROP TABLE .. CASCADE in partitioning tests.
This isn't really guaranteed to always produce exactly the same
output; the order can change from run to run.
See related cleanup in 257d8157205a7be5f9799e8941b922521d678a25.
Branch
--
master
Details
---
http://git.postgresql.org
Add some more tests for tuple routing.
Commit a25665088d812d08bb888e961f208eaebf522050 fixed some issues with
how PartitionDispatch related code handled multi-level partitioned
tables, but didn't add any tests.
Discussion:
http://postgr.es/m/CA%2BTgmoZ86v1G%2Bzx9etMiSQaBBvYMKfU-iitqZArSh5z0n8Q4c
Update information_schema queries and system views for new relkind.
The original table partitioning patch overlooked this.
Discussion:
http://postgr.es/m/CAG1_KcDJiZB=l6youo_bvufj2q2851_xdkfhw0jdcd_2vtk...@mail.gmail.com
Keith Fiske and Amit Langote, adjusted by me.
Branch
--
master
Detai
Make messages mentioning type names more uniform
This avoids additional translatable strings for each distinct type, as
well as making our quoting style around type names more consistent
(namely, that we don't quote type names). This continues what started
as f402b9950120.
Discussion: https://po
Factor out logic for computing number of parallel workers.
Forthcoming patches to allow other types of parallel scans will
need this logic, or something like it.
Dilip Kumar
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/716c7d4b242f0a64ad8ac4dc48c6fed6557ba12c
Mo
On 1/18/17 1:46 PM, Tom Lane wrote:
> I wrote:
>> The previous coding applied a sort so as not to depend on what
>> order "locale -a" had returned things in, and I think we need
>> to retain that. At the very least, all the normalized names
>> need to be saved up and entered in a second pass.
>
>
I wrote:
> The previous coding applied a sort so as not to depend on what
> order "locale -a" had returned things in, and I think we need
> to retain that. At the very least, all the normalized names
> need to be saved up and entered in a second pass.
Actually, it seems like doing precisely that
Avoid conflicts with collation aliases generated by stripping.
This resulted in failures depending on the order of "locale -a" output.
The original coding in initdb sorted the results, but that should be
unnecessary as long as "locale -a" doesn't print duplicate names. The
original entries will t
Improve RLS planning by marking individual quals with security levels.
In an RLS query, we must ensure that security filter quals are evaluated
before ordinary query quals, in case the latter contain "leaky" functions
that could expose the contents of sensitive rows. The original
implementation o
Peter Eisentraut writes:
> OK, the problem has to do with the order of the locale -a output, which
> is in turn dependent on the current locale.
Ah, right, it succeeds unpatched if I run initdb in en_US rather than
C locale.
regards, tom lane
--
Sent via pgsql-committe
Peter Eisentraut writes:
> What's fishy about this is that I can't reproduce it locally in a
> variety of VMs, and the buildfarm is not unanimous either.
Well, as I said, I get
$ locale -a | grep ^aa_ER
aa_ER
aa_ER.utf8
aa_ER.utf8@saaho
aa_ER@saaho
What it looks like to me is that we see "aa_ER
On 1/18/17 12:23 PM, Peter Eisentraut wrote:
> Yeah, it's supposed to do that. Note that the second call to
> CollationCreate() in pg_import_system_collations() has the "if not
> exists" argument true regardless. So the error appears to come from the
> first one.
>
> What's fishy about this is t
On 1/18/17 10:43 AM, Tom Lane wrote:
> Maybe an appropriate fix would be to ignore collations whose names aren't
> equal to what we get for collcollate/collctype. Presumably the latter
> are getting canonicalized somehow.
Yeah, it's supposed to do that. Note that the second call to
CollationCrea
On 18-01-2017 12:43, Tom Lane wrote:
> I wrote:
>> running bootstrap script ... ok
>> performing post-bootstrap initialization ... 2017-01-18 09:49:45.019 EST
>> [25919] FATAL: collation "aa_ER@saaho" for encoding "UTF8" already exists
>> 2017-01-18 09:49:45.019 EST [25919] STATEMENT: SELECT
>>
I wrote:
> running bootstrap script ... ok
> performing post-bootstrap initialization ... 2017-01-18 09:49:45.019 EST
> [25919] FATAL: collation "aa_ER@saaho" for encoding "UTF8" already exists
> 2017-01-18 09:49:45.019 EST [25919] STATEMENT: SELECT
> pg_import_system_collations(if_not_exists =
Peter Eisentraut writes:
> Add function to import operating system collations
The buildfarm's not happy with this, and neither am I:
...
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... 2017-01-18 09:49:45.019 EST
[25919] FATAL: c
Add function to import operating system collations
Move this logic out of initdb into a user-callable function. This
simplifies the code and makes it possible to update the standard
collations later on if additional operating system collations appear.
Reviewed-by: Andres Freund
Reviewed-by: Eul
41 matches
Mail list logo
