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

On Thu, Aug 31, 2017 at 4:35 PM, Fabien COELHO wrote: > > Hello Masahiko-san, > >> [...] Personally I prefer "t" for table creation because "c" for create is >> a generic word. We might want to have another initialization command that >> creates something. > > > Ok, good point. > > > About the pat

Re: [HACKERS] CLUSTER command progress monitor

Hi Thomas, Any comments or suggestion are welcome. Although this patch updates src/test/regress/expected/rules.out I think perhaps you included the wrong version? That regression test fails for me Thanks for the comment. I use the patch on 7b69b6ce and it's fine. Did you use "initdb" comma

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2017/08/26 1:43, Robert Haas wrote: On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita wrote: I agree, but I wonder if we ought to make it work first using the existing APIs and then add these new APIs as an optimization. I'm not sure that's a good idea because that once we support INSERT tup

Re: [HACKERS] Surjective functional indexes

On 1 September 2017 at 05:40, Thomas Munro wrote: > On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik > wrote: >> Attached please find rebased version of the patch. >> Now "projection" attribute is used instead of surjective/injective. > > Hi Konstantin, > > This still applies but it doesn't co

Re: [HACKERS] Hooks to track changed pages for backup purposes

Thank you for your reply, Michael! Your comments are valuable, especially in the world of backups. > 31 авг. 2017 г., в 19:44, Michael Paquier > написал(а): > Such things are not Postgres-C like. Will be fixed. > I don't understand what xlog_begin_insert_hook() is good for. memset control str

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

On 17 May 2017 at 08:38, Tsunakawa, Takayuki wrote: > From: Michael Paquier [mailto:michael.paqu...@gmail.com] >> On Fri, Mar 31, 2017 at 9:58 PM, Ashutosh Bapat >> wrote: >> > Then the question is why not to allow savepoints as well? For that we >> > have to fix transaction block state machine.

Re: [HACKERS] CLUSTER command progress monitor

On Thu, Aug 31, 2017 at 2:12 PM, Tatsuro Yamada wrote: > Any comments or suggestion are welcome. Although this patch updates src/test/regress/expected/rules.out I think perhaps you included the wrong version? That regression test fails for me -- Thomas Munro http://www.enterprisedb.com -- S

Re: [HACKERS] SERIALIZABLE with parallel query

On Wed, Jun 28, 2017 at 11:21 AM, Thomas Munro wrote: > [ssi-parallel-v5.patch] Rebased. -- Thomas Munro http://www.enterprisedb.com ssi-parallel-v6.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: htt

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

On Fri, Sep 1, 2017 at 12:25 AM, Bossart, Nathan wrote: > On 8/31/17, 2:24 AM, "Masahiko Sawada" wrote: >> I reviewed these patches and found a issue. > > Thanks for reviewing. > >> autovacuum worker seems not to work fine. I got an error message; >> >> ERROR: unrecognized node type: 0 >> CONTEX

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Tue, Aug 1, 2017 at 12:53 AM, Peter Moser wrote: > On 06.04.2017 01:24, Andres Freund wrote: >> >> Unfortunately I don't think this patch has received sufficient design >> and implementation to consider merging it into v10. As code freeze is >> in two days, I think we'll have to move this to t

Re: [HACKERS] Surjective functional indexes

On Fri, Jun 9, 2017 at 8:08 PM, Konstantin Knizhnik wrote: > Attached please find rebased version of the patch. > Now "projection" attribute is used instead of surjective/injective. Hi Konstantin, This still applies but it doesn't compile after commits 2cd70845 and c6293249. You need to change

Re: [HACKERS] adding the commit to a patch's thread

On Fri, Sep 1, 2017 at 1:11 PM, Erik Rijkers wrote: > Would it be possible to change the commitfest a bit and make it possible to > add the commit (or commit-message, or hash) to the thread in the > commitfest-app. I would think it would be best to make it so that when the > thread gets set to st

[HACKERS] adding the commit to a patch's thread

At the moment it's not easy to find the commit that terminates a commitfest thread about a patch. One has to manually compare dates and guess what belongs to what. The commit message nowadays often has the link to the thread ("Discussion") but the other way around is often not so easily found

Re: [HACKERS] Creating backup history files for backups taken from standbys

