Re: [HACKERS] assorted code cleanup

On Wed, Sep 6, 2017 at 4:12 AM, Peter Eisentraut wrote: > On 8/21/17 01:11, Michael Paquier wrote: >>> - Drop excessive dereferencing of function pointers >> >> - (*next_ProcessUtility_hook) (pstmt, queryString, >> +

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Hello Alik, Applies, compiles, works for me. Some minor comments and suggestions. Two typos: - "usinng" -> "using" - "a rejection method used" -> "a rejection method is used" I'm not sure of "least_recently_used_i", this naming style is not used in pgbench. "least_recently_used" would be

Re: [HACKERS] cache lookup errors for missing replication origins

On Tue, Sep 5, 2017 at 12:59 PM, Michael Paquier wrote: > ERROR: 42704: replication slot "%s" does not exist s/slot/origin/ > As far as I can see, replorigin_by_oid makes no use of its missing_ok > = false in the backend code, so letting it untouched would have no >

Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote: > Arseny Sher writes: > >> Attached patch fixes this by stopping workers before RO drop, as >> already done in case when we drop replication slot. > > Sorry, here is the patch. > I could reproduce

[HACKERS] Re: Tuple-routing for certain partitioned tables not working as expected

On Tue, Sep 05, 2017 at 08:35:13PM +0900, Etsuro Fujita wrote: > On 2017/08/30 17:20, Etsuro Fujita wrote: > >On 2017/08/30 9:13, Amit Langote wrote: > >>On 2017/08/29 20:18, Etsuro Fujita wrote: > >>>On 2017/08/25 22:26, Robert Haas wrote: > On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita >

Re: [HACKERS] CLUSTER command progress monitor

Hi Hackers, I revised the patch like this: - Add "command" column in the view It tells that the running command is CLUSTER or VACUUM FULL. - Enable VACUUM FULL progress monitor Add heap_tuples_vacuumed and heap_tuples_recently_dead as a counter in the view. Sequence of phases

[HACKERS] Changing Jobs

Hi Everyone, Since the beginning of September I'm working full-time for EDB. The plan for now is to continue working at the projects I was working on, in particular JIT, and to have more time for reviews. I'll be spending the large majority of my time on community PG. I'm primarily mentioning it

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

Applies, compiles, works for me. Very very minor comments that I should have noticed before, sorry for this additional round trip. In the help line, move -I just after -i, to put short options in alphabetical and decreasing importance order. On this line, also add the information about the

Re: [HACKERS] paths in partitions of a dummy partitioned table

On Fri, Aug 25, 2017 at 10:46 PM, Robert Haas wrote: > On Thu, Jul 6, 2017 at 11:35 AM, Ashutosh Bapat > wrote: >> If a partitioned table is proven dummy, set_rel_pathlist() doesn't mark the >> partition relations dummy and thus doesn't set

Re: [HACKERS] psql - add special variable to reflect the last query status

Hello Tom, Here is a version 6. A few thoughts about this patch: * I think the ERROR_CODE variable should instead be named SQLSTATE. That is what the SQL standard calls this string, and it's also what just about all our documentation calls it; see PG_DIAG_SQLSTATE in libpq, or the SQLSTATE

Re: [HACKERS] Replacing lfirst() with lfirst_node() appropriately in planner.c

Ashutosh Bapat wrote: > On Wed, Sep 6, 2017 at 1:32 AM, Tom Lane wrote: > > BTW, I think we *could* use "lfirst_node(List, ...)" in cases where > > we know the list is supposed to be a list of objects rather than ints > > or Oids. I didn't do anything about that observation,

Re: [HACKERS] dropping partitioned tables without CASCADE

Okay, I have marked this as ready for committer. Thanks, On Wed, Sep 6, 2017 at 2:50 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia > wrote: > > > > 2) Add partition to the foo; > > > > create table foo_p1

Re: [HACKERS] document and use SPI_result_code_string()

On Thu, Aug 31, 2017 at 11:23 AM, Peter Eisentraut wrote: > A lot of semi-internal code just prints out numeric SPI error codes, > which is not very helpful. We already have an API function > SPI_result_code_string() to convert the codes to a string, so here is

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

On Tue, Jul 25, 2017 at 9:33 PM, Tomas Vondra wrote: > On 7/25/17 12:55 AM, Tom Lane wrote: > >> Tomas Vondra writes: >> >>> It seems to me that VACUUM and ANALYZE somewhat disagree on what >>> exactly reltuples means. VACUUM seems to

Re: [HACKERS] psql - add special variable to reflect the last query status

