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] 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] 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] [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] 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] 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 >>

[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] 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

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] 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

[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] 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] 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] 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] 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 ;

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] 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] 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 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] 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] 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] 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] 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

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] 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] 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] [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] [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] 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] 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 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

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] 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] [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

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] 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] 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] [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] 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] [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] [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] 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] [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] 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] [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] 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] [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] [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] [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] 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] 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] 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] [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] [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] [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] 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] 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] 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] 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] 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] 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

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] 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] 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

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

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

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] 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

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 >

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

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

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

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

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

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

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

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

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] 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

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.

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] 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] 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] 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] 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

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

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

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.

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

> 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

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

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:

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,

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 > wrote: 0002-heap-page-special-1.patch Putting xid and multixact bases into PageHeaderData would take extra 16 bytes

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

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

[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 >

  1   2   >