On Thu, Aug 10, 2017 at 4:55 PM, Masahiko Sawada wrote: > On Thu, Aug 10, 2017 at 4:50 PM, Michael Paquier > wrote: >> On Thu, Aug 10, 2017 at 9:45 AM, Masahiko Sawada >> wrote: >>> Thank you for the patch. Regarding to creating the backup history file >>> on stanbys, is there any difference fr

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

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 should be commited > separately,

[HACKERS] Upcoming commit fest will begin soon

Hi all, At the moment of this email, it is 15:25 AOE, so you still have close to 8 hours to register patches for the upcoming the commit fest: https://commitfest.postgresql.org/14/ This commit fest is large, as expected from any first commit fest for a new development cycle, with still close to 2

Re: bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On Fri, Sep 1, 2017 at 4:49 AM, Peter Eisentraut wrote: > On 5/30/17 23:10, Peter Eisentraut wrote: >> Here is a proposed solution that splits bgw_name into bgw_type and >> bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. >> Uses of application_name are removed, because they ar

Re: [HACKERS] Hash Functions

Robert Haas writes: > On Thu, Aug 31, 2017 at 10:55 PM, Tom Lane wrote: >> ALTER OPERATOR FAMILY ADD FUNCTION ... ? >> >> That would result in the functions being considered "loose" in the >> family rather than bound into an operator class. I think that's >> actually the right thing, because th

Re: [HACKERS] Hash Functions

On Thu, Aug 31, 2017 at 10:55 PM, Tom Lane wrote: > Robert Haas writes: >> I think this takes care of adding not only the infrastructure but >> support for all the core data types, but I'm not quite sure how to >> handle upgrading types in contrib. It looks like citext, hstore, and >> several da

Re: [HACKERS] Hash Functions

Robert Haas writes: > I think this takes care of adding not only the infrastructure but > support for all the core data types, but I'm not quite sure how to > handle upgrading types in contrib. It looks like citext, hstore, and > several data types provided by isn have hash opclasses, and I think

Re: [HACKERS] Hash Functions

On Thu, Aug 31, 2017 at 8:40 AM, amul sul wrote: > Fixed in the attached version. I fixed these up a bit and committed them. Thanks. I think this takes care of adding not only the infrastructure but support for all the core data types, but I'm not quite sure how to handle upgrading types in con

Re: [HACKERS] Authentication mechanisms categorization

On Thu, Jul 20, 2017 at 01:00:50AM +0300, Álvaro Hernández Tortosa wrote: > I'm mostly convinced by the power of all the parameters that already > exist, given that you added both saslname and saslchannelbinding to the > already existing sslmode. That's great, and allows for very fine choosing

Re: [HACKERS] Re: [PATCH] Fix drop replication slot blocking instead of returning error

On Tue, Aug 29, 2017 at 12:04:33PM +0200, Alvaro Herrera wrote: > Noah Misch wrote: > > On Thu, Aug 24, 2017 at 03:38:20PM +0200, Simone Gotti wrote: > > > I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an > > > active slot will block until it's released instead of returnin

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On Fri, Sep 1, 2017 at 5:11 AM, David Steele wrote: > On 8/31/17 4:04 PM, Robert Haas wrote: >> On Wed, Aug 30, 2017 at 8:37 PM, Michael Paquier >> wrote: >>> Thanks for the new version. This looks fine to me. >> >> Committed to REL9_6_STABLE with minor wordsmithing. > > The edits look good to me

[HACKERS] Visual Studio 2017 Build Support

Hello, This is with respect to the original thread on "visual studio 2017 build support" created by Haribabu Kommi (kommi.harib...@gmail.com). https://www.postgresql.org/message-id/CAJrrPGc

Re: [HACKERS] static assertions in C++

On Thu, Aug 31, 2017 at 6:37 PM, Tom Lane wrote: > Meh. We support ancient versions of C for backwards compatibility > reasons, but considering that compiling backend code with C++ isn't > officially supported at all, I'm not sure we need to cater to ancient > C++ compilers. We could quibble abo

Re: [HACKERS] static assertions in C++

Robert Haas writes: > On Thu, Aug 31, 2017 at 4:43 PM, Peter Eisentraut > wrote: >> As discussed in >> , a >> more general solution would be to add specific C++ support for static >> assertions in c.h. Here is a patch for that,

