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

On 8/23/17, 11:59 PM, "Michael Paquier" wrote: > Robert, Amit and other folks working on extending the existing > partitioning facility would be in better position to answer that, but > I would think that we should have something as flexible as possible, > and storing a

Re: [HACKERS] proposal: psql command \graw

Hello, I'll wait to winter commitfest Argh, sorry, I put it in the September commitfest, and it seems that it cannot be changed afterwards. Maybe you can close it and redeclare it in the commitfest you want? for some other ideas, tests, comments - it is topic for PostgreSQL 11, and then

Re: [HACKERS] proposal: psql command \graw

2017-08-24 17:27 GMT+02:00 Fabien COELHO : > > Hello, > > I'll wait to winter commitfest >> > > Argh, sorry, I put it in the September commitfest, and it seems that it > cannot be changed afterwards. > > Maybe you can close it and redeclare it in the commitfest you want? >

Re: [HACKERS] Page Scan Mode in Hash Index

On 08/24/2017 01:21 AM, Ashutosh Sharma wrote: Done. Attached are the patches with above changes. Thanks ! Based on the feedback in this thread, I have moved the patch to "Ready for Committer". Best regards, Jesper -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] Thoughts on unit testing?

On 13.08.2017 21:19, Peter Geoghegan wrote: On Thu, Aug 10, 2017 at 2:53 PM, Thomas Munro wrote: The current regression tests, isolation tests and TAP tests are very good (though I admit my experience with TAP is limited), but IMHO we are lacking support for

Re: [HACKERS] Explicit relation name in VACUUM VERBOSE log

Alvaro Herrera writes: > Michael Paquier wrote: >> Hm. I am not sure what you have in mind here. > I'm thinking that this data is useful to analyze as a stream of related > events, rather than as individual data points. Grepping logs in order to > extract the numbers

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Robert Haas writes: > On Wed, Aug 23, 2017 at 6:55 PM, Douglas Doole wrote: >> From previous experience, pushing the limit to the workers has the potential >> to be a big win . > Here's a not-really-tested draft patch for that. Both this patch and

Re: [HACKERS] Updating line length guidelines

[ returning from the wilds of Kentucky... ] Stephen Frost writes: > * Craig Ringer (cr...@2ndquadrant.com) wrote: >> Personally I'd be fine with 100 or so, but when I'm using buffers side by >> side, or when I'm working in poor conditions where I've set my terminal to >>

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

Hi all, I noticed that in postgres 10beta3, calling pg_drop_replication_slot on an active slot will block until it's released instead of returning an error like done in pg 9.6. Since this is a change in the previous behavior and the docs wasn't changed I made a patch to restore the previous

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

Hi Michael, Thanks for reviewing! Sorry for the late response, those eclipses don't just chase themselves... On 8/20/17 10:22 PM, Michael Paquier wrote: > On Fri, Aug 18, 2017 at 3:35 AM, David Steele wrote: > > + Prior to PostgreSQL 9.6, this > Markup ? Fixed. > +

[HACKERS] MCXT_ALLOC_NO_OOM -> DSA_ALLOC_NO_OOM in dsa.c

Hi hackers, I spotted a (harmless) thinko in dsa.c. Please see attached. -- Thomas Munro http://www.enterprisedb.com dsa-alloc-no-oom.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] POC: Sharing record typmods between backends

On Wed, Aug 23, 2017 at 11:58 PM, Thomas Munro wrote: > On Wed, Aug 23, 2017 at 5:46 PM, Andres Freund wrote: >> Notes for possible followup commits of the dshash API: >> - nontrivial portions of dsahash are essentially critical sections lest >>

[HACKERS] auto_explain : log queries with wrong estimation

Hi hackers, I try to made a patch to auto_explain in order to log queries with wrong estimation. I compare planned row id : queryDesc->planstate->plan->plan_rows Vs ntuples : queryDesc->planstate->instrument->ntuples; If I understand, instrumentation is used only with explain. So my patch

Re: [HACKERS] auto_explain : log queries with wrong estimation

On 24.08.2017 14:56, Adrien Nayrat wrote: Hi hackers, Hi, I try to made a patch to auto_explain in order to log queries with wrong estimation. I compare planned row id : queryDesc->planstate->plan->plan_rows Vs ntuples : queryDesc->planstate->instrument->ntuples; AFAICS you want to

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

> > No. You can't easily avoid recursion for the merge-append case, since > that has to descend to multiple children. Agreed. That's why it's not in the while loop in my sketch of the suggested rework. > TBH I dislike the fact that > you did the subquery case randomly differently from the

[HACKERS] More replication race conditions