Here is a version 6. Small v7 update, sorry for the noise. Add testing the initial state of all variables. Fix typos in a comment in tests. Fix the documentation wrt the current implementation behavior. -- Fabien.diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml

Re: [HACKERS] CLUSTER command progress monitor

On Wed, Sep 6, 2017 at 3:58 PM, Tatsuro Yamada wrote: > I revised the patch like this: You should avoid top-posting. > I didn't change the name of view (pg_stat_progress_cluster) because I'm not > sure > whether the new name (pg_stat_progress_reorg) is suitable or

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

> When we reviewed the ecpg code,we found the array seem not have the > end > character('\0') after using the strncpy function. True. > In the function ECPGnoticeReceiver, we use the stncpy function copy > the > sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as > the size >

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

Hi, At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier wrote in

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

Tom Lane wrote: > "Bossart, Nathan" writes: > > On 9/4/17, 10:32 PM, "Simon Riggs" wrote: > >> If we want to keep the code simple we must surely consider whether the > >> patch has any utility. > > > ... I'd argue that this feels like a natural

Re: [HACKERS] dropping partitioned tables without CASCADE

I picked this patch for review and started looking at the implementation details. Consider the below test: 1) postgres=# create table foo (a int, b int) partition by list (a); CREATE TABLE postgres=# \d foo Table "public.foo" Column | Type | Collation | Nullable | Default

Re: [HACKERS] dropping partitioned tables without CASCADE

On Wed, Sep 6, 2017 at 1:06 PM, Rushabh Lathia wrote: > > 2) Add partition to the foo; > > create table foo_p1 partition of foo for values in (1, 2, 3) partition by > list (b); > > postgres=# \d foo > Table "public.foo" > Column | Type | Collation |

Re: [HACKERS] pg_basebackup behavior on non-existent slot

Magnus Hagander wrote: > On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote: > > Should the parent process of pg_basebackup be made to respond to SIGCHLD? > > Or call waitpid(bgchild, , WNOHANG) in some strategic loop? > > I think it's ok to just call waitpid() -- we don't

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

Michael Meskes writes: >> In the function ECPGnoticeReceiver, we use the stncpy function copy >> the >> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as >> the size >> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the >> previous

Re: [HACKERS] <> join selectivity estimate question

On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro wrote: > > Thanks. Bearing all that in mind, I ran through a series of test > scenarios and discovered that my handling for JOIN_ANTI was wrong: I > thought that I had to deal with inverting the result, but I now see >

Re: [HACKERS] dropping partitioned tables without CASCADE

On 2017/09/06 18:46, Rushabh Lathia wrote: > Okay, I have marked this as ready for committer. Thanks Ashutosh and Rushabh for rebasing and improving the patch. Looks good to me too. Regards, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE

On Fri, Jun 2, 2017 at 6:31 PM, Amit Kapila wrote: > > Your reasoning sounds sensible to me. I think the other way to attack > this problem is that we can maintain some local queue in each of the > workers when the shared memory queue becomes full. Basically, we can >