Re: [HACKERS] static assertions in C++

On Thu, Aug 31, 2017 at 4:43 PM, Peter Eisentraut wrote: > Commit df1a699e5ba3232f373790b2c9485ddf720c4a70 introduced a > StaticAssertStmt() into a header file, which will fail if a module > written in C++ uses that header file. Currently, that header file is > not widely used, but it's a potenti

[HACKERS] static assertions in C++

Commit df1a699e5ba3232f373790b2c9485ddf720c4a70 introduced a StaticAssertStmt() into a header file, which will fail if a module written in C++ uses that header file. Currently, that header file is not widely used, but it's a potential problem if the use of static assertions expands. As discussed

Re: [HACKERS] sync process names between ps and pg_stat_activity

Peter Eisentraut writes: > As an aside, is there a reason why the archiver process is not included > in pg_stat_activity? It's not connected to shared memory. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On 8/31/17 4:04 PM, Robert Haas wrote: > On Wed, Aug 30, 2017 at 8:37 PM, Michael Paquier > wrote: >> Thanks for the new version. This looks fine to me. > > Committed to REL9_6_STABLE with minor wordsmithing. The edits look good to me. Thanks, Robert! -- -David da...@pgmasters.net -- Sent v

Re: [HACKERS] Update low-level backup documentation to match actual behavior

