On 03/27/2017 08:23 AM, Peter Eisentraut wrote:
> Clean up Perl code according to perlcritic
>
> Fix all perlcritic warnings of severity level 5, except in
> src/backend/utils/Gen_dummy_probes.pl, which is automatically generated.
>
> Reviewed-by: Dagfinn Ilmari Mannsåker
> Reviewed-by: Daniel G
Show ignored constants as "$N" rather than "?" in pg_stat_statements.
The trouble with the original choice here is that "?" is a valid (and
indeed used) operator name, so that you could end up with ambiguous
statement texts like "SELECT ? ? ?". With this patch, you instead
see "SELECT $1 ? $2", w
Fix uninitialized memory propagation mistakes
Valgrind complains that some uninitialized bytes are being passed around
by the extended statistics code since commit 7b504eb282ca2f, as reported
by Andres Freund. Silence it.
Tomas Vondra submitted a patch which he verified to fix the complaints
in
doc: Improve rendering of notes/cautions using XSL-FO
Center title and put a border around it, like the output that the DSSSL
version gave.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/6e31c3e13514be4404f716f152ac4c434adad03a
Modified Files
--
doc/src
Still more code review for single-page hash vacuuming.
Most seriously, fix use of incorrect block ID, per a report from
Jeff Janes that it causes a crash and a diagnosis from Amit Kapila.
Improve consistency between the hash and btree versions of this
code by adding back a PANIC that btree has, a
Fsync directory after creating or unlinking file.
If file was created/deleted just before powerloss it's possible that
file system will miss that. To prevent it, call fsync() where creating/
unlinkg file is critical.
Author: Michael Paquier
Reviewed-by: Ashutosh Bapat, Takayuki Tsunakawa, me
Bra
Fix thinko in estimate_num_groups
The code for the reworked n-distinct estimation on commit 7b504eb282 was
written differently in a previous version of the patch, prior to commit;
on rewriting it, we missed updating an initializer. This caused the
code to (mistakenly) apply a fudge factor even in
Improve performance of find_all_inheritors()
Previous coding uses three nested loops which obviously were a pain for
large number of table's children. Patch replaces inner loop with
a hashmap.
Author: Aleksander Alekseev
Reviewed-by: me
https://commitfest.postgresql.org/13/1058/
Branch
--
m
On Sun, Mar 26, 2017 at 2:26 AM, Masahiko Sawada wrote:
> On Sun, Mar 26, 2017 at 1:37 AM, Fujii Masao wrote:
>> On Mon, Mar 6, 2017 at 9:37 PM, Masahiko Sawada
>> wrote:
>>> On Fri, Mar 3, 2017 at 10:50 PM, Simon Riggs wrote:
Allow vacuums to report oldestxmin
Allow VACUUM and
doc: Fix oldhtml/old PDF build again
Commit e259e1f748c7a6d67e307a90d6c27b8ab8b90df8 was faulty and created
some broken output. This one fixes it better.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/5196f13b2726eeabfe2c8b7a97fc05839766cdce
Modified Files
---
Andrew Gierth wrote:
> > "Alvaro" == Alvaro Herrera writes:
>
> Alvaro> Fix a couple of problems in pg_get_statisticsextdef
>
> Alvaro> src/test/regress/expected/stats_ext.out | 7 +++
>
> Missed an update to stats_ext_1.out ?
Yeah ... instead of fixing it, I pushed Tomas's patch to
Rework the stats_ext test
As suggested by Tom Lane, avoid printing specific estimated cost values,
because they vary across architectures; instead, verify plan shapes (in
this case, HashAggregate vs. GroupAggregate), as we do in other planner
tests.
We can now remove expected/stats_ext_1.out.
Au
PL/Python: Add cursor and execute methods to plan object
Instead of
plan = plpy.prepare(...)
res = plpy.execute(plan, ...)
you can now write
plan = plpy.prepare(...)
res = plan.execute(...)
or even
res = plpy.prepare(...).execute(...)
and similarly for the cursor() method
Improve performance of find_tabstat_entry()/get_tabstat_entry()
Patch introduces a hash map reloid -> PgStat_TableStatus which improves
performance in case of large number of tables/partitions.
Author: Aleksander Alekseev
Reviewed-by: Andres Freund, Anastasia Lubennikova, Tels, me
https://commit
Improve documentation of how NOT NULL works with partitioning.
Amit Langote
Discussion:
http://postgr.es/m/a6f99cdb-21e7-1d65-1381-91f2cfa15...@lab.ntt.co.jp
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/d65561464f45d325e82ad91918bcd4e2881ce567
Modified Files
--
Tidy up the CREATE TABLE documentation for partitioning.
Remove some tags that make this too "loud". Fix some typos.
Amit Langote, with a few minor corrections by me
Discussion:
http://postgr.es/m/a6f99cdb-21e7-1d65-1381-91f2cfa15...@lab.ntt.co.jp
Branch
--
master
Details
---
http:/
Fix improper NULL handling in list partitioning code.
The previous logic was wrong when the value was NULL but there was
no partition for NULL.
Amit Langote, reviewed by Jeevan Ladhe
Discussion:
http://postgr.es/m/d64f8498-70eb-3c88-b56d-c54fd3b05...@lab.ntt.co.jp
Branch
--
master
Details
Allow ON CONFLICT .. DO NOTHING on a partitioned table.
ON CONFLICT .. DO UPDATE still doesn't work, for lack of a way of
enforcing uniqueness across partitions, but we can still allow this
case.
Amit Langote, per discussion with Peter Geoghegan. Additional
wordsmithing by me.
Discussion:
http
Change default of log_directory to 'log'
The previous default 'pg_log' might have indicated by its "pg_" prefix
that it is an internal system directory. The new default is more in
line with the typical naming of directories with user-facing log files.
Together with the renaming of pg_clog and pg_
Pass DSA_ALLOC_HUGE when allocating a shared TIDBitmap.
When creating an unshared TIDBitmap, we pass MCXT_ALLOC_HUGE to allow
allocations >1GB, so by analogy we pass DSA_ALLOC_HUGE for a shared
TIDBitmap.
Bug introduced by commit 98e6e89040a0534ca26914c66cae9dd49ef62ad9.
Report by Rafia Sabih, fi
Clean up Perl code according to perlcritic
Fix all perlcritic warnings of severity level 5, except in
src/backend/utils/Gen_dummy_probes.pl, which is automatically generated.
Reviewed-by: Dagfinn Ilmari Mannsåker
Reviewed-by: Daniel Gustafsson
Branch
--
master
Details
---
http://git.p
On Fri, Mar 24, 2017 at 12:59 AM, Peter Eisentraut
wrote:
> On 3/23/17 10:25, Petr Jelinek wrote:
>> On 23/03/17 15:17, Stephen Frost wrote:
>>> Petr,
>>>
>>> * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
On 23/03/17 14:47, Petr Jelinek wrote:
> I am looking into buildfarm failures
22 matches
Mail list logo
