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

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

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

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

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

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 >

[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

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

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

[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

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

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

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

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

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

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

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

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

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.

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

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 >

[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

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

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

[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

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

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.

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

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 >

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

[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

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

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

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

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

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

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

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 >

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

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 ( > ..., >

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

[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

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,

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

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

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

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

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

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

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

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

[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

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.

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

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

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:

Re: [HACKERS] expanding inheritance in partition bound order

On Thu, Aug 31, 2017 at 1:15 AM, 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

Re: [HACKERS] UPDATE of partition key

On Fri, Aug 11, 2017 at 10:44 AM, Amit Khandekar wrote: > On 4 August 2017 at 22:28, Amit Khandekar wrote: >>> I am planning to review and test this patch, Seems like this patch needs to be rebased. [dilip@localhost postgresql]$ patch -p1 <

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

On Wed, Aug 30, 2017 at 2:00 AM, Robert Haas wrote: > > I suggest defining a TBM_FILLFACTOR constant instead of repeating the > value 0.9 in a bunch of places. I think it would also be good to try > to find the sweet spot for that constant. Making it bigger reduces > the

[HACKERS] Hooks to track changed pages for backup purposes

Hi hackers! 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], but here I start separate thread since Subj