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] https://www.postgresql.org/message-id/CAOgcT0ONgwajdtkoq%2

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 si

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, Postgr

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 which lacks a newline b

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 pre

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 0

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 working with the previous

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 sti

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 skip when scanning the directory of the target remotely >

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 parts. May be they

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: > > > https://www.postgresql.org/docs/devel/static/runtime-config-client.html > > > > > VACUUM performs an aggressive scan >

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 trying to VACUUM multiple specific > > tables. > > > > postgres=# vacuum a, b; > > ERROR: syntax error at or near "," > > LINE 1:

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 CREATE > > EXENSION i

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 ( >>>TEMPLATE = pg_catalog.simple, >>>"STOPWORds" = english

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 >> possibility could have been that I change the cod

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 enough; for example,

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 for reference. Tha

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: > > > > A simple idea would be to pass as a parameter

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 those relations. Now that we >> crea

[HACKERS] [PATCH] Tests for reloptions

This thread continues discussion at https://www.postgresql.org/message-id/20170903094543.kkqdbdjuxwa5z6ji@alvherre.pgsql (Shortly: I refactored reloptions code, Alvaro offered to commit tests before the full patch) > I see that this patch adds a few tests for reloptions, for instance in > bloom

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

On Tue, Sep 5, 2017 at 3:03 AM, Alexander Korotkov wrote: > On Mon, Sep 4, 2017 at 2:04 PM, wrote: >> >> Our clients complain about this issue and therefore I want to raise the >> discussion and suggest several solutions to this problem: >> >> I. Why does PG use Fatal when Error is enough to rele

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал: > > I've just made sure that patch is still applyable to the current master. > > > > And I am still waiting for reviews :-) > > I see that this patch adds a few tests for reloptions, for instance in > bloom. I think we sh

Re: [HACKERS] Challenges preventing us moving to 64 bit transaction id (XID)?

Hi Alexander, On 22.06.2017 18:36, Alexander Korotkov wrote: On Wed, Jun 7, 2017 at 11:33 AM, Alexander Korotkov mailto:a.korot...@postgrespro.ru>> wrote: 0002-heap-page-special-1.patch Putting xid and multixact bases into PageHeaderData would take extra 16 bytes on index pages too. That wou

Re: [HACKERS] WAL logging problem in 9.4.3?

> On 13 Apr 2017, at 11:42, Kyotaro HORIGUCHI > wrote: > > At Thu, 13 Apr 2017 13:52:40 +0900, Michael Paquier > wrote in > >> On Tue, Apr 11, 2017 at 5:38 PM, Kyotaro HORIGUCHI >> wrote: >>> Sorry, what I have just sent was broken. >> >> You can use PROVE_TESTS when running make check to

Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

> On 18 Aug 2017, at 08:50, Andrey Borodin wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: tested, failed > Implements feature: tested, failed > Spec compliant: tested, failed > Documentation:tested, faile

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

Hi, lfirst_node() changes are missing for List node type and I was thinking about adding those. But it looks like we cannot do so as List can be a T_List, T_IntList, or T_OidList. So I am OK with that. Apart from this, changes look good to me. Everything works fine. As we are now doing it for lf

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

> 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 the problem once? It is a bit harder to get consensus on a way how to do it, but it seems that there are no

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

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 efficiency improvements, primarily to access columns with an absolute offset if all

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

On Tue, Sep 5, 2017 at 7: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. This is not a portable solution. Users can include configuration files with the n

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

On Mon, Sep 4, 2017 at 10:38 PM, Alvaro Herrera wrote: > I wonder how portable fnmatch() is in practice (which we don't currently > use anywhere). A shell glob seems a more natural interface to me for > this than a regular expression. On Windows you could use roughly PathMatchSpecEx, but it does

Re: [HACKERS] Protect syscache from bloating with negative cache entries

Thank you for reviewing this. At Sat, 2 Sep 2017 12:12:47 +1200, Thomas Munro wrote in > On Mon, Aug 28, 2017 at 9:24 PM, Kyotaro HORIGUCHI > wrote: > > This patch have had interferences from several commits after the > > last submission. I amended this patch to follow them (up to > > f97c55c)

Re: [HACKERS] Protect syscache from bloating with negative cache entries

Thank you for the comment. At Mon, 28 Aug 2017 21:31:58 -0400, Robert Haas wrote in > On Mon, Aug 28, 2017 at 5:24 AM, Kyotaro HORIGUCHI > wrote: > > This patch have had interferences from several commits after the > > last submission. I amended this patch to follow them (up to > > f97c55c), r

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 as proposed; I agree that just

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 help. My suggestion would be 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. >> >> No objections. > > This submission has

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? > > Th

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

On Tue, Sep 5, 2017 at 4:02 PM, Jeevan Chalke wrote: > Hi, > > lfirst_node() changes are missing for List node type and I was thinking > about adding those. But it looks like we cannot do so as List can be a > T_List, T_IntList, or T_OidList. So I am OK with that. Thanks for investigating the cas

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

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 matches the copyright in partition.c, >> but partition.c has: >> >>  * Portions

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, just FYI, I cannot find any regression test coverage of th

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 the problem once? It is a bit harder to get

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

> 5 сент. 2017 г., в 14:04, Michael Paquier > написал(а): > >> For example, in archive_command we put WALs for archiving from >> pg_xlog/pg_wal into another directory inside PGDATA and than another cron >> task makes real archiving. This directory ideally should be skipped by >> pg_rewind, but

Re: [HACKERS] Disallowing multiple queries per PQexec()

On 6/14/17 10:05, Surafel Temesgen wrote: > PGC_POSTMASTER implies that it's an instance-wide setting. > Is is intentional? I can understand that it's more secure for this > not to > be changeable in an existing session, but it's also much less usable > if you > can't set it

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

On Tue, Sep 5, 2017 at 1:04 PM, Michael Paquier wrote: > On Tue, Sep 5, 2017 at 7: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. > > This is

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

On Tue, Sep 5, 2017 at 2:40 PM, Vladimir Borodin wrote: > > 5 сент. 2017 г., в 14:04, Michael Paquier > написал(а): > > For example, in archive_command we put WALs for archiving from > pg_xlog/pg_wal into another directory inside PGDATA and than another cron > task makes real archiving. This dir

Re: [HACKERS] Making clausesel.c Smarter

> On 09 Apr 2017, at 12:14, David Rowley wrote: > > On 8 April 2017 at 09:33, Claudio Freire wrote: >> Otherwise, the patch LGTM, but I'd like to solve the quadratic >> behavior too... are you going to try? Otherwise I could take a stab at >> it myself. It doesn't seem very difficult. > > I ha

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

On Tue, Sep 5, 2017 at 9:40 PM, Vladimir Borodin wrote: > We do compress WALs and send them over network. Doing it via archive_command > in single thread is sometimes slower than new WALs are written under heavy > load. Ah, yeah, true. I do use pg_receivexlog --compress for that locally and do a

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

> On 08 Apr 2017, at 09:42, Pavel Stehule wrote: > > 2017-04-08 2:30 GMT+02:00 Peter Eisentraut >: > On 4/6/17 14:32, Pavel Stehule wrote: > > I like to see any proposals about syntax or implementation. > > > > Using PRAGMA is one variant - introduced by

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

> 5 сент. 2017 г., в 15:42, Chris Travers написал(а): > > On Tue, Sep 5, 2017 at 2:40 PM, Vladimir Borodin > wrote: > >> 5 сент. 2017 г., в 14:04, Michael Paquier > > написал(а): >> >>> For example, in archive_command we put WALs for

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

Fabien COELHO writes: >>> I run the test, figure out the number it found in the resulting >>> error message, and update the number in the source. >> Yeah, but then what error is all that work protecting you from? > I'm not sure I understand your point. I agree that Perl doing the counting > may

Re: [HACKERS] [PATCH] Improve geometric types

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 LGTM. The new status of this patch is: Ready for Committer

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

On 6/9/17 02:08, Michael Paquier wrote: > On Wed, Jun 7, 2017 at 9:20 AM, Michael Paquier > wrote: >> While it is possible to tackle some of those issues independently, >> like pg_basebackup stuff, it seems to me that it would be helpful to >> make the tests more deterministic by having an --endpo

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

> 5 сент. 2017 г., в 15:48, Michael Paquier > написал(а): > > On Tue, Sep 5, 2017 at 9:40 PM, Vladimir Borodin wrote: >> We do compress WALs and send them over network. Doing it via archive_command >> in single thread is sometimes slower than new WALs are written under heavy >> load. > > Ah,

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

Sandro Santilli writes: > On Wed, Aug 30, 2017 at 06:01:58PM -0400, Tom Lane wrote: >> We intentionally *don't* do that; pg_dump goes to a lot of trouble to >> duplicate the old extension contents exactly, instead. There are a bunch >> of corner cases that would fail if we allowed the new install

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 wrote: > - trigger_file

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: http://www.postgresql.org/mailpref/pgsql-hacke

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 indent for the > variable

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 my

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] 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 2:43 PM, Simon Riggs wrote: > On 25 February 2017 at 1

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 o

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 libpq/fe-print.c. That's not used by p

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 examining the PAGER > environment variable, namely

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 some hot code paths, xlogin

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 of >> psql's own version. Add VERSION_NAME t

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 \if, I'm not seeing a

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 fai

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 efficie

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 s

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 adding them to the 9.x branches. >> Given the lac

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 factor is a bit understa

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. T

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, one that I, like others much earlier in this

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, Pavel Stehule wrote: > > > I like to see an

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 this patch? If so, I'll set the CF entry back to

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 is well readable and static

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 results in an error as on HEA

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 \if would have these variables. >>> However, I'm less enthused ab

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 to range where the plans caching will be > > ex

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 the wild --- so far as I c

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 o

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 > & ERROR_MESSAGE reflect

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`, - but

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 server

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 risking touching this code. What t

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 performance win, it's hard to justify

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 you could do lookup tables of

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 'off' using > both logged 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 mostly > > null values). > > If

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 lik

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 >> patch >> which now have static dat

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 revie

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] 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, flinfo)) > I think there is no los

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 runs. However, there is no regression >>> either in all ca

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 check passes. > Here are both the patches rebased on the latest sour

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. I would suggest to move

  1   2   >