On Wed, Aug 30, 2017 at 8:37 PM, Michael Paquier wrote: > Thanks for the new version. This looks fine to me. Committed to REL9_6_STABLE with minor wordsmithing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (

[HACKERS] sync process names between ps and pg_stat_activity

The process names shown in pg_stat_activity.backend_type as of PG10 and the process names used in the ps display are in some cases gratuitously different, so here is a patch to make them more alike. Of course it could be debated in some cases which spelling was better. As an aside, is there a rea

Re: [HACKERS] expanding inheritance in partition bound order

On Thu, Aug 31, 2017 at 2:56 AM, Ashutosh Bapat wrote: > Here are the patches revised a bit. I have esp changed the variable > names and arguments to reflect their true role in the functions. Also > updated prologue of expand_single_inheritance_child() to mention > "has_child". Let me know if thos

bgw_type (was Re: [HACKERS] Why does logical replication launcher set application_name?)

On 5/30/17 23:10, Peter Eisentraut wrote: > Here is a proposed solution that splits bgw_name into bgw_type and > bgw_name_extra. bgw_type shows up in pg_stat_activity.backend_type. > Uses of application_name are removed, because they are no longer > necessary to identity the process type. Updated

Re: [HACKERS] expanding inheritance in partition bound order

On Thu, Aug 31, 2017 at 3:36 AM, Amit Langote wrote: > ISTM, the primary motivation for the EIBO patch at this point is to get > the partitions ordered in a predictable manner so that the partition-wise > join patch and update partition key patches could implement certain logic > using O (n) algor

Re: [HACKERS] Parallel worker error

On Wed, Aug 30, 2017 at 11:19 AM, Robert Haas wrote: > But since that's an established design fl^H^Hprinciple, maybe that > means we should go with the approach of teaching SerializeGUCState() > to ignore role altogether and instead have ParallelWorkerMain call > SetCurrentRoleId using information

Re: [HACKERS] Assorted leaks and weirdness in parallel execution

On Thu, Aug 31, 2017 at 2:13 PM, Tom Lane wrote: > Yeah, it is different. What I'm looking at is that nodeGather does > DestroyTupleQueueReader as soon as it's seen EOF on a given tuple queue. > That can't save any worker cycles. The reason seems to be that it wants > to collapse its array of Tu

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

Hello all, While working on checksum support for GPDB, we noticed that several callers of PageGetLSN() didn't follow the correct locking procedure. To try to help ferret out present and future mistakes, we added an assertion to PageGetLSN() that checks whether those locks were being held correctly

Re: [HACKERS] Assorted leaks and weirdness in parallel execution

Robert Haas writes: > On Thu, Aug 31, 2017 at 11:09 AM, Tom Lane wrote: >> (With this patch, >> there are no callers of shm_mq_get_queue(); should we remove that?) > May as well. I can't remember any more why I did shm_mq_detach() that > way; I think there was someplace where I thought that the

Re: [HACKERS] The case for removing replacement selection sort

On Wed, Aug 30, 2017 at 4:59 PM, Peter Geoghegan wrote: > I may submit the simple patch to remove replacement selection, if > other contributors are receptive. Apart from everything else, the > "incrementalism" of replacement selection works against cleverer batch > memory management of the type I

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Thu, Aug 31, 2017 at 2:26 AM, Dilip Kumar wrote: > Thanks for the feedback. I will work on it. Another thought is that you probably want/need to test across a range of work_mem values. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via

[HACKERS] GnuTLS support

Hi, I have seen discussions from time to time about OpenSSL and its licensing issues so I decided to see how much work it would be to add support for another TLS library, and I went with GnuTLS since it is the library I know best after OpenSSL and it is also a reasonably popular library. A

Re: [HACKERS] Assorted leaks and weirdness in parallel execution

On Thu, Aug 31, 2017 at 11:09 AM, Tom Lane wrote: > I complained a couple weeks ago that nodeGatherMerge looked like it > leaked a lot of memory when commanded to rescan. Attached are three > proposed patches that, in combination, demonstrably result in zero > leakage across repeated rescans. Go

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

I have attached a new, rebased version of the batch with most of Banck's and some of your feedback incorporated. Thanks for the good feedback! On 03/31/2017 08:27 AM, Michael Paquier wrote> When running REINDEX SCHEMA CONCURRENTLY public on the regression database I am bumping into a bunch of

[HACKERS] Assorted leaks and weirdness in parallel execution

I complained a couple weeks ago that nodeGatherMerge looked like it leaked a lot of memory when commanded to rescan. Attached are three proposed patches that, in combination, demonstrably result in zero leakage across repeated rescans. The first thing I noticed when I started digging into this wa

Re: [HACKERS] Hooks to track changed pages for backup purposes

On Thu, Aug 31, 2017 at 3:02 PM, Andrey Borodin wrote: > Here is the patch with hooks that I consider sufficient for implementation of > incremental backup with pages tracking as extension. > > Recently I was posting these things to the thread "Adding hook in BufferSync > for backup purposes" [0

Re: [HACKERS] multiple target of VACUUM command

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: vacuum a, b; > > This patch just allows multiple targets for VACUUM command. There is

Re: [HACKERS] generated columns

On 31 August 2017 at 05:16, Peter Eisentraut wrote: > Here is another attempt to implement generated columns. This is a > well-known SQL-standard feature, also available for instance in DB2, > MySQL, Oracle. A quick example: > > CREATE TABLE t1 ( > ..., > height_cm numeric, > heigh

Re: [HACKERS] Parallel Hash take II

Here's a new rebased and debugged patch set. On Tue, Aug 1, 2017 at 1:11 PM, Andres Freund wrote: > - Echoing concerns from other threads (Robert: ping): I'm doubtful that > it makes sense to size the number of parallel workers solely based on > the parallel scan node's size. I don't think i

[HACKERS] multiple target of VACUUM command

Hello, I sometimes feel annoyed when trying to VACUUM multiple specific tables. postgres=# vacuum a, b; ERROR: syntax error at or near "," LINE 1: vacuum a, b; This patch just allows multiple targets for VACUUM command. regards, -- Kyotaro Horiguchi NTT Open Source Software Center >From 4816

Re: [HACKERS] asynchronous execution

At Thu, 03 Aug 2017 09:30:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170803.093057.261590619.horiguchi.kyot...@lab.ntt.co.jp> > > Unfortunately, that's probably another gigantic patch (that > > should probably be written by Andres). > > Yeah, but async executor on the current

Re: [HACKERS] log_destination=file

Magnus Hagander writes: > On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: >> Right, because the decision whether to redirect stdout/stderr can't >> be changed on the fly. > Right. > We could of course also say we only care about things generated by our > ereport framework, in which case we don

Re: [HACKERS] Hash Functions

On Wed, Aug 30, 2017 at 9:05 PM, Robert Haas wrote: > On Wed, Aug 30, 2017 at 10:43 AM, amul sul wrote: > > Thanks for the suggestion, I have updated 0002-patch accordingly. > > Using this I found some strange behaviours as follow: > > > > 1) standard and extended0 output for the jsonb_hash case

Re: [HACKERS] log_destination=file

On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > Magnus Hagander writes: > > My understanding is that the main reason for this is that we cannot > change > > logging_collector without restarting postmaster, whereas we can change > > log_destination. > > Right, because the decision whether to r

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

Hello Nikolay, Thanks for the review! As for function names, committers can have their say. I'm somehow not dissatisfied with the current version, but I also agree with you that they are imperfect. As for included bug fixes, I can do separate patches, but I think that it is enough to first

Re: [HACKERS] log_destination=file

Magnus Hagander writes: > My understanding is that the main reason for this is that we cannot change > logging_collector without restarting postmaster, whereas we can change > log_destination. Right, because the decision whether to redirect stdout/stderr can't be changed on the fly. > My suggest

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

Hi All! 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 should be commited separately, then Fabien will split them, I think. 1. The tests.

Re: [HACKERS] Function to move the position of a replication slot

On Thu, Aug 17, 2017 at 2:19 AM, Craig Ringer wrote: > On 17 August 2017 at 07:30, Michael Paquier > wrote: > >> >> Definitely agreed on that. Any move function would need to check if >> the WAL position given by caller is already newer than what's >> available in the local pg_wal (minimum of al

Re: [HACKERS] More replication race conditions

On 27 August 2017 at 03:32, Noah Misch wrote: > On Fri, Aug 25, 2017 at 12:09:00PM +0200, Petr Jelinek wrote: >> On 24/08/17 19:54, Tom Lane wrote: >> > sungazer just failed with >> > >> > pg_recvlogical exited with code '256', stdout '' and stderr >> > 'pg_recvlogical: could not send replication

[HACKERS] log_destination=file

Attached is a very much VIP (AKA rough draft) for $subject. Right now we have two parameters controlling logging destination, and they work in interesting combinations: log_destination=stderr, logging_collector=off -> log to stderr (makes sense) log_destination=stderr, logging_collector=on -> lo

[HACKERS] CurrentUserId may be invalid during the rest of a session

Hi, During the first transaction starting phase within a backend, if there is an 'ereport' after setting transaction state but before saving CurrentUserId into 'prevUser' in 'TransactionStateData', CurrentUserId will be invalid in the rest of the session. Take branch 'REL9_6_STABLE' for example:

Re: [HACKERS] Range Merge Join v1

On Fri, Aug 25, 2017 at 10:19 AM, Alexander Kuzmenkov wrote: > Hi Jeff, Hi, Thank you for the review and suggestions! > * At the moment, "mergejoinable clause" and "equality clause" mean the same > thing to the planner, and those clauses are used both to create equivalence > classes and to perf

Re: [HACKERS] UPDATE of partition key

Thanks Dilip. I am working on rebasing the patch. Particularly, the partition walker in my patch depended on the fact that all the tables get opened (and then closed) while creating the tuple routing info. But in HEAD, now only the partitioned tables get opened. So need some changes in my patch. T

Re: [HACKERS] expanding inheritance in partition bound order

On 2017/08/31 4:45, Robert Haas wrote: > On Wed, Aug 30, 2017 at 12:47 PM, Ashutosh Bapat > wrote: >> +1. I think we should just pull out the OIDs from partition descriptor. > > Like this? The first patch refactors the expansion of a single child > out into a separate function, and the second pa

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

Hello Masahiko-san, [...] Personally I prefer "t" for table creation because "c" for create is a generic word. We might want to have another initialization command that creates something. Ok, good point. About the patch: applies, compiles, works for me. A few minor comments. While re-read

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

On Thu, Aug 31, 2017 at 10:52 AM, Bossart, Nathan wrote: > On 8/30/17, 5:37 PM, "Michael Paquier" wrote: >> +VacuumRelation * >> +makeVacuumRelation(RangeVar *relation, List *va_cols, Oid oid) >> +{ >> + VacuumRelation *vacrel = makeNode(VacuumRelation); >> + vacrel->relation = relation; >> +

Re: [HACKERS] Parallel Append implementation

The last updated patch needs a rebase. Attached is the rebased version. Thanks -Amit Khandekar ParallelAppend_v13_rebased_3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailp