Re: 2018-03 Commitfest Summary (Andres #1)

2018-03-04 8:29 GMT+01:00 Craig Ringer : > On 4 March 2018 at 14:58, Pavel Stehule wrote: >> >> >> 2018-03-04 3:09 GMT+01:00 Craig Ringer : >> >>> On 3 March 2018 at 17:56, Fabien COELHO wrote: >>>

Re: 2018-03 Commitfest Summary (Andres #1)

On Sat, Mar 03, 2018 at 05:13:25PM -0800, Andres Freund wrote: > Reviewing whether the implementation is good enough *does* use > resources. Our scarcest resource isn't patch contributions, it's > dealing with review and maintenance. This is true. One thing that patch authors tend to easily

Re: 2018-03 Commitfest Summary (Andres #1)

On 4 March 2018 at 14:58, Pavel Stehule wrote: > > > 2018-03-04 3:09 GMT+01:00 Craig Ringer : > >> On 3 March 2018 at 17:56, Fabien COELHO wrote: >> >>> >>> The (trivial) big picture is to allow client-side expressions in psql

Re: 2018-03 Commitfest Summary (Andres #1)

2018-03-04 3:09 GMT+01:00 Craig Ringer : > On 3 March 2018 at 17:56, Fabien COELHO wrote: > >> >> The (trivial) big picture is to allow client-side expressions in psql >> (which as a \if:-) by reusing pgbench expression engine, so that one could >>

Re: [HACKERS] Removing LEFT JOINs in more cases

On 10 January 2018 at 08:44, Tom Lane wrote: > select distinct nextval('foo') from a left join b ... > > The presence of the DISTINCT again doesn't excuse changing how often > nextval() gets called. > > I kinda doubt this list of counterexamples is exhaustive, either;

Re: GSOC 2018 ideas

Hi Aleksander, Went through the documents listed by you, and they are helpful! It seems the main purpose of extension pg_protobuf is to parse a protobuf struct and return the decoded field. May I ask how these kinds of extensions are used in postgreSQL (or in other words, the scenarios to use

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Sun, Mar 4, 2018 at 4:37 PM, Thomas Munro wrote: > Could it be that a concurrency bug causes tuples to be lost on the > tuple queue, and also sometimes causes X (terminate) messages to be > lost from the error queue, so that the worker appears to go away >

Re: Rewriting the test of pg_upgrade as a TAP test - take two

On Sun, Mar 4, 2018 at 12:42 AM, Peter Eisentraut wrote: > On 1/26/18 03:00, Michael Paquier wrote: >> As promised on a recent thread, here is a second tentative to switch >> pg_upgrade's test.sh into a TAP infrastructure. > > AFAICT, this still has the same

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Sun, Mar 4, 2018 at 4:17 PM, Tomas Vondra wrote: > On 03/04/2018 04:11 AM, Thomas Munro wrote: >> On Sun, Mar 4, 2018 at 4:07 PM, Tomas Vondra >> wrote: >>> ! ERROR: lost connection to parallel worker >> >> That sounds like the new

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On 03/04/2018 04:11 AM, Thomas Munro wrote: > On Sun, Mar 4, 2018 at 4:07 PM, Tomas Vondra > wrote: >> I've started "make check" with parallel_schedule tweaked to contain many >> select_parallel runs, and so far I've seen a couple of failures like >> this (about 10

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Sun, Mar 4, 2018 at 4:07 PM, Tomas Vondra wrote: > I've started "make check" with parallel_schedule tweaked to contain many > select_parallel runs, and so far I've seen a couple of failures like > this (about 10 failures out of 1500 runs): > > select count(*)

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On 03/04/2018 03:40 AM, Andres Freund wrote: > > > On March 3, 2018 6:36:51 PM PST, Tomas Vondra > wrote: >> On 03/04/2018 03:20 AM, Thomas Munro wrote: >>> Hi, >>> >>> I saw a one-off failure like this: >>> >>> QUERY PLAN >>>

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Sun, Mar 4, 2018 at 3:48 PM, Thomas Munro wrote: > I've seen it several times on Travis CI. (So I would normally have > been able to tell you about this problem before the was committed, > except that the email thread was too long and the mail archive app > cuts

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On Sun, Mar 4, 2018 at 3:40 PM, Andres Freund wrote: > On March 3, 2018 6:36:51 PM PST, Tomas Vondra > wrote: >>On 03/04/2018 03:20 AM, Thomas Munro wrote: >>> Hi, >>> >>> I saw a one-off failure like this: >>> >>>

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On March 3, 2018 6:36:51 PM PST, Tomas Vondra wrote: >On 03/04/2018 03:20 AM, Thomas Munro wrote: >> Hi, >> >> I saw a one-off failure like this: >> >> QUERY PLAN >>

Re: select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

On 03/04/2018 03:20 AM, Thomas Munro wrote: > Hi, > > I saw a one-off failure like this: > > QUERY PLAN > -- >Aggregate (actual rows=1 loops=1) > !-> Nested Loop (actual

select_parallel test failure: gather sometimes losing tuples (maybe during rescans)?

Hi, I saw a one-off failure like this: QUERY PLAN -- Aggregate (actual rows=1 loops=1) !-> Nested Loop (actual rows=98000 loops=1) -> Seq Scan on tenk2 (actual rows=10

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

On 03/04/2018 02:37 AM, Tom Lane wrote: > Tomas Vondra writes: >> Here is v2 of the fix. It does handle all the convert_to_scalar calls >> for various data types, just like the numeric one did in v1 with the >> exception of bytea. > > Pushed with some adjustments.

Re: 2018-03 Commitfest Summary (Andres #1)

On 3 March 2018 at 17:56, Fabien COELHO wrote: > > The (trivial) big picture is to allow client-side expressions in psql > (which as a \if:-) by reusing pgbench expression engine, so that one could > write things like > > \let i :j + 12 * :k > > or > > \if :VERSION_NUM <

Re: 2018-03 Commitfest Summary (Andres #1)

On 2 March 2018 at 17:47, Fabien COELHO wrote: > > For instance, I used extensively tps throttling, latencies and timeouts > measures when developping and testing the checkpointer sorting & throttling > patch. > I have to admit, I've found tps throttling and latency

Re: 2018-03 Commitfest Summary (Andres #1)

On 2 March 2018 at 02:37, Tom Lane wrote: > Andres Freund writes: > > On 2018-03-01 14:09:02 +0100, Fabien COELHO wrote: > >>> A bit concerned that we're turning pgbench into a kitchen sink. > > >> I do not understand "kitchen sink" expression in this

Re: [HACKERS] plpgsql - additional extra checks

On 03/02/2018 10:30 PM, Pavel Stehule wrote: > Hi > > 2018-03-01 21:14 GMT+01:00 David Steele >: > > Hi Pavel, > > On 1/7/18 3:31 AM, Pavel Stehule wrote: > > > >     There, now it's in the correct Waiting for Author state. :) >

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

Tomas Vondra writes: > Here is v2 of the fix. It does handle all the convert_to_scalar calls > for various data types, just like the numeric one did in v1 with the > exception of bytea. Pushed with some adjustments. > The bytea case is fixed by checking that the

Re: 2018-03 Commitfest Summary (Andres #1)

Hi, On 2018-03-03 10:36:18 +0100, Fabien COELHO wrote: > Why would committers prevent pgbench to be used to reproduce this kind of > load? The goal of *discussing* whether a feature is worth the cost is obviously not to deprive users of features. I find that is a fairly absurd, and frankly

Re: WIP: BRIN multi-range indexes

Hi, Attached is a patch version fixing breakage due to pg_proc changes commited in fd1a421fe661. On 03/02/2018 05:08 AM, Tom Lane wrote: > Andres Freund writes: >> On 2018-02-25 01:30:47 +0100, Tomas Vondra wrote: >>> Note: Currently, this only works with float8-based data

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

On 2018-03-01 11:30:39 +0100, Fabien COELHO wrote: > > > > -#ifdef HAVE_SYS_SELECT_H > > > +#ifdef PGBENCH_USE_SELECT/* force use of > > > select(2)? */ > > > +#undef HAVE_PPOLL > > > +#endif > > > +#ifdef HAVE_PPOLL > > > +#include > > > +#elif

Re: BUG #14941: Vacuum crashes

On 2018-01-11 08:14:42 +0900, Michael Paquier wrote: > On Wed, Jan 10, 2018 at 05:26:43PM +, Bossart, Nathan wrote: > > Perhaps any logging changes for VACOPT_NOWAIT could be handled in a > > separate thread. For now, I've updated 0003 to remove the logging > > changes. > > Thanks. I am

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 2, 2018 at 10:53 AM, Masahiko Sawada wrote: > > 2) In the append-only case, index statistics can lag indefinitely. > > The original proposal proposed a new GUC that specifies a fraction of > the modified pages to trigger a cleanup indexes. Regarding original

Re: perltidy version

Magnus Hagander writes: > Ah yeah, if I apply that one first, the diff from using 20140328 is much > smaller. Attached is that one, which means the difference between the two > perltidy versions. I'm hardly a Perl guru, so I'm not going to opine on whether these changes are

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

An updated patch version, fixing the breakage caused by fd1a421fe6 twiddling with pg_proc. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 0001-Keep-information-about-already-estimated-clauses.patch.gz

Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support

On Sat, Mar 03, 2018 at 08:58:18AM -0500, Peter Eisentraut wrote: > On 3/2/18 03:23, Michael Paquier wrote: >> That's a better idea. I have reworked that in 0001. What do you think? >> This has the same effect as diag(), which shows information directly to >> the screen, and that's the behavior

Re: autovacuum: change priority of the vacuumed tables

On 03/03/2018 10:21 PM, Jim Nasby wrote: > On 3/3/18 2:53 PM, Tomas Vondra wrote: >> That largely depends on what knobs would be exposed. I'm against adding >> some low-level knobs that perhaps 1% of the users will know how to tune, >> and the rest will set it incorrectly. Some high-level options

Re: autovacuum: change priority of the vacuumed tables

On 3/3/18 2:53 PM, Tomas Vondra wrote: That largely depends on what knobs would be exposed. I'm against adding some low-level knobs that perhaps 1% of the users will know how to tune, and the rest will set it incorrectly. Some high-level options that would specify the workload type might work,

Re: autovacuum: change priority of the vacuumed tables

On 03/03/2018 08:32 PM, Jim Nasby wrote: > On 2/19/18 10:00 AM, Tomas Vondra wrote: >> So I don't think this is a very promising approach, unfortunately. >> >> What I think might work is having a separate pool of autovac workers, >> dedicated to these high-priority tables. That still would not

use of getcwd(3)/chdir(2) during path resolution (exec.c)

Hi, When trying to deduct their absolute, symlink-free path from argv0, pg_ctl, postgres (and probably others) use: a) getcwd(3) in find_my_exec in order to complement a relative path containing at least one directory separator b) getcwd(3) and chdir(2) in resolve_symlinks in order to

Re: JIT compiling with LLVM v11

Hi, On 2018-03-03 09:37:35 -0500, Peter Eisentraut wrote: > On 3/2/18 19:29, Andres Freund wrote: > >> Using my standard set of CC=gcc-7 and CXX=g++-7, the build fails with > >> > >> g++-7: error: unrecognized command line option '-stdlib=libc++' > > > It's actually already filtered, I just

Re: pgbench - allow to specify scale as a size

On 2/20/18 05:06, Fabien COELHO wrote: >> Now the overhead is really 60-65%. Although the specification is >> unambiguous, >> but we still need some maths to know whether it fits in buffers or memory... >> The point of Karel regression is to take this into account. >> >> Also, whether this

Re: autovacuum: change priority of the vacuumed tables

On 2/19/18 10:00 AM, Tomas Vondra wrote: So I don't think this is a very promising approach, unfortunately. What I think might work is having a separate pool of autovac workers, dedicated to these high-priority tables. That still would not guarantee the high-priority tables are vacuumed

Re: Function to track shmem reinit time

On Sat, Mar 03, 2018 at 01:00:52PM -0500, Peter Eisentraut wrote: > On 2/28/18 07:11, Anastasia Lubennikova wrote: > > Currently, if the 'restart_after_crash' option is on, postgres will just > > restart. > > And the only way to know that it happened is to regularly parse logfile > > or monitor

Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT

On 2/20/18 10:10, Matheus de Oliveira wrote: > Besides that, there is a another change in this patch on current ALTER > CONSTRAINT about deferrability options. Previously, if the user did > ALTER CONSTRAINT without specifying an option on deferrable or > initdeferred, it was implied the default

Re: Online enabling of checksums

On Sat, Mar 3, 2018 at 5:17 PM, Tomas Vondra wrote: > > > On 03/03/2018 05:08 PM, Magnus Hagander wrote: > > > > > > On Sat, Mar 3, 2018 at 5:06 PM, Tomas Vondra > > > > wrote: > > > > On

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On 2/7/18 13:34, Bossart, Nathan wrote: > Here is a patch to allow users to change the WAL segment size of a cluster > with > pg_resetwal. Like the '--wal-segize' option in initdb, the new '-s' option > accepts segment sizes in megabytes. Or how about we call the new option, um, --wal-segsize?

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Wed, Feb 21, 2018 at 04:35:50PM +0900, Michael Paquier wrote: > You have an excellent point here, and I did not consider it. > For pg_dump and pg_dumpall, something like what I described in > https://www.postgresql.org/message-id/20180112012440.ga2...@paquier.xyz > to extend pg_settings so as

Re: [HACKERS] user-defined numeric data types triggering ERROR: unsupported type

Hi, Here is v2 of the fix. It does handle all the convert_to_scalar calls for various data types, just like the numeric one did in v1 with the exception of bytea. The bytea case is fixed by checking that the boundary values are varlenas. This seems better than checking for BYTEAOID explicitly,

Re: perltidy version

On Fri, Mar 2, 2018 at 4:49 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Fri, Mar 2, 2018 at 3:53 PM, Tom Lane wrote: > >> +1. We're not that far away from it being time to run > pgindent/perltidy, > >> so now would be a

Re: Function to track shmem reinit time

On 2/28/18 07:11, Anastasia Lubennikova wrote: > Currently, if the 'restart_after_crash' option is on, postgres will just > restart. > And the only way to know that it happened is to regularly parse logfile > or monitor it, catching restart messages. This approach is really > inconvenient for >

Re: [PATCH] Minor fixes for reloptions tests

On 1/22/18 15:06, Nikolay Shaplov wrote: > I have a small fixes for already committed reloption test patch > (https://www.postgresql.org/message-id/2615372.orqtEn8VGB@x200m) > > First one is missing tab symbol where it should be. > > The second is a comment. "The OIDS option is not stored" is

Re: pgbench randomness initialization

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed The patch 8 works and addresses the things I noticed earlier.

Re: WIP: a way forward on bootstrap data

John Naylor writes: > On 3/3/18, Tom Lane wrote: >> * In 0006, I'm not very pleased with the introduction of >> "Makefile.headers". > I wasn't happy with it either, but I couldn't get it to build > otherwise. The sticking point was the symlinks in >

Re: WIP: a way forward on bootstrap data

John Naylor writes: > I've attached a patch that takes care of these cleanups so they don't > clutter the patch set. Pushed. I made a couple of cosmetic changes in genbki.pl. regards, tom lane

Re: Online enabling of checksums

On 03/03/2018 05:08 PM, Magnus Hagander wrote: > > > On Sat, Mar 3, 2018 at 5:06 PM, Tomas Vondra > > wrote: > > On 03/03/2018 01:38 PM, Robert Haas wrote: > > On Sat, Mar 3, 2018 at 7:32 AM, Robert Haas

Re: Online enabling of checksums

On Sat, Mar 3, 2018 at 5:06 PM, Tomas Vondra wrote: > On 03/03/2018 01:38 PM, Robert Haas wrote: > > On Sat, Mar 3, 2018 at 7:32 AM, Robert Haas > wrote: > >> On Fri, Mar 2, 2018 at 6:26 PM, Tomas Vondra > >>

Re: Online enabling of checksums

On 03/03/2018 01:38 PM, Robert Haas wrote: > On Sat, Mar 3, 2018 at 7:32 AM, Robert Haas wrote: >> On Fri, Mar 2, 2018 at 6:26 PM, Tomas Vondra >> wrote: >>> Hmmm, OK. So we need to have a valid checksum on a page, disable >>> checksums, set

Re: line_perp() (?-|) is broken.

Emre Hasegeli writes: >> Possibly this objection is pointless, because I'm not at all sure that >> the existing code is careful about how it uses FPeq/FPzero; perhaps >> we're applying EPSILON to all manner of numbers that don't have units >> of the coordinate space. But this

Re: line_perp() (?-|) is broken.

> However, for either patch, I'm a bit concerned about using FPzero() > on the inner product result. To the extent that the EPSILON bound > has any useful meaning at all, it needs to mean a maximum difference > between two coordinate values. The inner product has units of coordinates > squared,

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

Peter Eisentraut writes: > On 3/3/18 00:48, Tom Lane wrote: >> I don't think that can possibly work. It would only be safe if, between >> the thrower and the catcher, there were no other levels of control >> operating according to the normal error-handling

Re: WIP: a way forward on bootstrap data

John Naylor writes: > On 3/3/18, Tom Lane wrote: >> * I'm a little disturbed by the fact that 0002 has to "re-doublequote >> values that are macros expanded by initdb.c". I see that there are only >> a small number of affected places, so maybe it's not

Re: 2018-03 Commitfest Summary (Andres #1)

Moin, On Fri, March 2, 2018 2:48 pm, Andres Freund wrote: > Hi, > > On 2018-03-02 11:06:12 +0100, Fabien COELHO wrote: >> A lot of patches do not even get a review: no immediate interest or more >> often no ressources currently available, patch stays put, I'm fine with >> that. > > Well, even if

Re: All Taxi Services need Index Clustered Heap Append

On 3 March 2018 at 05:30, Darafei "Komяpa" Praliaskouski wrote: > Our options were: > > - partitioning. Not entirely trivial when your id is uuid. To get visible > gains, we need to make sure each driver gets their own partition. That would > leave us with 50 000(+) tables, and

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

On 03/03/2018 06:19 AM, Erik Rijkers wrote: > On 2018-03-03 01:55, Tomas Vondra wrote: >> Hi there, >> >> attached is an updated patch fixing all the reported issues (a bit more >> about those below). > > Hi, > > 0007-Track-statistics-for-streaming-spilling.patch  won't apply.  All > the other

Re: TAP test module - PostgresClient

On 3/1/18 23:39, Michael Paquier wrote: > On Thu, Mar 01, 2018 at 02:27:13AM -0800, Andres Freund wrote: >> If I understand correctly there's been no progress on this since, and >> there'd definitely need to be major work to get something we can agree >> upon. Doesn't seem v11 material. I think we

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

2018-03-03 15:02 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 3/3/18 00:48, Tom Lane wrote: > > I don't think that can possibly work. It would only be safe if, between > > the thrower and the catcher, there were no other levels of control > > operating according to the

Re: Rewriting the test of pg_upgrade as a TAP test - take two

On 1/26/18 03:00, Michael Paquier wrote: > As promised on a recent thread, here is a second tentative to switch > pg_upgrade's test.sh into a TAP infrastructure. AFAICT, this still has the same problem as the previous take, namely that adding a TAP test suite to the pg_upgrade subdirectory will

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

On 3/3/18 00:48, Tom Lane wrote: > I don't think that can possibly work. It would only be safe if, between > the thrower and the catcher, there were no other levels of control > operating according to the normal error-handling rules. But input > functions certainly cannot assume that they are

Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support

On 3/2/18 03:23, Michael Paquier wrote: > That's a better idea. I have reworked that in 0001. What do you think? > This has the same effect as diag(), which shows information directly to > the screen, and that's the behavior I was looking for. I ended up using plan skip_all, which seems to be

Re: Contention preventing locking

On Thu, Mar 1, 2018 at 1:22 PM, Konstantin Knizhnik wrote: > > On 28.02.2018 16:32, Amit Kapila wrote: >> >> On Mon, Feb 26, 2018 at 8:26 PM, Konstantin Knizhnik >> wrote: > > > Yes, but two notices: > 1. Tuple lock is used inside heap_*

idea - custom menu

Hi I am looking on project https://github.com/NikolayS/postgres_dba Nice idea, and perfect publicity of typical PostgreSQL maintenance task. We can allow to call some external applications on some key press (not command) and evaluate their output. mc has F2 for User menu. It can works well with

Re: Online enabling of checksums

On Sat, Mar 3, 2018 at 7:32 AM, Robert Haas wrote: > On Fri, Mar 2, 2018 at 6:26 PM, Tomas Vondra > wrote: >> Hmmm, OK. So we need to have a valid checksum on a page, disable >> checksums, set some hint bits on the page (which won't be

[WIP] Document update for Logical Replication security

Hi, Hackers, The attached patch adds the following information to the document on Logical Replication. About the requirement of connection role of Logical Replication, written in 31.7 of the manual is as follows. -- The role used for the replication connection must have the REPLICATION

Re: Desirability of client-side expressions in psql?

2018-03-03 11:35 GMT+01:00 Fabien COELHO : > > Hello devs, > > This is a discussion without actual patch intended for pg12, to be added > to CF 2018-09. The expected end result is either "returned with feedback", > meaning proceed to send some big patch(es), or "rejected",

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 6:26 PM, Tomas Vondra wrote: > Hmmm, OK. So we need to have a valid checksum on a page, disable > checksums, set some hint bits on the page (which won't be WAL-logged), > enable checksums again and still get a valid checksum even with the new >

Re: [HACKERS] GSoC 2017: weekly progress reports (week 4) and patch for hash index

On Fri, Mar 2, 2018 at 9:27 AM, Thomas Munro wrote: > On Fri, Mar 2, 2018 at 3:57 PM, Andres Freund wrote: >> Based on this sub-thread this patch's status of 'needs review' doesn't >> quite seem accurate and 'waiting on author' and then

Re: WIP: a way forward on bootstrap data

I wrote: > I'll submit a > preliminary patch soon to get some of those items out of the way. I've attached a patch that takes care of these cleanups so they don't clutter the patch set. -John Naylor From d97a8b2e5fa4977e656d1aca7ee7bf1289ecbd40 Mon Sep 17 00:00:00 2001 From: John Naylor

Desirability of client-side expressions in psql?

Hello devs, This is a discussion without actual patch intended for pg12, to be added to CF 2018-09. The expected end result is either "returned with feedback", meaning proceed to send some big patch(es), or "rejected", meaning the project does not want this, no point in submitting something.

Re: public schema default ACL

On 03/03/2018 01:56 AM, Noah Misch wrote: > Commit 5770172 ("Document security implications of search_path and the public > schema.") is largely a workaround for the fact that the boot_val of > search_path contains "public" while template0 gets "GRANT CREATE, USAGE ON > SCHEMA public TO PUBLIC".

Re: STATISTICS retained in CREATE TABLE ... LIKE (INCLUDING ALL)?

I've attached a rebased patch which fixes up the conflicts caused by 8b08f7d. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services create_table_like_statistics_v4.patch Description: Binary data

Re: 2018-03 Commitfest Summary (Andres #1)

Hello Andres, For instance, I used extensively tps throttling, latencies and timeouts measures when developping and testing the checkpointer sorting & throttling patch. That doesn't say that much about proposed feature additions, we didn't say that feature isn't useful? Sure. The point I

Re: 2018-03 Commitfest Summary (Andres #1)

Hello Peter, On the "adequate return" point, my opinion is that currently pgbench is just below the feature set needed to be generally usable, so not improving it is a self-fullfilling ensurance that it will not be used further. Once the "right" feature set is reached (for me, at least

Re: [HACKERS] Another oddity in handling of WCO constraints in postgres_fdw

Hello, On Wed, Feb 28, 2018 at 05:22:42PM +0900, Etsuro Fujita wrote: > I rebased the patch over HEAD and revised comments/docs a little bit. Please > find attached a new version of the patch. I've reviewed the patch. The code is good, clear and it is pretty small. There are documentation fixes

Re: Parallel Aggregates for string_agg and array_agg

I've attached a rebased patch which fixes the conflicts caused by fd1a421. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services combinefn_for_string_and_array_aggs_v4.patch Description: Binary data

Re: 2018-03 Commitfest Summary (Andres #1)

Hello, [...] The consequence of this appears to be that we should integrate everything that anybody decided worthy enough to review. That just doesn't make sense, we can't maintain the project that way, nor will the design be even remotely coherent. Sure. The pgbench capabilities we are

Re: WIP: a way forward on bootstrap data

Thanks for taking a look. On 3/3/18, Tom Lane wrote: > John Naylor writes: >> Version 8, rebased against 76b6aa41f41d. > > I took a preliminary look through this, without yet attempting to execute > the script against HEAD. I have a few thoughts: > > *