Re: [HACKERS] Fix performance of generic atomics

On Tue, Sep 5, 2017 at 11:39 AM, Jesper Pedersen wrote: > On 09/05/2017 02:24 PM, Tom Lane wrote: > >> Jesper Pedersen writes: >> >>> I have tested this patch on a 2-socket machine, but don't see any >>> performance change in the various

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

Ashutosh Bapat writes: > On Tue, Sep 5, 2017 at 4:02 PM, Jeevan Chalke > wrote: >> Attached patch for replacing linitial() with linital_node() appropriately in >> planner.c > Ok. The patch looks good to me. It compiles and make

Re: [HACKERS] Coverage improvements of src/bin/pg_basebackup and pg_receivewal --endpos

On Tue, Sep 5, 2017 at 10:19 PM, Peter Eisentraut wrote: > On 6/9/17 02:08, Michael Paquier wrote: >> I have just played with that, and attached is a patch to implement the >> so-said option with a basic set of tests, increasing code coverage of >>

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On Mon, Sep 4, 2017 at 4:15 PM, Tom Lane wrote: > Also, the main thing that we need xact.c's involvement for in the first > place is the fact that implicit transaction blocks, unlike regular ones, > auto-cancel on an error, leaving you outside a block not inside a failed >

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

On Wed, Sep 6, 2017 at 12:11 AM, Fabien COELHO wrote: > >> Sorry, I don't follow that. You meant I should add a newline before >> pg_realloc()? That is, >> >> +initialize_cmds = >> +(char *) pg_realloc(initialize_cmds, >> +

Re: [HACKERS] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

On Wed, Sep 6, 2017 at 1:15 AM, Jacob Champion wrote: > On Sun, Sep 3, 2017 at 11:14 PM, Michael Paquier > wrote: >> +#if defined(USE_ASSERT_CHECKING) && !defined(FRONTEND) >> +void >> +AssertPageIsLockedForLSN(Page page) >> +{ >> From a design

Re: [HACKERS] pg_stat_wal_write statistics view

On Tue, Aug 15, 2017 at 7:39 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/29/17 22:10, Haribabu Kommi wrote: > > Updated patch to use shared counter instead of adding pg_stat_ calls to > send > > the statistics from each background process/worker. > > Your patch needs to

Re: [HACKERS] proposal psql \gdesc

2017-09-06 0:18 GMT+02:00 Tom Lane : > Fabien COELHO writes: > > I did yet another rebase of your patch after Tom alphabetically ordered > > backslash commands. Here is the result. > > Pushed with some massaging. > Thank you very much > >

Re: [HACKERS] Fix performance of generic atomics

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. I spent some time poking at this with the test scaffolding I showed at

[HACKERS] GatherMerge misses to push target list

During my recent work on costing of parallel paths [1], I noticed that we are missing to push target list below GatherMerge in some simple cases like below. Test prepration - create or replace function simple_func(var1 integer) returns integer as $$ begin return var1 +

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

On Wed, Sep 6, 2017 at 1:32 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Tue, Sep 5, 2017 at 4:02 PM, Jeevan Chalke >> wrote: >>> Attached patch for replacing linitial() with linital_node() appropriately

Re: [HACKERS] Making clausesel.c Smarter

On 6 September 2017 at 00:43, Daniel Gustafsson wrote: > This patch was moved to the currently open Commitfest. Given the above > comment, is the last patch in this thread still up for review, or are you > working on a new version? Just to avoid anyone reviewing an outdated

Re: [HACKERS] Parallel Append implementation

On 30 August 2017 at 17:32, Amit Khandekar wrote: > On 16 August 2017 at 18:34, Robert Haas wrote: >> Thanks for the benchmarking results! >> >> On Tue, Aug 15, 2017 at 11:35 PM, Rafia Sabih >> wrote: >>> Q4 | 244 | 12

Re: [HACKERS] Proposal for changes to recovery.conf API

On Wed, Sep 6, 2017 at 12:31 AM, Simon Riggs wrote: > I've not worked on this at all, so it isn't ready for re-review and commit. > > I get the "lets do it early" thing and will try to extract a subset in > October. Nice to see that you are still planning to work on that.

Re: [HACKERS] assorted code cleanup

Peter Eisentraut writes: > Do you mean specifically the hook variables, or any function pointers? > I can see your point in the above case, but for example here > - if ((*tinfo->f_lt) (o.upper, c.upper, flinfo)) > + if (tinfo->f_lt(o.upper, c.upper,

Re: [HACKERS] show "aggressive" or not in autovacuum logs

Thank you for the opinions. At Tue, 29 Aug 2017 15:00:57 +0900, Masahiko Sawada wrote in

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 5, 2017 at 12:06 PM, Amit Langote wrote: > On 2017/09/05 15:30, Ashutosh Bapat wrote: >> Those changes are already part of my updated 0001 patch. Aren't they? >> May be you should just review those and see if those are suitable for >> you? > > Yeah, I

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/05 13:20, Amit Langote wrote: > The later phase can > build that list from the AppendRelInfos that you mention we now [1] build. > > [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=30833ba154 Looking at that commit again, AppendRelInfos are still not created for

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 5, 2017 at 11:54 AM, Amit Langote wrote: > On 2017/09/05 13:20, Amit Langote wrote: >> The later phase can >> build that list from the AppendRelInfos that you mention we now [1] build. >> >> [1]

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/05 15:30, Ashutosh Bapat wrote: > Those changes are already part of my updated 0001 patch. Aren't they? > May be you should just review those and see if those are suitable for > you? Yeah, I think it's going to be the same patch, functionality-wise. And sorry, I didn't realize you

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/05 13:20, Amit Langote wrote: On 2017/09/04 21:32, Ashutosh Bapat wrote: +1. Will Fujita-san's patch also handle getting rid of partitioned_rels list? As Fujita-san mentioned, his patch won't. Actually, I suppose he didn't say that partitioned_rels itself is useless, just that

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

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. >From 008d54dfe2e8ba610bb7c897cfbb4ee7a700aa2e Mon Sep 17 00:00:00 2001 From: Arseny Sher

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

Hello, Currently, DROP SUBSCRIPTION on REL_10_STABLE would block forever in the following setup: node 1: create table t (i int); create publication p for table t; node 2: create table t (i int); create subscription s CONNECTION 'port=5432' publication p; begin; alter subscription s disable ;

[HACKERS] atomics/arch-x86.h is stupider than atomics/generic-gcc.h?

I spent some time trying to devise a suitable performance microbenchmark for the atomic ops, in pursuit of whether the proposal at https://commitfest.postgresql.org/14/1154/ is worth doing. I came up with the attached very simple-minded test case, which you run with something like create

Re: [HACKERS] Fix performance of generic atomics

Hi, On 05/25/2017 11:12 AM, Sokolov Yura wrote: I agree that lonely semicolon looks bad. Applied your suggestion for empty loop body (/* skip */). Patch in first letter had while(true), but I removed it cause I think it is uglier: - `while(true)` was necessary for grouping read with `if`, -

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

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) 2007-2017, PostgreSQL Global Development Group >>> >>> I think it's reasonable that that

Re: [HACKERS] increasing the default WAL segment size

Hi, I was looking to commit this, but the changes I made ended up being pretty large. Here's what I changed in the attached: - split GUC_UNIT_BYTE into a separate commit, squashed rest - renamed GUC_UNIT_BYT to GUC_UNIT_BYTE, don't see why we'd have such a weird abbreviation? - bumped control

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

On Mon, Sep 4, 2017 at 3:21 PM, Jeff Janes wrote: > > If I tell pg_basebackup to use a non-existent slot, it immediately reports > an error. And then it exits with an error, but only after streaming the > entire database contents. > > If you are doing this interactively

Re: [HACKERS] proposal psql \gdesc

Fabien COELHO writes: > I did yet another rebase of your patch after Tom alphabetically ordered > backslash commands. Here is the result. Pushed with some massaging. regards, tom lane -- Sent via pgsql-hackers mailing list

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

On Wed, Sep 6, 2017 at 2:36 AM, Bossart, Nathan wrote: > On 9/4/17, 8:16 PM, "Michael Paquier" wrote: >> So I would tend to think that the same column specified multiple times >> should cause an error, and that we could let VACUUM run work N times

Re: [HACKERS] pgbench tap tests & minor fixes.

Hello Tom, sub pgbench($) My concern is basically about maintaining coding style consistency. Yes, I'm fine with that. I have removed it in the v12 patch. reasons why it's not like that already. I do have to say that many of the examples I've seen look more like line noise than

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

On Tue, Sep 5, 2017 at 4:06 PM, Fabien COELHO wrote: > >> Attached the latest patch. Please review it. > > > Patch applies and compiles cleanly. > > Three very minor points: > > Typo added in the documentation: ".Each" -> ". Each". > > In "case 8:" there is a very long line

Re: [HACKERS] show "aggressive" or not in autovacuum logs

Hello, At Mon, 28 Aug 2017 20:07:32 -0700, "David G. Johnston" wrote in > On Mon, Aug 28, 2017 at 2:26 AM, Kyotaro HORIGUCHI < > horiguchi.kyot...@lab.ntt.co.jp> wrote: > > >

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

Attached the latest patch. Please review it. Patch applies and compiles cleanly. Three very minor points: Typo added in the documentation: ".Each" -> ". Each". In "case 8:" there is a very long line which lacks a newline before pg_realloc second argument. I think that the check should

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

On Fri, Aug 25, 2017 at 10:08 PM, Robert Haas wrote: > On Mon, Aug 21, 2017 at 5:08 AM, Amit Kapila wrote: >> (b) I have changed the costing of gather path for path target in >> generate_gather_paths which I am not sure is the best way. Another >>

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

> On 17 Aug 2017, at 11:08, Daniel Gustafsson wrote: > >> On 16 Aug 2017, at 17:51, Tom Lane wrote: >> >> Heikki Linnakangas writes: >>> This no longer works: >> >>> postgres=# CREATE TEXT SEARCH DICTIONARY public.simple_dict ( >>>

Re: [HACKERS] Allow INSTEAD OF DELETE triggers to modify the tuple for RETURNING

On Mon, Aug 14, 2017 at 6:48 AM, Marko Tiikkaja wrote: > On Fri, Jul 1, 2016 at 2:12 AM, I wrote: > >> Currently the tuple returned by INSTEAD OF triggers on DELETEs is only >> used to determine whether to pretend that the DELETE happened or not, which >> is often not helpful

Re: [HACKERS] Proposal: pg_rewind to skip config files

On Mon, Sep 4, 2017 at 3:38 PM, Alvaro Herrera wrote: > Chris Travers wrote: > > On Mon, Sep 4, 2017 at 12:23 PM, Michael Paquier < > michael.paqu...@gmail.com> > > wrote: > > > > > On Mon, Sep 4, 2017 at 7:21 PM, Michael Paquier > > > wrote:

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 5, 2017 at 1:16 PM, Amit Langote wrote: > On 2017/09/05 15:43, Ashutosh Bapat wrote: >> Ok. Can you please answer my previous questions? >> >> AFAIU, the list contained RTIs of the relations, which didnt' have >> corresponding AppendRelInfos to lock

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

Here is the copyright in partition.h: * Copyright (c) 2007-2017, PostgreSQL Global Development Group I think it's reasonable that that matches the copyright in partition.c, but partition.c has: * Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group * Portions Copyright

Re: [HACKERS] Default Partition for Range

Hello all, This is to inform all that this patch has been merged with default list partition patch [1]. There will be no further updates here. The status of this will be updated on the commitfest according to progres on that thread. [1]

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

On 2017/09/05 15:48, Etsuro Fujita wrote: > Here is the copyright in partition.h: > >  * Copyright (c) 2007-2017, PostgreSQL Global Development Group > > I think it's reasonable that that matches the copyright in partition.c, > but partition.c has: > >  * Portions Copyright (c) 1996-2017,

Re: [HACKERS] postgres_fdw bug in 9.6

On 2017/09/05 13:43, Ryan Murphy wrote: The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested This feature is obviously a

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/05 15:43, Ashutosh Bapat wrote: > Ok. Can you please answer my previous questions? > > AFAIU, the list contained RTIs of the relations, which didnt' have > corresponding AppendRelInfos to lock those relations. Now that we > create AppendRelInfos even for partitioned partitions with my

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

i can't apply your patch cleanly i think it needs rebase Regards Surafel On Thu, Aug 31, 2017 at 1:38 PM, Jing Wang wrote: > Hi All, > > Enclosed please find the patch only for the pg_dump using the 'comment on > current_database' statement. > > This patch should be

Re: [HACKERS] Secondary index access optimizations

On 05.09.2017 04:02, Amit Langote wrote: Like Thomas, I'm not so sure about the whole predtest.c patch. The core logic in operator_predicate_proof() should be able to conclude that, say, k < 21 is implied by k <= 20, which you are trying to address with some special case code. If there is

Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised

Jeff Janes wrote: > I'm attaching a patch for each option. Each one independently solves the > problem. But I think we should do both. There is no point in issuing > unnecessary kill system calls, and there may also be more spurious wake-ups > than just these ones. I modified patch 1 a bit --

Re: [HACKERS] Proposal: pg_rewind to skip config files

Chris Travers wrote: > On Mon, Sep 4, 2017 at 12:23 PM, Michael Paquier > wrote: > > > On Mon, Sep 4, 2017 at 7:21 PM, Michael Paquier > > wrote: > > > A simple idea would be to pass as a parameter a regex on which we > > > check files to

Re: [HACKERS] pgbench tap tests & minor fixes.

Michael Paquier wrote: > On Thu, Aug 31, 2017 at 9:29 PM, Nikolay Shaplov wrote: > > I am about to set "Ready for commit" status to this patch. So there is my > > summary for commiter, so one does not need to carefully read all the thread. > > > > This patch is consists of three

Re: [HACKERS] pg_upgrade changes can it use CREATE EXTENSION?

On Wed, Aug 30, 2017 at 06:01:58PM -0400, Tom Lane wrote: > "Regina Obe" writes: > > I think this thread covers most of the issues. > > https://lists.osgeo.org/pipermail/postgis-devel/2017-August/026355.html > > My thought was is it possible for pg_upgrade to be taught to use

Re: [HACKERS] multiple target of VACUUM command

Ouch! At Thu, 31 Aug 2017 23:09:20 +0900, Michael Paquier wrote in > On Thu, Aug 31, 2017 at 9:53 PM, Kyotaro HORIGUCHI > wrote: > > I sometimes feel annoyed when

Re: [HACKERS] [POC] hash partitioning

On Mon, Sep 4, 2017 at 4:08 PM, amul sul wrote: > I've updated patch to use an extended hash function (​Commit # > 81c5e46c490e2426db243eada186995da5bb0ba7) for the partitioning. > > I have done some testing with these patches, everything looks fine, attaching sql and out file

Re: [HACKERS] Variable substitution in psql backtick expansion

I wrote: > "Daniel Verite" writes: >> That would look like the following, for example, with a 3-space margin >> for the description: >> AUTOCOMMIT >>If set, successful SQL commands are automatically committed > But we could do something close to that, say two-space

Re: [HACKERS] Variable substitution in psql backtick expansion

[ psql-version-num-8.patch ] Pushed with some minor additional fiddling. Ok, Thanks. I also noticed the reformating. -- Fabien. -- 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] [PATCH] Assert that the correct locks are held when calling PageGetLSN()

Hi Michael, thanks for the review! On Sun, Sep 3, 2017 at 11:14 PM, Michael Paquier wrote: >> While working on checksum support for GPDB, we noticed that several >> callers of PageGetLSN() didn't follow the correct locking procedure. > > Well, PageGetLSN can be used in

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

2017-09-05 18:06 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > [ psql-psql-pager-env-2.patch ] > > Pushed, with some fooling with the documentation (notably, > re-alphabetizing relevant lists). > > Grepping turned up an additional place that's

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: > [ psql-version-num-8.patch ] Pushed with some minor additional fiddling. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

Sorry, I don't follow that. You meant I should add a newline before pg_realloc()? That is, +initialize_cmds = +(char *) pg_realloc(initialize_cmds, +sizeof(char) * n_cmds + 1); Yes. Or maybe

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

Pavel Stehule writes: > [ psql-psql-pager-env-2.patch ] Pushed, with some fooling with the documentation (notably, re-alphabetizing relevant lists). Grepping turned up an additional place that's examining the PAGER environment variable, namely PQprint() in

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

[ redirecting to -hackers for wider comment ] Simon Riggs writes: > On 5 September 2017 at 07:51, Tom Lane wrote: >> Add psql variables showing server version and psql version. >> >> We already had a psql variable VERSION that shows the verbose form

Re: [HACKERS] Proposal for changes to recovery.conf API

On 5 September 2017 at 06:47, Daniel Gustafsson wrote: >> On 27 Mar 2017, at 10:27, Simon Riggs wrote: >> >> On 7 March 2017 at 23:31, Josh Berkus wrote: >>> On 03/02/2017 07:13 AM, David Steele wrote: Hi Simon, On 2/25/17

Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised

Alvaro Herrera wrote: > Jeff Janes wrote: > > > I'm attaching a patch for each option. Each one independently solves the > > problem. But I think we should do both. There is no point in issuing > > unnecessary kill system calls, and there may also be more spurious wake-ups > > than just these

Re: [HACKERS] A note about debugging TAP failures

On 4/25/17 11:00, Daniel Gustafsson wrote: > Makes sense, assuming a “clean slate” to run on seems a reasonable assumption > for the test and it makes for simpler code in PostgresNode. Updated the patch > which now have static datadir names; retains on PG_TESTS_NOCLEAN or any kind > of > test

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

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 'x' construct in pl/pgsql, or the

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

Robert Haas writes: > On Tue, Sep 5, 2017 at 12:16 PM, Tom Lane wrote: >> Hm. I think it would be a fine idea to push this change into v10, >> so that all psql versions that have \if would have these variables. >> However, I'm less enthused about

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

2017-09-05 15:01 GMT+02:00 Daniel Gustafsson : > > On 08 Apr 2017, at 09:42, Pavel Stehule wrote: > > > > 2017-04-08 2:30 GMT+02:00 Peter Eisentraut < > peter.eisentr...@2ndquadrant.com >>: > > On 4/6/17 14:32,

Re: [HACKERS] postgres_fdw bug in 9.6

> I tested that with HEAD, but couldn't reproduce this problem. Didn't you test that with HEAD? Yeah, I know it's not an issue other people are having - I think it's something specific about how my environment / postgres build is set up. In any case I knew that it wasn't caused by your patch.

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

Michael Paquier writes: > On Mon, Sep 4, 2017 at 11:15 PM, Tom Lane wrote: >> I don't want to go there, and was thinking we should expand the new >> comment in DefineSavepoint to explain why not. > Okay. Does anyone want to do further review on

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

On 9/4/17, 8:16 PM, "Michael Paquier" wrote: > So vacuum_multiple_tables_v14.patch is good for a committer in my > opinion. With this patch, if the same relation is specified multiple > times, then it gets vacuum'ed that many times. Using the same column > multi-times

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

On 5 September 2017 at 09:58, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 5, 2017 at 12:16 PM, Tom Lane wrote: >>> Hm. I think it would be a fine idea to push this change into v10, >>> so that all psql versions that have

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

On Tue, Sep 5, 2017 at 12:16 PM, Tom Lane wrote: > Hm. I think it would be a fine idea to push this change into v10, > so that all psql versions that have \if would have these variables. > However, I'm less enthused about adding them to the 9.x branches. > Given the lack of

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

On 2017-09-05 13:58:56 +0300, Konstantin Knizhnik wrote: > > > On 04.09.2017 23:52, Andres Freund wrote: > > > > Yea, I've changed that already, although it's currently added earlier, > > because the alignment is needed before, to access the column correctly. > > I've also made number of

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

This is good. Please can we backpatch these are far as they will go (easily)? There is very little risk in doing so and significant benefits in being able to rely on scripts that know about versions. Hm. I think it would be a fine idea to push this change into v10, so that all psql versions

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

On 9/4/17, 10:32 PM, "Simon Riggs" wrote: > ISTM there is no difference between > VACUUM a, b > and > VACUUM a; VACUUM b; > > If we want to keep the code simple we must surely consider whether the > patch has any utility. Yes, this is true, but I think the convenience

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

"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 extension of the > VACUUM command,

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

Pavel Stehule writes: > 2. what syntax we should to use (if we accept this feature)? There was not > another proposal if I remember well - The PRAGMA syntax is strong because > we can very well specify to range where the plans caching will be > explicitly controlled. It

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

2017-09-05 19:38 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2. what syntax we should to use (if we accept this feature)? There was > not > > another proposal if I remember well - The PRAGMA syntax is strong because > > we can very well specify

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

Hello Tom, * 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 'x' construct in pl/pgsql, or the sqlstate attribute

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

Fabien COELHO writes: >> * It might be better if SQLSTATE and ERROR_MESSAGE were left >> unchanged by a non-error query. > Hmmm. I'm not sure. If so, ERROR_MESSAGE should be LAST_ERROR_MESSAGE > maybe? Then what about LAST_ERROR_SQLSTATE to go with it, and let SQLSTATE > &

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

Simon Riggs writes: > 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. Huh? The variable will be set in any case. It should be correct for any server version we might find in

Re: [HACKERS] Fix performance of generic atomics

Hi, On 05/25/2017 11:12 AM, Sokolov Yura wrote: I agree that lonely semicolon looks bad. Applied your suggestion for empty loop body (/* skip */). Patch in first letter had while(true), but I removed it cause I think it is uglier: - `while(true)` was necessary for grouping read with `if`, -

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

I wrote: > Huh? The variable will be set in any case. It should be correct for any > server version we might find in the wild --- so far as I can tell from the > commit history, every version supporting FE/BE protocol version 3 has sent > server_version at connection start. With a pre-7.4

Re: [HACKERS] Fix performance of generic atomics

Jesper Pedersen writes: > I have tested this patch on a 2-socket machine, but don't see any > performance change in the various runs. However, there is no regression > either in all cases. Hm, so if we can't demonstrate a performance win, it's hard to justify

Re: [HACKERS] Fix performance of generic atomics

On 09/05/2017 02:24 PM, Tom Lane wrote: Jesper Pedersen writes: I have tested this patch on a 2-socket machine, but don't see any performance change in the various runs. However, there is no regression either in all cases. Hm, so if we can't demonstrate a

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

On 5 September 2017 at 11:58, Konstantin Knizhnik wrote: > > I wonder if we can perform some optimization in this case (assuming that in > typical cases column either contains mostly non-null values, either mostly > null values). If you really wanted to go crazy here

Re: [HACKERS] Fix performance of generic atomics

Jesper Pedersen writes: > On 09/05/2017 02:24 PM, Tom Lane wrote: >> Hm, so if we can't demonstrate a performance win, it's hard to justify >> risking touching this code. What test case(s) did you use? > I ran pgbench (-M prepared) with synchronous_commit 'on' and

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

On 2017-09-05 19:43:33 +0100, Greg Stark wrote: > On 5 September 2017 at 11:58, Konstantin Knizhnik > wrote: > > > > I wonder if we can perform some optimization in this case (assuming that in > > typical cases column either contains mostly non-null values, either

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

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 does not have expressions (yet), it just handles TRUE/ON/1 and FALSE/0/OFF. Do we need

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

Huh? The variable will be set in any case. It should be correct for any server version we might find in the wild --- so far as I can tell from the commit history, every version supporting FE/BE protocol version 3 has sent server_version at connection start. With a pre-7.4 server, it looks

Re: [HACKERS] A note about debugging TAP failures

> On 05 Sep 2017, at 18:37, Peter Eisentraut > wrote: > > On 4/25/17 11:00, Daniel Gustafsson wrote: >> Makes sense, assuming a “clean slate” to run on seems a reasonable assumption >> for the test and it makes for simpler code in PostgresNode. Updated the >>

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

* It might be better if SQLSTATE and ERROR_MESSAGE were left unchanged by a non-error query. Hmmm. I'm not sure. If so, ERROR_MESSAGE should be LAST_ERROR_MESSAGE maybe? Then what about LAST_ERROR_SQLSTATE to go with it, and let SQLSTATE & ERROR_MESSAGE reflect the last command, and ERROR is

Re: [HACKERS] assorted code cleanup

On 8/29/17 03:32, Ryan Murphy wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:tested, passed > > I've

Re: [HACKERS] assorted code cleanup

On 8/21/17 01:11, Michael Paquier wrote: >> - Drop excessive dereferencing of function pointers > > - (*next_ProcessUtility_hook) (pstmt, queryString, > + next_ProcessUtility_hook(pstmt, queryString, > context, params, queryEnv, >

Re: [HACKERS] Proposal for changes to recovery.conf API

> On 27 Mar 2017, at 10:27, Simon Riggs wrote: > > On 7 March 2017 at 23:31, Josh Berkus wrote: >> On 03/02/2017 07:13 AM, David Steele wrote: >>> Hi Simon, >>> >>> On 2/25/17 2:43 PM, Simon Riggs wrote: On 25 February 2017 at 13:58, Michael Paquier

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

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 wrote: Agreed, but I'd vote for fixing this in v10

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

On 4 September 2017 at 09:06, Alexander Korotkov wrote: > Aborting read-only query on standby because of vacuum on master seems to be > rather unexpected behaviour for user when hot standby feedback is on. > I think we should work on this problem for v11. Happy to

Re: [HACKERS] Should we cacheline align PGXACT?

> On 04 Apr 2017, at 14:58, David Steele wrote: > > On 4/4/17 8:55 AM, Alexander Korotkov wrote: >> On Mon, Apr 3, 2017 at 9:58 PM, Andres Freund > >>I'm inclined to push this to the next CF, it seems we need a lot more >>benchmarking here. >>

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

On Tue, Sep 5, 2017 at 4:34 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > I have fixed the issues which were marked as TODOs in the attached > patches. Also, I have included your test change patch in my series of > patches. Are there any other issues you have commented out? > >

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Wed, May 10, 2017 at 5:55 AM, Amit Langote wrote: > On 2017/05/09 22:52, Mark Dilger wrote: >> >>> On May 9, 2017, at 12:18 AM, Amit Langote >>> wrote: >>> >>> Hi, >>> >>> On 2017/05/05 9:38, Mark Dilger wrote: Hackers,

Re: [HACKERS] Proposal: pg_rewind to skip config files

On Tue, Sep 5, 2017 at 12:54 PM, Vladimir Borodin wrote: > > 5 сент. 2017 г., в 12:31, Chris Travers > написал(а): > > I think the simplest solution for now is to skip any files ending in > .conf, .log, and serverlog. > > > Why don’t you want to solve

  1   2   >