sungazer just failed with pg_recvlogical exited with code '256', stdout '' and stderr 'pg_recvlogical: could not send replication command "START_REPLICATION SLOT "test_slot" LOGICAL 0/0 ("include-xids" '0', "skip-empty-xacts" '1')": ERROR: replication slot "test_slot" is active for PID

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Robert Haas writes: > Buildfarm members with force_parallel_mode=regress are failing now. I > haven't had a chance to investigate exactly what's going on here, but > I think there are probably several issues: > 1. It's definitely the case that the details about a sort

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

I wrote: > To get the buildfarm back to green, I agree with the suggestion of > setting force_parallel_mode=off for this test, at least for now. Actually, there's an easier way: we can just make the test table be TEMP. That is a good idea anyway to prevent possible interference from

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Douglas Doole writes: > My first thought was to do a regex over the explain output to mask the > troublesome value, but I couldn't figure out how to make it work and didn't > find an example (admittedly didn't spent a huge amount of time hunting > though). I'd love to see how

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

> > I don't greatly like the way that the regression test case filters > the output; it hides too much IMO. I'd be inclined to try to return > the EXPLAIN output with as much detail preserved as possible. Maybe > we could use regex substitution on lines of the output to get rid of > stuff that

Re: [HACKERS] type cache for concat functions

Hi Pavel, I tried applying your patch, it applies and compiles fine, check and checkworld pass. I ran a simple performance test, select concat(generate_series(1,10), ... [x5 total]) vs select generate_series(1,10)::text || ... . Operator || runs in 60 ms, while unpatched concat

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Douglas Doole writes: > Would we be better off moving those cases into the while loop I added to > avoid the recursion? No. You can't easily avoid recursion for the merge-append case, since that has to descend to multiple children. TBH I dislike the fact that you did the

Re: [HACKERS] Proposal: global index

My understanding is that global indexes allow foreign keys to work naturally with partitioned tables, or tables in an inheritance hierarchy. That is pretty big IMO, as it allows you to partition a table without making a trade-off in your database integrity.

Re: [HACKERS] Proposal: global index

On 08/24/2017 10:52 AM, Adam Brusselback wrote: My understanding is that global indexes allow foreign keys to work naturally with partitioned tables, or tables in an inheritance hierarchy. That is pretty big IMO, as it allows you to partition a table without making a trade-off in your

Re: [HACKERS] SCRAM salt length

On 8/17/17 17:00, Joe Conway wrote: >> Hence my original inquiry: "I suspect that this length was chosen based >> on the example in RFC 5802 (SCRAM-SHA-1) section 5. But the analogous >> example in RFC 7677 (SCRAM-SHA-256) section 3 uses a length of 16. >> Should we use that instead?" > Unless

Re: [HACKERS] obsolete code in pg_upgrade

On 8/23/17 09:36, Robert Haas wrote: > I think I agree. It seems to me that the version of pg_upgrade > shipped with release N only needs to support upgrades to release N, > not older releases. There's probably room for debate about whether a > pg_upgrade needs to support direct upgrades FROM

Re: [HACKERS] Regression stoping PostgreSQL 9.4.13 if a walsender is running

Hi, On 2017-08-22 19:28:22 +0200, Marco Nenciarini wrote: > I have noticed that after the 9.4.13 release PostgreSQL reliably fails > to shutdown with smart and fast method if there is a running walsender. > > The postmaster continues waiting forever for the walsender termination. > > It works

Re: [HACKERS] MCXT_ALLOC_NO_OOM -> DSA_ALLOC_NO_OOM in dsa.c

Hi, On 2017-08-24 23:08:52 +1200, Thomas Munro wrote: > I spotted a (harmless) thinko in dsa.c. Please see attached. Pushed to 10 and master. Thanks. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

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

On Thu, Aug 24, 2017 at 11:28 PM, Bossart, Nathan wrote: > I should also note that the dedupe_relations(...) function needs another > small fix for column lists. Since the lack of a column list means that we > should ANALYZE all columns, a duplicate table name with an empty

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

Douglas Doole writes: >> TBH I dislike the fact that >> you did the subquery case randomly differently from the existing cases; >> it should just have been added as an additional recursive case. Since >> this is done only once at query startup, worrying about hypothetical >>

Re: [HACKERS] Proposal: global index

Hi, On 2017-08-18 12:12:58 +0300, Ildar Musin wrote: > While we've been developing pg_pathman extension one of the most frequent > questions we got from our users was about global index support. We cannot > provide it within an extension. And I couldn't find any recent discussion > about someone

Re: [HACKERS] One-shot expanded output in psql using \gx

* Noah Misch (n...@leadboat.com) wrote: > On Tue, Aug 15, 2017 at 10:24:34PM +0200, Tobias Bussmann wrote: > > I've tested the new \gx against 10beta and current git HEAD. Actually one > > of my favourite features of PostgreSQL 10! However in my environment it was > > behaving strangely. After

Re: [HACKERS] taking stdbool.h into use

Peter Eisentraut writes: > Some not so long time ago, it was discussed to look into taking > stdbool.h into use. The reason was that third-party libraries (perl?, > ldap?, postgis?) are increasingly doing so, and having incompatible > definitions of bool

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

On Thu, Aug 24, 2017 at 10:49 PM, David Steele wrote: > Thanks for reviewing! Sorry for the late response, those eclipses don't > just chase themselves... That's quite something to see. > On 8/20/17 10:22 PM, Michael Paquier wrote: >> On Fri, Aug 18, 2017 at 3:35 AM, David

Re: [HACKERS] ECPG: WHENEVER statement with DO CONTINUE action

On Fri, Aug 18, 2017 at 5:20 PM, vinayak wrote: > > On 2017/06/20 17:35, vinayak wrote: >> >> Hi Sawada-san, >> >> On 2017/06/20 17:22, Masahiko Sawada wrote: >>> >>> On Tue, Jun 20, 2017 at 1:51 PM, vinayak >>> wrote:

Re: [HACKERS] proposal: psql command \graw

"column_header" is somehow redundant with "tuples_only". Use the existing one instead of adding a new one? It is different - a result of tuples_only is just tuples - not column names, not title, footer. I needed new special flag for enhancing tuples_only to print column names I do not

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

On Tue, Aug 22, 2017 at 5:15 PM, Fabien COELHO wrote: > >>> Why not allow -I as a short option for --custom-initialize? >> >> >> Other options for similar purpose such as --foreign-keys also have >> only a long option. Since I think --custom-initialize option is in the >>

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Aug 24, 2017 at 3:11 AM, Josh Berkus wrote: > On 08/22/2017 11:04 PM, Masahiko Sawada wrote: >> WARNING: what you did is ok, but you might have wanted to do something else >> >> First of all, whether or not that can properly be called a warning is >> highly debatable.

Re: [HACKERS] proposal: psql command \graw

2017-08-24 8:53 GMT+02:00 Fabien COELHO : > > "column_header" is somehow redundant with "tuples_only". Use the >>> existing one instead of adding a new one? >>> >> >> It is different - a result of tuples_only is just tuples - not column >> names, not title, footer. I needed

Re: [HACKERS] [PATCH v1] Add and report the new "in_hot_standby" GUC pseudo-variable.

Hi, On Wed, May 24, 2017 at 07:16:06AM +, Tsunakawa, Takayuki wrote: > I confirmed that the attached patch successfully provides: I was going to take a look at this, but the patch no longer applies cleanly for me: Hunk #1 succeeded at 1474 (offset 49 lines). Hunk #2 succeeded at 1762

Re: [HACKERS] coverage analysis improvements

On Wed, Aug 23, 2017 at 3:47 AM, Peter Eisentraut wrote: > On 8/21/17 01:23, Michael Paquier wrote: >> Patch 0001 fails to apply as of c629324. > > Updated patches attached. > >> Which versions of lcov and gcov did you use for your tests? > > LCOV version 1.13,

Re: [HACKERS] Default Partition for Range

Hi Beena, On Tue, Aug 22, 2017 at 5:22 PM, Beena Emerson wrote: > On Tue, Aug 22, 2017 at 4:20 PM, Beena Emerson > wrote: > > Hi Jeevan, > > > > On Tue, Aug 22, 2017 at 7:53 AM, Jeevan Ladhe > > wrote: > >> > >>

Re: [HACKERS] Default Partition for Range

Hello, On Thu, Aug 24, 2017 at 3:08 PM, Jeevan Ladhe wrote: > Hi Beena, > > > On Tue, Aug 22, 2017 at 5:22 PM, Beena Emerson > wrote: >> >> On Tue, Aug 22, 2017 at 4:20 PM, Beena Emerson >> wrote: >> > Hi Jeevan,

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi all, Enclosed please find the updated patch with covering security labels on database. The patch cover the following commands: 1. COMMENT ON DATABASE CURRENT_DATABASE is ... 2. ALTER DATABASE CURRENT_DATABASE OWNER to ... 3. ALTER DATABASE CURRENT_DATABASE SET parameter ...

Re: [HACKERS] POC: Sharing record typmods between backends

On 2017-08-21 11:02:52 +1200, Thomas Munro wrote: > 2. Andres didn't like what I did to DecrTupleDescRefCount, namely > allowing to run when there is no ResourceOwner. I now see that this > is probably an indication of a different problem; even if there were a > worker ResourceOwner as he