Re: [HACKERS] Causal reads take II

2017-09-06 Thread Thomas Munro
On Thu, Aug 10, 2017 at 2:02 PM, Thomas Munro wrote: > Rebased after conflicting commit 030273b7. Now using format-patch > with a commit message to keep track of review/discussion history. TAP test 006_logical_decoding.pl failed with that version. I had missed

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Amit Langote
On 2017/09/07 13:09, Michael Paquier wrote: > On Thu, Sep 7, 2017 at 12:59 PM, Tom Lane wrote: >> The idea I'd had was to apply the masking only if pd_lower >= >> SizeOfPageHeaderData, or if you wanted to be stricter, only if >> pd_lower != 0. > > If putting a check, it seems

Re: [HACKERS] Parallel Append implementation

2017-09-06 Thread Amit Kapila
On Thu, Aug 31, 2017 at 12:47 PM, Amit Khandekar wrote: > The last updated patch needs a rebase. Attached is the rebased version. > Few comments on the first read of the patch: 1. @@ -279,6 +347,7 @@ void ExecReScanAppend(AppendState *node) { int i; +

Re: [HACKERS] merge psql ef/ev sf/sv handling functions

2017-09-06 Thread Fabien COELHO
you can't do this sort of thing: -psql_error("The server (version %s) does not support editing function source.\n", +psql_error("The server (version %s) does not support editing %s.\n", formatPGVersionNumber(pset.sversion, false, -

Re: [HACKERS] ANALYZE command progress checker

2017-09-06 Thread Tatsuro Yamada
On 2017/04/05 10:17, Masahiko Sawada wrote: On Wed, Apr 5, 2017 at 1:49 AM, Robert Haas wrote: On Tue, Apr 4, 2017 at 4:57 AM, Amit Langote wrote: Hmm, you're right. It could be counted with a separate variable initialized to 0 and

Re: [HACKERS] Restricting maximum keep segments by repslots

2017-09-06 Thread Kyotaro HORIGUCHI
Hello, At Fri, 1 Sep 2017 23:49:21 -0400, Peter Eisentraut wrote in <751e09c4-93e0-de57-edd2-e64c4950f...@2ndquadrant.com> > I'm still concerned about how the critical situation is handled. Your > patch just prints a warning to the log and then goes on --

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

2017-09-06 Thread Masahiko Sawada
On Wed, Sep 6, 2017 at 4:01 PM, Fabien COELHO wrote: > > Applies, compiles, works for me. > > Very very minor comments that I should have noticed before, sorry for this > additional round trip. Thank you for the dedicated review! > > In the help line, move -I just after -i,

[HACKERS] Re: DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

2017-09-06 Thread Noah Misch
On Wed, Sep 06, 2017 at 03:28:47PM +0900, Masahiko Sawada wrote: > On Mon, Sep 4, 2017 at 11:43 PM, Arseny Sher wrote: > > Arseny Sher writes: > > > >> Attached patch fixes this by stopping workers before RO drop, as > >> already done in case when we

Re: [HACKERS] WIP: Failover Slots

2017-09-06 Thread Craig Ringer
On 14 August 2017 at 11:56, Craig Ringer wrote: > > I don't want to block failover slots on decoding on standby just because > decoding on standby would be nice to have. > However, during discussion with Tomas Munro a point has come up that does block failover slots as

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Michael Paquier
On Thu, Sep 7, 2017 at 12:59 PM, Tom Lane wrote: > The idea I'd had was to apply the masking only if pd_lower >= > SizeOfPageHeaderData, or if you wanted to be stricter, only if > pd_lower != 0. If putting a check, it seems to me that the stricter one makes the most sense.

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Tom Lane
Michael Paquier writes: > On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote: >> I looked briefly at these patches. I'm not sure that it's safe for the >> mask functions to assume that meta pages always have valid pd_lower. >> What happens when

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

2017-09-06 Thread Kyotaro HORIGUCHI
Hello, At Wed, 6 Sep 2017 12:23:53 -0700, Andres Freund wrote in <20170906192353.ufp2dq7wm5fd6...@alap3.anarazel.de> > On 2017-09-06 17:36:02 +0900, Kyotaro HORIGUCHI wrote: > > The problem is that the current ReadRecord needs the first one of > > a series of continuation

Re: [HACKERS] Replication vs. float timestamps is a disaster

2017-09-06 Thread Chapman Flack
On 09/06/17 18:33, Omar Kilani wrote: > Is there anything people using float datetimes can do that isn't a > pg_dumpall | pg_restore to do a less painful update? > > We have several TB of data still using float datetimes and I'm trying > to figure out how we can move to 10 (currently on 9.6.x)

Re: [HACKERS] A design for amcheck heapam verification

2017-09-06 Thread Peter Geoghegan
On Wed, Aug 30, 2017 at 9:29 AM, Peter Geoghegan wrote: > On Wed, Aug 30, 2017 at 5:02 AM, Alvaro Herrera > wrote: >> Eh, if you want to optimize it for the case where debug output is not >> enabled, make sure to use ereport() not elog(). ereport() >>

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Michael Paquier
On Thu, Sep 7, 2017 at 10:42 AM, Amit Langote wrote: > I too tend to think that any users who use this masking facility would > know to expect to get these failures on upgraded clusters with invalid > pd_lower in meta pages. Yes, I don't think that an optimization

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

2017-09-06 Thread Michael Paquier
On Wed, Sep 6, 2017 at 10:05 PM, Peter Eisentraut wrote: > Please send a rebased patch. > > I propose splitting the single Perl script into three separate test > files: one for basic command-line option handling and so on (I would > like to expand that later),

Re: [HACKERS] Pluggable storage

2017-09-06 Thread Thomas Munro
On Fri, Sep 1, 2017 at 1:51 PM, Haribabu Kommi wrote: > Here I attached new set of patches that are rebased to the latest master. Hi Haribabu, Could you please post a new rebased version? 0007-Scan-functions-are-added-to-storage-AM.patch conflicts with recent changes.

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Amit Langote
On 2017/09/07 8:51, Michael Paquier wrote: > On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote: >> Amit Langote writes: >>> On 2017/08/22 9:39, Michael Paquier wrote: On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

2017-09-06 Thread Michael Paquier
On Wed, Sep 6, 2017 at 11:44 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Peter Eisentraut wrote: >>> We also need to have a plan for handling the build farm. Maybe keep the >>> vcregress.pl upgradecheck target as a thin wrapper for the time

Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

2017-09-06 Thread Michael Paquier
On Thu, Sep 7, 2017 at 10:11 AM, Peter Eisentraut wrote: > On 9/4/17 06:03, Alvaro Herrera wrote: >> Tom Lane wrote: >>> Michael Paquier writes: I don't like breaking the abstraction of pg_log() with the existing flags with

Re: [HACKERS] Re: [COMMITTERS] pgsql: pg_rewind: Fix some problems when copying files >2GB.

2017-09-06 Thread Peter Eisentraut
On 9/4/17 06:03, Alvaro Herrera wrote: > Tom Lane wrote: >> Michael Paquier writes: >>> I don't like breaking the abstraction of pg_log() with the existing >>> flags with some kind of pg_debug() layer. The set of APIs present now >>> in pg_rewind for logging is nice to

Re: [HACKERS] Minor code improvement to postgresGetForeignPlan

2017-09-06 Thread Tatsuro Yamada
On 2017/09/07 6:52, Tom Lane wrote: Tatsuro Yamada writes: The declaration of postgresGetForeignPlan uses baserel, but the actual definition uses foreignrel. It would be better to sync. Pushed, thanks. regards, tom lane Thanks!

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Michael Paquier
On Thu, Sep 7, 2017 at 5:49 AM, Tom Lane wrote: > Amit Langote writes: >> On 2017/08/22 9:39, Michael Paquier wrote: >>> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote >>> wrote: I updated brin_mask() and

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

2017-09-06 Thread Michael Paquier
On Thu, Sep 7, 2017 at 1:43 AM, Robert Haas wrote: > On Wed, Sep 6, 2017 at 12:26 PM, Simon Riggs wrote: I'd personally be fine with --no-whatever for any whatever that might be a subsidiary property of database objects. We've got

Re: [HACKERS] Replication vs. float timestamps is a disaster

2017-09-06 Thread Tom Lane
Omar Kilani writes: > Is there anything people using float datetimes can do that isn't a > pg_dumpall | pg_restore to do a less painful update? Um, not really. You may be stuck on 9.6 until you can spare the effort to convert. The physical representations of timestamps

Re: [HACKERS] Red-Black tree traversal tests

2017-09-06 Thread Tom Lane
[ btw, please don't cc pgsql-hackers-owner, the list moderators don't need the noise ] Aleksander Alekseev writes: > I would say that this patch is in a pretty good shape now. And I see a > 99% code coverage of rbtree.c. Let's see what committers think. I took a quick

Re: [HACKERS] Replication vs. float timestamps is a disaster

2017-09-06 Thread Omar Kilani
Hi, I know I'm 7 months late to this, but only just read the beta 4 release notes. Is there anything people using float datetimes can do that isn't a pg_dumpall | pg_restore to do a less painful update? We have several TB of data still using float datetimes and I'm trying to figure out how we

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

2017-09-06 Thread Peter Geoghegan
On Wed, Sep 6, 2017 at 2:47 PM, Thomas Munro wrote: >> I attach a patch to remove replacement selection, which I'll submit to CF 1. > > This breaks the documentation build, because > doc/src/sgml/release-9.6.sgml still contains

Re: [HACKERS] Minor code improvement to postgresGetForeignPlan

2017-09-06 Thread Tom Lane
Tatsuro Yamada writes: > The declaration of postgresGetForeignPlan uses baserel, but > the actual definition uses foreignrel. It would be better to sync. Pushed, thanks. regards, tom lane -- Sent via pgsql-hackers mailing list

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

2017-09-06 Thread Thomas Munro
On Fri, Sep 1, 2017 at 6:00 AM, Peter Geoghegan wrote: > 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 >>

Re: [HACKERS] merge psql ef/ev sf/sv handling functions

2017-09-06 Thread Tom Lane
Fabien COELHO writes: > Here is an attempt at merging some functions which removes 160 lines of > code. Pushed with minor adjustments. I thought a couple of variable names could be better chosen, but mostly, you can't do this sort of thing: -psql_error("The

Re: [HACKERS] Setting pd_lower in GIN metapage

2017-09-06 Thread Tom Lane
Amit Langote writes: > On 2017/08/22 9:39, Michael Paquier wrote: >> On Tue, Jun 27, 2017 at 4:56 PM, Amit Langote >> wrote: >>> I updated brin_mask() and spg_mask() in the attached updated patches so >>> that they consider meta pages

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Tom Lane
Robert Haas writes: > On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote: >> I'm not entirely following. I thought that add_path was set up to treat >> "can be parallelized" as an independent dimension of merit, so that >> parallel paths would always

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
I wrote: > Ah. I was not thinking of touching pg_atomic_read_u32/u64_impl, > although now that you mention it, it's not clear to me why we > couldn't simplify > - return *(>value); > + return ptr->value; Just to check, I applied that change to pg_atomic_read_u32_impl and

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane wrote: > Robert Haas writes: >> In particular, as Jeff and Amit point out, it >> may well be that (a) before apply_projection_to_path(), the cheapest >> plan is non-parallel and (b) after

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Tom Lane
Robert Haas writes: > In particular, as Jeff and Amit point out, it > may well be that (a) before apply_projection_to_path(), the cheapest > plan is non-parallel and (b) after apply_projection_to_path(), the > cheapest plan would be a Gather plan, except that it's too late

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Andres Freund writes: > On 2017-09-06 15:25:20 -0400, Tom Lane wrote: >> I think we can just use "old = ptr->value" to set up for the cmpxchg >> loop in every generic.h function that uses such a loop. > I think we might have been talking past each other - I thought you were >

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 3:18 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote: >>> If somebody's applying apply_projection_to_path to a path that's already >>> been add_path'd, that's a

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Andres Freund
On 2017-09-06 15:25:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-09-06 15:12:13 -0400, Tom Lane wrote: > >> It looks to me like two of the three implementations promise no such > >> thing. > > > They're volatile vars, so why not? > > Yeah, but so are the

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Andres Freund writes: > On 2017-09-06 15:12:13 -0400, Tom Lane wrote: >> It looks to me like two of the three implementations promise no such >> thing. > They're volatile vars, so why not? Yeah, but so are the caller's variables. That is, in

Re: [HACKERS] [BUGS] Bug in Physical Replication Slots (at least 9.5)?

2017-09-06 Thread Andres Freund
On 2017-09-06 17:36:02 +0900, Kyotaro HORIGUCHI wrote: > Hi, > > At Mon, 4 Sep 2017 17:17:19 +0900, Michael Paquier > wrote in >

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Andres Freund
On 2017-09-06 15:12:13 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-09-06 14:31:26 -0400, Tom Lane wrote: > >> However, if that's the reasoning, why don't we make all of these > >> use simple reads? It seems unlikely that a locked read is free. > > > We don't

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Tom Lane
Robert Haas writes: > On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote: >> If somebody's applying apply_projection_to_path to a path that's already >> been add_path'd, that's a violation of the documented restriction. > /me is confused. Isn't that

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Andres Freund writes: > On 2017-09-06 14:31:26 -0400, Tom Lane wrote: >> However, if that's the reasoning, why don't we make all of these >> use simple reads? It seems unlikely that a locked read is free. > We don't really use locked reads? All the _atomic_ wrapper forces is

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote: >>> Okay, now I understand your point, but I think we already change the >>> cost of paths in

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Fabien COELHO
Thus short, simple but meaningful examples which show how to do something useful with all that in the documentation may help people take advantage of these new features. I don't have an objection to providing an example. I wasn't terribly impressed with Simon's version, but maybe we can do

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

2017-09-06 Thread Pavel Stehule
> > > I think a GUC is a decent, though not perfect, mechanism for this. > This problem isn't restricted to PL/pgsql; indeed, the cases I've seen > have come via prepared queries, not PL/pgsql functions. Even without > that, one advantage of a GUC is that they are fairly broadly > understood and

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Andres Freund
Hi, On 2017-09-06 14:31:26 -0400, Tom Lane wrote: > I wrote: > > Anyway, I don't have a big objection to applying this. My concern > > is more that we need to be taking a harder look at other parts of > > the atomics infrastructure, because tweaks there are likely to buy > > much more. > > I

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Tom Lane
Fabien COELHO writes: > Thus short, simple but meaningful examples which show how to do something > useful with all that in the documentation may help people take advantage > of these new features. I don't have an objection to providing an example. I wasn't terribly

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
I wrote: > Anyway, I don't have a big objection to applying this. My concern > is more that we need to be taking a harder look at other parts of > the atomics infrastructure, because tweaks there are likely to buy > much more. I went ahead and pushed these patches, adding __sync_fetch_and_sub

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Fabien COELHO
Hello, * Clarification that this will work for current AND past server versions The short answer is it works. I do not think we need a longer answer. To have something operational you have to know quite a bit of psql details (:-substitutions, backslash command logic, gset, if, quit...).

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Tom Lane
Robert Haas writes: > On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote: >> Okay, now I understand your point, but I think we already change the >> cost of paths in apply_projection_to_path which is done after add_path >> for top level scan/join

Re: [HACKERS] [PATCH] Add citext_pattern_ops to citext contrib module

2017-09-06 Thread Jacob Champion
On Tue, Jul 18, 2017 at 5:18 AM, Alexey Chernyshov wrote: > Hi all, Hi Alexey, I took a look at your patch. Builds fine here, and passes the new tests. I'm new to this code, so take my review with a grain of salt. > The attached patch introduces citext_pattern_ops

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Jesper Pedersen
Hi Jeff, On 09/05/2017 03:47 PM, Jeff Janes wrote: I ran pgbench (-M prepared) with synchronous_commit 'on' and 'off' using both logged and unlogged tables. Also ran an internal benchmark which didn't show anything either. What scale factor and client count? How many cores per socket? It

Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour

2017-09-06 Thread Simon Riggs
On 6 September 2017 at 10:27, Tom Lane wrote: > Simon Riggs writes: >> Other than that, I'm good to commit. >> Any last minute objections? > > The docs and comments could stand a bit closer copy-editing by a > native English speaker. Other than that,

Re: [HACKERS] why not parallel seq scan for slow functions

2017-09-06 Thread Robert Haas
On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila wrote: > Okay, now I understand your point, but I think we already change the > cost of paths in apply_projection_to_path which is done after add_path > for top level scan/join paths. Yeah. I think that's a nasty hack, and I

Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour

2017-09-06 Thread Tom Lane
Simon Riggs writes: > Other than that, I'm good to commit. > Any last minute objections? The docs and comments could stand a bit closer copy-editing by a native English speaker. Other than that, it seemed sane in a quick read-through. regards, tom

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Robert Haas writes: > It's not a question of whether the return value is used, but of > whether the updated value of *old is used. Right, but if we re-read "old" in the loop, and if the primitive doesn't return "old" (or does, but call site ignores it) then in principle

Re: [HACKERS] ALTER INDEX .. SET STATISTICS ... behaviour

2017-09-06 Thread Simon Riggs
On 4 September 2017 at 10:30, Adrien Nayrat wrote: > On 09/04/2017 06:16 PM, Alexander Korotkov wrote: >> Looks good for me. I've integrated those changes in the patch. >> New revision is attached. > > Thanks, I changed status to "ready for commiter". This looks useful

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 12:26 PM, Simon Riggs wrote: >>> I'd personally be fine with --no-whatever for any whatever that might >>> be a subsidiary property of database objects. We've got >>> --no-security-labels, --no-tablespaces, --no-owner, and >>> --no-privileges

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-09-06 Thread Fabien COELHO
Seeing it as is, it calls for having "SERVER_VERSION" as well, but I'm not sure of the better way to get it. I tried with "SELECT VERSION() AS SERVER_VERSION \gset" but varnames are lowerized. The problem there is you can't get version() without an extra round trip to the server --- and an

Re: [HACKERS] Patch: Add --no-comments to skip COMMENTs with pg_dump

2017-09-06 Thread Simon Riggs
On 1 September 2017 at 22:08, Michael Paquier wrote: > On Sat, Sep 2, 2017 at 1:53 AM, Robert Haas wrote: >> On Mon, Aug 21, 2017 at 5:30 PM, Simon Riggs wrote: >>> Thinking ahead, are we going to add a new --no-objecttype

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

2017-09-06 Thread Peter Eisentraut
On 8/18/17 05:28, Michael Banck wrote: >>> Rebased, squashed and slighly edited version attached. I've added this >>> to the 2017-07 commitfest now as well: >>> >>> https://commitfest.postgresql.org/14/1112/ >> Can you rebase this past some conflicting changes? > Thanks for letting me know, PFA a

Re: [HACKERS] UPDATE of partition key

2017-09-06 Thread Dilip Kumar
On Mon, Sep 4, 2017 at 10:52 AM, Amit Khandekar wrote: > On 4 September 2017 at 07:43, Amit Kapila wrote: > Oops sorry. Now attached. I have done some basic testing and initial review of the patch. I have some comments/doubts. I will continue

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Tom Lane
Simon Riggs writes: > * Clarification that this will work for current AND past server versions The short answer is it works. I do not think we need a longer answer. (The existing comment in libpq says that the "select version()" method works in any server version that

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 12:01 PM, Tom Lane wrote: >> This seems like a pretty sound argument to me. I think Tom's probably >> right that the changes in generic-gcc.h are the important ones, but >> I'm not sure that's an argument against patching generics.h. Given >> that

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Robert Haas writes: > On Wed, Sep 6, 2017 at 9:42 AM, Sokolov Yura > wrote: >> But I think, generic version still should be "fixed". >> If generic version is not reached on any platform, then why it is kept? >> If it is reached somewhere, then

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Simon Riggs
On 6 September 2017 at 06:38, Tom Lane wrote: > Simon Riggs writes: >> Based upon input from Tom and Fabien, I propose this additional doc patch. > > I do not think any of this is appropriate, particularly not the reference > to 7.0.3. OK, no problem.

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

2017-09-06 Thread Jacob Champion
On Tue, Sep 5, 2017 at 10:49 PM, Michael Paquier wrote: > 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) &&

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 9:42 AM, Sokolov Yura wrote: > Yes, you're right. > > But I think, generic version still should be "fixed". > If generic version is not reached on any platform, then why it is kept? > If it is reached somewhere, then it should be improved. This

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

2017-09-06 Thread Robert Haas
On Wed, Sep 6, 2017 at 11:03 AM, Tom Lane wrote: > That's fair enough. We need to have a discussion about exactly what > the knob does, which is distinct from the question of how you spell > the incantation for twiddling it. I'm dubious that a dumb "force a > custom plan"

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

2017-09-06 Thread Tom Lane
Robert Haas writes: > I don't think we can just indefinitely continue to resist > providing manual control over this behavior on the theory that some > day we'll fix it. That's fair enough. We need to have a discussion about exactly what the knob does, which is distinct

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

2017-09-06 Thread Tom Lane
Alvaro Herrera writes: > Peter Eisentraut wrote: >> We also need to have a plan for handling the build farm. Maybe keep the >> vcregress.pl upgradecheck target as a thin wrapper for the time being? > The buildfarm already runs "make check" in src/bin/ when TAP tests are

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

2017-09-06 Thread Robert Haas
On Tue, Sep 5, 2017 at 1:38 PM, Tom Lane wrote: > The complaint I have about PRAGMA is that it's yet another syntax for > accomplishing pretty much the same thing. If you don't like the GUC > solution, we've already got the "comp_option" syntax for static options > in

Re: [HACKERS] Fix bloom WAL tap test

2017-09-06 Thread Alexander Korotkov
On Wed, Sep 6, 2017 at 4:08 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > I just realized that these lines of contrib/bloom/t/001_wal.pl don't > check that queries give same results on master and standby. They just > check that *return codes* of psql are equal. > > # Run test

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

2017-09-06 Thread Alvaro Herrera
Peter Eisentraut wrote: > I propose splitting the single Perl script into three separate test > files: one for basic command-line option handling and so on (I would > like to expand that later), one for the main upgrade test, and one for > the funny database names tests. Check. > We also need

Re: [HACKERS] Walsender timeouts and large transactions

2017-09-06 Thread Yura Sokolov
I've changed to "need review" to gain more attention from other. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Is anything preventing us from allowing write to foreign tables from standby?

2017-09-06 Thread Alexander Korotkov
Hi! We're currently blocking writing queries on standby if even they are modifying contents of foreign tables. But do we have serious reasons for that? Keeping in the mind FDW-sharding, making FDW-tables writable from standby would be good to prevent single-master bottleneck. I wrote simple

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Sokolov Yura
On 2017-09-06 16:36, Tom Lane wrote: Sokolov Yura writes: On 2017-09-06 15:56, Tom Lane wrote: The point I'm trying to make is that if tweaking generic.h improves performance then it's an indicator of missed cases in the less-generic atomics code, and the latter

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Tom Lane
Simon Riggs writes: > Based upon input from Tom and Fabien, I propose this additional doc patch. I do not think any of this is appropriate, particularly not the reference to 7.0.3. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Sokolov Yura writes: > On 2017-09-06 15:56, Tom Lane wrote: >> The point I'm trying to make is that if tweaking generic.h improves >> performance then it's an indicator of missed cases in the less-generic >> atomics code, and the latter is where our attention should

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Sokolov Yura
On 2017-09-06 15:56, Tom Lane wrote: Simon Riggs writes: On 5 September 2017 at 21:23, Tom Lane wrote: Moreover, it matters which primitive you're testing, on which platform, with which compiler, because we have a couple of layers of atomic ops

Re: [HACKERS] [COMMITTERS] pgsql: Add psql variables showing server version and psql version.

2017-09-06 Thread Simon Riggs
On 5 September 2017 at 11:58, Fabien COELHO wrote: > > 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

[HACKERS] Fix bloom WAL tap test

2017-09-06 Thread Alexander Korotkov
Hi! I just realized that these lines of contrib/bloom/t/001_wal.pl don't check that queries give same results on master and standby. They just check that *return codes* of psql are equal. # Run test queries and compare their result > my $master_result = $node_master->psql("postgres", $queries);

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

2017-09-06 Thread Peter Eisentraut
On 4/14/17 02:00, Michael Paquier wrote: > Attached is an updated patch to use --no-sync with pg_dumpall calls. Please send a rebased patch. I propose splitting the single Perl script into three separate test files: one for basic command-line option handling and so on (I would like to expand

Re: [HACKERS] <> join selectivity estimate question

2017-09-06 Thread Tom Lane
Simon Riggs writes: > Why isn't this an open item for PG10? Why should it be? This behavior has existed for a long time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Tom Lane
Simon Riggs writes: > On 5 September 2017 at 21:23, Tom Lane wrote: >> Moreover, it matters which primitive you're testing, on which platform, >> with which compiler, because we have a couple of layers of atomic ops >> implementations. > If there is no

Re: [HACKERS] <> join selectivity estimate question

2017-09-06 Thread Simon Riggs
On 6 September 2017 at 04:14, Ashutosh Bapat wrote: > On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro > wrote: >> >> Thanks. Bearing all that in mind, I ran through a series of test >> scenarios and discovered that my handling for

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Simon Riggs
On 5 September 2017 at 21:23, Tom Lane wrote: > 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. ... >

Re: [HACKERS] document and use SPI_result_code_string()

2017-09-06 Thread Tom Lane
Michael Paquier writes: > Fine for 0002. This reminds me of LockGXact and RemoveGXact in > twophase.c, as well as _hash_squeezebucket that have some code paths > that cannot return... Any thoughts about having some kind of > PG_NOTREACHED defined to 0 which could be put

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Sokolov Yura
On 2017-09-06 14:54, Sokolov Yura wrote: On 2017-09-06 07:23, Tom Lane wrote: 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. This

Re: [HACKERS] Adding support for Default partition in partitioning

2017-09-06 Thread Jeevan Ladhe
Hi Ashutosh, I have tried to address your comments in V27 patch series[1]. Please find my comments inlined. > >> > >> The current set of patches contains 6 patches as below: > >> > >> 0001: > >> Refactoring existing ATExecAttachPartition code so that it can be used > >> for > >> default

Re: [HACKERS] 【ECPG】strncpy function does not set the end character '\0'

2017-09-06 Thread Tom Lane
Michael Meskes writes: >> In the function ECPGnoticeReceiver, we use the stncpy function copy >> the >> sqlstate to sqlca->sqlstate. And the sqlca->sqlstate is defined as >> the size >> of 5, and the copy size is sizeof(sqlca->sqlstate). However, from the >> previous

Re: [HACKERS] Fix performance of generic atomics

2017-09-06 Thread Sokolov Yura
On 2017-09-06 07:23, Tom Lane wrote: 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. This means that Sokolov's proposed changes in

Re: [HACKERS] <> join selectivity estimate question

2017-09-06 Thread Ashutosh Bapat
On Fri, Jul 21, 2017 at 4:10 AM, Thomas Munro wrote: > > Thanks. Bearing all that in mind, I ran through a series of test > scenarios and discovered that my handling for JOIN_ANTI was wrong: I > thought that I had to deal with inverting the result, but I now see >

Re: [HACKERS] additional contrib test suites

2017-09-06 Thread Thomas Munro
On Sat, Aug 12, 2017 at 1:20 PM, Peter Eisentraut wrote: > Here are some small test suites for some contrib modules as well as > pg_archivecleanup that didn't have one previously, as well as one patch > to improve code coverage in a module. > > Will add to commit

Re: [HACKERS] [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel

2017-09-06 Thread Thomas Munro
On Sat, Jul 22, 2017 at 12:05 AM, Alexey Chernyshov wrote: > the following patch transfers functionality from gevel module > (http://www.sai.msu.su/~megera/wiki/Gevel) which provides functions for > analyzing GIN and GiST indexes to pageinspect. Gevel was originally >

Re: [HACKERS] Effect of changing the value for PARALLEL_TUPLE_QUEUE_SIZE

2017-09-06 Thread Rafia Sabih
On Fri, Jun 2, 2017 at 6:31 PM, Amit Kapila wrote: > > Your reasoning sounds sensible to me. I think the other way to attack > this problem is that we can maintain some local queue in each of the > workers when the shared memory queue becomes full. Basically, we can >

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

2017-09-06 Thread Daniel Gustafsson
> On 06 Sep 2017, at 02:56, Amit Langote wrote: > > 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)

Re: [HACKERS] path toward faster partition pruning

2017-09-06 Thread Amit Langote
On 2017/09/04 10:10, Amit Langote wrote: > On 2017/09/02 2:52, Robert Haas wrote: >> It strikes me that this patch set is doing two things but maybe in the >> opposite order that I would have chosen to attack them. First, >> there's getting partition pruning to use something other than >>

  1   2   >