Re: [HACKERS] [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel

On Sat, Jul 22, 2017 at 12:05 AM, Alexey Chernyshov wrote: > the following patch transfers functionality from gevel module > (http://www.sai.msu.su/~megera/wiki/Gevel) which provides functions for > analyzing GIN and GiST indexes to pageinspect. Gevel was originally >

Re: [HACKERS] additional contrib test suites

On Sat, Aug 12, 2017 at 1:20 PM, Peter Eisentraut wrote: > Here are some small test suites for some contrib modules as well as > pg_archivecleanup that didn't have one previously, as well as one patch > to improve code coverage in a module. > > Will add to commit

Re: [HACKERS] Fix performance of generic atomics

On 2017-09-06 07:23, Tom Lane wrote: Jeff Janes writes: What scale factor and client count? How many cores per socket? It looks like Sokolov was just starting to see gains at 200 clients on 72 cores, using -N transaction. This means that Sokolov's proposed changes in

Re: [HACKERS] Fix performance of generic atomics

On 5 September 2017 at 21:23, Tom Lane wrote: > Jeff Janes writes: >> What scale factor and client count? How many cores per socket? It looks >> like Sokolov was just starting to see gains at 200 clients on 72 cores, >> using -N transaction. ... >

Re: [HACKERS] Copyright in partition.h and partition.c

> On 06 Sep 2017, at 02:56, Amit Langote wrote: > > On 2017/09/05 21:14, Tom Lane wrote: >> Amit Langote writes: >>> On 2017/09/05 15:48, Etsuro Fujita wrote: Here is the copyright in partition.h: * Copyright (c)

Re: [HACKERS] Adding support for Default partition in partitioning

Hi Ashutosh, I have tried to address your comments in V27 patch series[1]. Please find my comments inlined. > >> > >> The current set of patches contains 6 patches as below: > >> > >> 0001: > >> Refactoring existing ATExecAttachPartition code so that it can be used > >> for > >> default

Re: [HACKERS] Fix performance of generic atomics

On 2017-09-06 14:54, Sokolov Yura wrote: On 2017-09-06 07:23, Tom Lane wrote: Jeff Janes writes: What scale factor and client count? How many cores per socket? It looks like Sokolov was just starting to see gains at 200 clients on 72 cores, using -N transaction. This

Re: [HACKERS] path toward faster partition pruning

On 2017/09/04 10:10, Amit Langote wrote: > On 2017/09/02 2:52, Robert Haas wrote: >> It strikes me that this patch set is doing two things but maybe in the >> opposite order that I would have chosen to attack them. First, >> there's getting partition pruning to use something other than >>

Re: [HACKERS] document and use SPI_result_code_string()

Michael Paquier writes: > Fine for 0002. This reminds me of LockGXact and RemoveGXact in > twophase.c, as well as _hash_squeezebucket that have some code paths > that cannot return... Any thoughts about having some kind of > PG_NOTREACHED defined to 0 which could be put

Re: [HACKERS] <> join selectivity estimate question

Simon Riggs writes: > Why isn't this an open item for PG10? Why should it be? This behavior has existed for a long time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Fix performance of generic atomics

Sokolov Yura writes: > On 2017-09-06 15:56, Tom Lane wrote: >> The point I'm trying to make is that if tweaking generic.h improves >> performance then it's an indicator of missed cases in the less-generic >> atomics code, and the latter is where our attention should

Re: [HACKERS] <> join selectivity estimate question

On 6 September 2017 at 04:14, Ashutosh Bapat wrote: > On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro > wrote: >> >> Thanks. Bearing all that in mind, I ran through a series of test >> scenarios and discovered that my handling for

Re: [HACKERS] Fix performance of generic atomics

Simon Riggs writes: > On 5 September 2017 at 21:23, Tom Lane wrote: >> Moreover, it matters which primitive you're testing, on which platform, >> with which compiler, because we have a couple of layers of atomic ops >> implementations. > If there is no

Re: [HACKERS] Fix performance of generic atomics

On 2017-09-06 15:56, Tom Lane wrote: Simon Riggs writes: On 5 September 2017 at 21:23, Tom Lane wrote: Moreover, it matters which primitive you're testing, on which platform, with which compiler, because we have a couple of layers of atomic ops

[HACKERS] Fix bloom WAL tap test

Hi! I just realized that these lines of contrib/bloom/t/001_wal.pl don't check that queries give same results on master and standby. They just check that *return codes* of psql are equal. # Run test queries and compare their result > my $master_result = $node_master->psql("postgres", $queries);

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

Simon Riggs writes: > Based upon input from Tom and Fabien, I propose this additional doc patch. I do not think any of this is appropriate, particularly not the reference to 7.0.3. regards, tom lane -- Sent via pgsql-hackers mailing list

[HACKERS] Is anything preventing us from allowing write to foreign tables from standby?

Hi! We're currently blocking writing queries on standby if even they are modifying contents of foreign tables. But do we have serious reasons for that? Keeping in the mind FDW-sharding, making FDW-tables writable from standby would be good to prevent single-master bottleneck. I wrote simple

Re: [HACKERS] Walsender timeouts and large transactions

I've changed to "need review" to gain more attention from other. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Peter Eisentraut wrote: > I propose splitting the single Perl script into three separate test > files: one for basic command-line option handling and so on (I would > like to expand that later), one for the main upgrade test, and one for > the funny database names tests. Check. > We also need

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 4/14/17 02:00, Michael Paquier wrote: > Attached is an updated patch to use --no-sync with pg_dumpall calls. Please send a rebased patch. I propose splitting the single Perl script into three separate test files: one for basic command-line option handling and so on (I would like to expand

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

On 5 September 2017 at 11:58, Fabien COELHO wrote: > > Hello Simon, > >> Does raise the further question of how psql behaves when we connect to >> a pre-10 server, so we have SERVER_VERSION_NUM but yet it is not set. >> How does this >> \if SERVER_VERSION_NUM < x > > > The if

Re: [HACKERS] Fix performance of generic atomics

On 2017-09-06 16:36, Tom Lane wrote: Sokolov Yura writes: On 2017-09-06 15:56, Tom Lane wrote: The point I'm trying to make is that if tweaking generic.h improves performance then it's an indicator of missed cases in the less-generic atomics code, and the latter

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On Tue, Sep 5, 2017 at 1:38 PM, Tom Lane wrote: > The complaint I have about PRAGMA is that it's yet another syntax for > accomplishing pretty much the same thing. If you don't like the GUC > solution, we've already got the "comp_option" syntax for static options > in

Re: [HACKERS] Fix bloom WAL tap test

On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > I just realized that these lines of contrib/bloom/t/001_wal.pl don't > check that queries give same results on master and standby. They just > check that *return codes* of psql are equal. > > # Run test

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Alvaro Herrera writes: > Peter Eisentraut wrote: >> We also need to have a plan for handling the build farm. Maybe keep the >> vcregress.pl upgradecheck target as a thin wrapper for the time being? > The buildfarm already runs "make check" in src/bin/ when TAP tests are

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

Robert Haas writes: > I don't think we can just indefinitely continue to resist > providing manual control over this behavior on the theory that some > day we'll fix it. That's fair enough. We need to have a discussion about exactly what the knob does, which is distinct

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On Wed, Sep 6, 2017 at 11:03 AM, Tom Lane wrote: > That's fair enough. We need to have a discussion about exactly what > the knob does, which is distinct from the question of how you spell > the incantation for twiddling it. I'm dubious that a dumb "force a > custom plan"

Re: [HACKERS] Fix performance of generic atomics

On 2017-09-06 15:25:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-09-06 15:12:13 -0400, Tom Lane wrote: > >> It looks to me like two of the three implementations promise no such > >> thing. > > > They're volatile vars, so why not? > > Yeah, but so are the

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Sep 6, 2017 at 3:18 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote: >>> If somebody's applying apply_projection_to_path to a path that's already >>> been add_path'd, that's a

Re: [HACKERS] Fix performance of generic atomics

I wrote: > Ah. I was not thinking of touching pg_atomic_read_u32/u64_impl, > although now that you mention it, it's not clear to me why we > couldn't simplify > - return *(>value); > + return ptr->value; Just to check, I applied that change to pg_atomic_read_u32_impl and

Re: [HACKERS] why not parallel seq scan for slow functions

Robert Haas writes: > On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote: >> I'm not entirely following. I thought that add_path was set up to treat >> "can be parallelized" as an independent dimension of merit, so that >> parallel paths would always

Re: [HACKERS] Setting pd_lower in GIN metapage

Amit Langote writes: > On 2017/08/22 9:39, Michael Paquier wrote: >> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote >> wrote: >>> I updated brin_mask() and spg_mask() in the attached updated patches so >>> that they consider meta pages

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

On 2017-09-06 17:36:02 +0900, Kyotaro HORIGUCHI wrote: > Hi, > > At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier > wrote in >

Re: [HACKERS] Fix performance of generic atomics

Andres Freund writes: > On 2017-09-06 15:25:20 -0400, Tom Lane wrote: >> I think we can just use "old = ptr->value" to set up for the cmpxchg >> loop in every generic.h function that uses such a loop. > I think we might have been talking past each other - I thought you were >

Re: [HACKERS] why not parallel seq scan for slow functions

Robert Haas writes: > In particular, as Jeff and Amit point out, it > may well be that (a) before apply_projection_to_path(), the cheapest > plan is non-parallel and (b) after apply_projection_to_path(), the > cheapest plan would be a Gather plan, except that it's too late

Re: [HACKERS] Fix performance of generic atomics

Andres Freund writes: > On 2017-09-06 15:12:13 -0400, Tom Lane wrote: >> It looks to me like two of the three implementations promise no such >> thing. > They're volatile vars, so why not? Yeah, but so are the caller's variables. That is, in

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote: > Robert Haas writes: >> In particular, as Jeff and Amit point out, it >> may well be that (a) before apply_projection_to_path(), the cheapest >> plan is non-parallel and (b) after

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote: > Okay, now I understand your point, but I think we already change the > cost of paths in apply_projection_to_path which is done after add_path > for top level scan/join paths. Yeah. I think that's a nasty hack, and I

Re: [HACKERS] Fix performance of generic atomics

Hi, On 2017-09-06 14:31:26 -0400, Tom Lane wrote: > I wrote: > > Anyway, I don't have a big objection to applying this. My concern > > is more that we need to be taking a harder look at other parts of > > the atomics infrastructure, because tweaks there are likely to buy > > much more. > > I

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

Thus short, simple but meaningful examples which show how to do something useful with all that in the documentation may help people take advantage of these new features. I don't have an objection to providing an example. I wasn't terribly impressed with Simon's version, but maybe we can do

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 5, 20