Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Fri, Mar 31, 2017 at 5:12 PM, Andreas Karlsson wrote: > Thanks for the feedback. I will look at it when I get the time. > > On 03/31/2017 08:27 AM, Michael Paquier wrote: >> >> - Do a per-index rebuild and not a per-relation rebuild for concurrent >> indexing. Doing a

Re: [HACKERS] Allow interrupts on waiting standby

On Fri, Mar 31, 2017 at 4:46 PM, Tsunakawa, Takayuki wrote: > Thank you, but did you remove WL_LATCH_SET from WaitLatch() intentionally? I > understood you added it for startup process to respond quickly to events > other than the postmaster death. Why don't we

Re: [HACKERS] Logical decoding on standby

On 31 March 2017 at 12:49, Craig Ringer wrote: > On 31 March 2017 at 01:16, Andres Freund wrote: >>> @@ -9633,6 +9643,12 @@ xlog_redo(XLogReaderState *record) >>> SetTransactionIdLimit(checkPoint.oldestXid, >>> checkPoint.oldestXidDB);

Re: [HACKERS] [COMMITTERS] pgsql: Avoid GatherMerge crash when there are no workers.

On Sat, Apr 1, 2017 at 7:58 PM, Robert Haas wrote: > On Fri, Mar 31, 2017 at 10:26 PM, Andres Freund > wrote: > > Hi, > > > > On 2017-04-01 01:22:14 +, Robert Haas wrote: > >> Avoid GatherMerge crash when there are no workers. > > > > I think the

Re: [HACKERS] Supporting huge pages on Windows

From: Michael Paquier [mailto:michael.paqu...@gmail.com] > Amit is right, you had better use %zu as we do in all the other places of > the code dealing with Size variables that are printed. When compiling with > Visual Studio, Postgres falls back to the implementation of sprintf in >

Re: [HACKERS] parallel explain analyze support not exercised

On Sat, Apr 1, 2017 at 12:25 AM, Andres Freund wrote: > Hi, > > As visible in [1], the explain analyze codepaths of parallel query isn't > exercised in the tests. That used to be not entirely trivial if the > output was to be displayed (due to timing), but we should be able

Re: [HACKERS] Documentation improvements for partitioning

On 2017/04/01 6:37, Robert Haas wrote: > On Tue, Mar 28, 2017 at 6:35 AM, Amit Langote > wrote: >> Attached updated patch. > > Committed with editing here and there. I just left out the thing > about UNION ALL views, which seemed to brief a treatment to deserve >

Re: [HACKERS] Supporting huge pages on Windows

On Mon, Apr 3, 2017 at 1:12 PM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >> You should use %zu instead of %llu to print Size type of variable. > > I did so at

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

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Alvaro Herrera > Ashutosh Bapat wrote: > > Please add this to the next commitfest. > > If this cannot be reproduced in 9.6, then it must be added to the Open Items > wiki page instead. I added

Re: [HACKERS] Supporting huge pages on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > You should use %zu instead of %llu to print Size type of variable. I did so at first, but it didn't work with Visual Studio 2010 at hand. It doesn't support %z which is added in

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Sat, Apr 1, 2017 at 2:03 AM, David Steele wrote: > Hi, > > On 3/30/17 2:12 PM, Daniel Verite wrote: > >> Vaishnavi Prabakaran wrote: >> >> Hmm, With batch mode, after sending COPY command to server(and server >>> started processing the query and goes into COPY

Re: [HACKERS] delta relations in AFTER triggers

On Mon, Apr 3, 2017 at 3:50 PM, Thomas Munro wrote: > Please also find attached a rebased patch to add pl/python support, > and new equivalent patches for pl/perl and pl/tcl. I am planning to > add these to PG11 CF1, unless you think we should be more aggressive >

Re: [HACKERS] delta relations in AFTER triggers

Happy to see this committed! And thanks for the co-author credit, which is a generous exaggeration. I was still a bit confused about this and poked at it a bit: On Wed, Mar 8, 2017 at 1:28 PM, Kevin Grittner wrote: >> /* >> + * Capture the NEW and OLD transition TABLE

Re: [HACKERS] delta relations in AFTER triggers

> > > That, and I suspect that people will start using this infrastructure > > for some very cool projects. > > Yeah, I was excited to see this committed. It practically begs to be > used for plpgsql TABLE valued variables backed by tuplestores. > (also very excited about this!)

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/01 5:29, Robert Haas wrote: > On Fri, Mar 31, 2017 at 4:33 AM, Kyotaro HORIGUCHI > wrote: >> I have no more comment on this. Thank you. > > I committed this with a few tweaks. I simplified the wording in the > documentation a bit, removed or adjusted

Re: [HACKERS] delta relations in AFTER triggers

On 1 April 2017 at 02:29, David Fetter wrote: > On Fri, Mar 31, 2017 at 12:20:51PM -0500, Kevin Grittner wrote: >> On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner wrote: >> >> > New version attached. It needs some of these problem cases added >> > to the

Re: [HACKERS] Fix obsolete comment in GetSnapshotData

On 31 March 2017 at 21:59, Robert Haas wrote: > On Wed, Mar 29, 2017 at 12:00 AM, Craig Ringer wrote: >> There's an outdated reference to GetOldestXmin(true, true) in >> GetSnapshotData. It hasn't had that call signature for a long while >> now.

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO writes: >>> - how desirable/useful is it to have this in 10? >> Extensions and extension-ish packages will love the _NUM vars. > H. I'm afraid pg extension scripts (for CREATE EXTENSION) are not > executed through psql, but server side directly, so there

Re: [HACKERS] WIP: Covering + unique indexes.

On Thu, Mar 30, 2017 at 8:26 AM, Teodor Sigaev wrote: > Any objection from reviewers to push both patches? I object. Unfortunately, it seems very unlikely that we'll be able to get the patch into shape in the allotted time before feature-freeze, even with the 1 week extension.

Re: [HACKERS] WIP: Covering + unique indexes.

On Fri, Mar 31, 2017 at 4:31 PM, Peter Geoghegan wrote: > That's all I have for now. Maybe I can look again later, or tomorrow. I took another look, this time at code used during CREATE INDEX. More feedback: * I see no reason to expose _bt_pgaddtup() (to modify it to not be

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

On Mon, Apr 3, 2017 at 7:19 AM, Venkata B Nagothi wrote: > As we are already past the commitfest, I am not sure, what should i change > the patch status to ? The commit fest finishes on the 7th of April. Even with the deadline passed, there is nothing preventing to work on bug

Re: [HACKERS] PATCH: two slab-like memory allocators

Hi, this patch is marked as committed in CF application but the second part (generational allocator) was AFAICS never committed. Does anybody plan to push this forward? -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

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

On Fri, Mar 31, 2017 at 4:05 PM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Thank you having a look on this. > > # I removed -bugs in CC:. > > At Fri, 31 Mar 2017 13:40:00 +1100, Venkata B Nagothi > wrote in

Re: [HACKERS] Undefined psql variables

I'm inclined to suggest that we should require all extensions beyond the boolean-literal case to be set up as a keyword followed by appropriate argument(s); that seems like it's enough to prevent syntax conflicts from future additions. So you could imagine \if defined varname

Re: [HACKERS] Undefined psql variables

Hello, For checking variable definition, I would suggest to extend the variable access syntax so that there is no exception to the one thing rule between client side and server side evaluation: \if :?variable Don't like that one bit; Possibly:-) This is kind of a shell-like hack

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-03-23 17:26 GMT+01:00 Pierre Ducroquet : > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:

Re: [HACKERS] Undefined psql variables

Hello Tom, I'm just arguing that for pgbench the evaluator needs to be on the client side, which implies a lexer, parser and executor. For psql, it does not really matter where the evaluator is, thus relying on the server should be fine and simpler and also powerful, provided the necessary

Re: [HACKERS] Suggested fix for \p and \r in psql

"Daniel Verite" writes: > Tom Lane wrote: >> If we do phrase it like that, I think that the most natural behavior >> for \r is the way I have it in HEAD --- you'd expect it to clear >> the query buffer, but you would not expect it to forget the most >> recent

Re: [HACKERS] Undefined psql variables

Fabien COELHO writes: > For checking variable definition, I would suggest to extend the variable > access syntax so that there is no exception to the one thing rule between > client side and server side evaluation: >\if :?variable Don't like that one bit; you're going

Re: [HACKERS] Variable substitution in psql backtick expansion

More to the point, we already have that. See c.h: #define CppAsString(identifier) #identifier #define CppAsString2(x) CppAsString(x) Thanks for the pointer. I grepped for them without success. Here is a v4. -- Fabiendiff --git a/doc/src/sgml/ref/psql-ref.sgml

Re: [HACKERS] Undefined psql variables

Fabien COELHO writes: > I'm just arguing that for pgbench the evaluator needs to be on the client > side, which implies a lexer, parser and executor. For psql, it does not > really matter where the evaluator is, thus relying on the server should be > fine and simpler and

Re: [HACKERS] Variable substitution in psql backtick expansion

src/tools/msvc/Solution.pm:s{PG_VERSION_STR "[^"]+"}{__STRINGIFY(x) #x\n#define __STRINGIFY2(z) __STRINGIFY(z)\n#define PG_VERSION_STR "PostgreSQL $self->{strver}$extraver, compiled by Visual C++ build " __STRINGIFY2(_MSC_VER) ", $bits-bit"}; Well, this is the same hack. Without digging too

Re: [HACKERS] Undefined psql variables

Hello Pavel, I have convinced myself that, unlike pgbench, psql does not really need an advanced client-side-implemented language, so the smaller the better. What I mean by this is that from psql point of view it is ok that the actual expression evaluation is performed server-side. From a user

Re: [HACKERS] Variable substitution in psql backtick expansion

Corey Huinker writes: > Looking at #define STRINGIFY(), I got curious where else STRINGIFY was used: > Without digging too deep, it seems like the redefinition wouldn't be > harmful, but it might make sense to not use the name STRINGIFY() if only to > avoid confusion with

Re: [HACKERS] walsender.c comments

On Tue, Mar 28, 2017 at 8:59 AM, Erik Rijkers wrote: > Small fry gathered wile reading walsender.c ... > > (to be applied to master) > Thanks, applied. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/

Re: [HACKERS] Suggested fix for \p and \r in psql

Tom Lane wrote: > If we do phrase it like that, I think that the most natural behavior > for \r is the way I have it in HEAD --- you'd expect it to clear > the query buffer, but you would not expect it to forget the most > recent command. Okay, leaving out \r as it is and changing only

Re: [HACKERS] Variable substitution in psql backtick expansion

On Sun, Apr 2, 2017 at 12:29 PM, Fabien COELHO wrote: > > Hello Corey, > > I'm anxious to help with these patches, but they seem a bit of a moving >> target. Happy to jump in and review as soon as we've settled on what >> should >> be done. >> > > The "v3" I sent basically

Re: [HACKERS] Undefined psql variables

2017-04-02 18:56 GMT+02:00 Fabien COELHO : > > Hello Tom, > > I'm inclined to suggest that we should require all extensions beyond the >> boolean-literal case to be set up as a keyword followed by appropriate >> argument(s); that seems like it's enough to prevent syntax

Re: [HACKERS] Undefined psql variables

2017-04-02 18:29 GMT+02:00 Tom Lane : > Corey Huinker writes: > > On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: > >> This seems pretty bizarre. What's the use case? Why would it not > >> be better to build the behavior out

Re: [HACKERS] Undefined psql variables

Hello Tom, I'm inclined to suggest that we should require all extensions beyond the boolean-literal case to be set up as a keyword followed by appropriate argument(s); that seems like it's enough to prevent syntax conflicts from future additions. So you could imagine \if defined

Re: [HACKERS] Suggested fix for \p and \r in psql

"Daniel Verite" writes: > The documentation over-simplifies things as if there > was only one query buffer, instead of two of them. Yeah, there's a lot of oversimplification in the docs for slash commands --- for instance, I was just noticing yesterday that there's no

Re: [HACKERS] Suggested fix for \p and \r in psql

Tom Lane wrote: > > 1. \p ignores the "previous buffer". Example: > > Yeah, I did that intentionally, thinking that the old behavior was > confusing. We can certainly discuss it though. I'd tend to agree > with your point that \p and \w should print the same thing, but > maybe neither

Re: [HACKERS] Undefined psql variables

Corey Huinker writes: > On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: >> This seems pretty bizarre. What's the use case? Why would it not >> be better to build the behavior out of other spare parts, along the >> lines of COALESCE or perhaps >>

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Corey, I'm anxious to help with these patches, but they seem a bit of a moving target. Happy to jump in and review as soon as we've settled on what should be done. The "v3" I sent basically adds both client & server version numbers in client-side variables, basically same code as

Re: [HACKERS] asynchronous execution

> > > I'll continue working on this from this point aiming to the next > commit fest. > > This probably will not surprise you given the many commits in the past 2 weeks, but the patches no longer apply to master: $ git apply ~/async/0001-Allow-wait-event-set-to-be-registered-to-resource-ow.patch

Re: [HACKERS] Variable substitution in psql backtick expansion

On Sun, Apr 2, 2017 at 11:16 AM, Pavel Stehule wrote: > > > 2017-04-02 13:13 GMT+02:00 Fabien COELHO : > >> >> Hello Pavel, >> >> \echo :VERSION PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4)

Re: [HACKERS] Undefined psql variables

On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane wrote: > Corey Huinker writes: > > I was giving some thought to how psql handles undefined variables. > > I would like an option where either psql can provide an alternate value > > when an undefined

Re: [HACKERS] Suggested fix for \p and \r in psql

1. \p ignores the "previous buffer". Example: Yeah, I did that intentionally, thinking that the old behavior was confusing. We can certainly discuss it though. I'd tend to agree with your point that \p and \w should print the same thing, but maybe neither of them should look at the

Re: [HACKERS] Suggested fix for \p and \r in psql

I wrote: > "Daniel Verite" writes: >> 1. \p ignores the "previous buffer". Example: > Yeah, I did that intentionally, thinking that the old behavior was > confusing. We can certainly discuss it though. I'd tend to agree > with your point that \p and \w should print the

Re: [HACKERS] Suggested fix for \p and \r in psql

"Daniel Verite" writes: > I've noticed two issues with the query buffer post-commit e984ef5 > (Support \if ... \elif ... \else ... \endif in psql scripting): > 1. \p ignores the "previous buffer". Example: Yeah, I did that intentionally, thinking that the old behavior

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 13:13 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > \echo :VERSION >>> PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu >>> 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit >>> >>> Probably some :VERSION_NUM would make some sense. See attached

Re: [HACKERS] Moving GiST index constant to parameter

Thomas Mercieca writes: > I have tried introducing a GUC variable (entry in guc.c/config_real) and I > have also tried having the parser recognize it (same as fillfactor is > recognized), but irrelevant of what I set the value to at run-time, I always > get the same unusual

Re: [HACKERS] BRIN cost estimate

- cond := format('%I %s %L', r.colname, r.oper, r.value); + cond := format('%s %s %L', r.colname, r.oper, r.value); Why did you change this? It seems unrelated. Must be a mistake. + indexRel = index_open(index->indexoid, AccessShareLock); + pagesPerRange = Min(BrinGetPagesPerRange(indexRel),

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley writes: > Tom, I'm wondering if you think you'll get time to look at this before the > feature freeze? Yeah, I intend to. Thanks for updating the patch. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Suggested fix for \p and \r in psql

Hello Daniel, I've noticed two issues with the query buffer post-commit e984ef5 (Support \if ... \elif ... \else ... \endif in psql scripting): I thought that Tom's changes were somehow intentional, in order to simplify the code. 1. \p ignores the "previous buffer". Example: postgres=#

[HACKERS] [GSoC] Question about "Explicitly support predicate locks in index access methods besides btree"

Hi guys, I'm confused about the this function, CheckForSerializableConflictOut(...). Can anyone help me out? It seems like this function is used to check the rw-antidependencies out edge. This should be done when reading a written tuple. But btree does not call this function at all. The heapam

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Daniel, SELECT some-boolean-expression AS okay \gset \if :okay Yes, the question was whether we leave it as that for v10, or if it's worth a last-minute improvement for usability, assuming it's doable, similarly to what $subject does to backtick expansion for external evaluation.

Re: [HACKERS] Variable substitution in psql backtick expansion

Fabien COELHO wrote: > Note that this is already available indirectly, as show in the > documentation. > > SELECT some-boolean-expression AS okay \gset > \if :okay > \echo boolean expression was true > \else > \echo boolean expression was false > \endif Yes, the

[HACKERS] FDW and parallel execution

Hi hackers and personally Robet (you are the best expert in both areas). I want to ask one more question concerning parallel execution and FDW. Below are two plans for the same query (TPC-H Q5): one for normal tables, another for FDW to vertical representation of the same data. FDW supports

[HACKERS] Suggested fix for \p and \r in psql

Hi, I've noticed two issues with the query buffer post-commit e984ef5 (Support \if ... \elif ... \else ... \endif in psql scripting): 1. \p ignores the "previous buffer". Example: postgres=# select 1; ?column? -- 1 (1 row) postgres=# \p Query buffer is empty. That doesn't

Re: [HACKERS] Variable substitution in psql backtick expansion

Can be SERVER_VERSION_NUM taken from connection info? Here is a version with that, quite easy as well as the information was already there for other checks. I have not updated "help.c" because the initial VERSION was not presented there in the first place. Here is a v3 to fix the

Re: [HACKERS] Variable substitution in psql backtick expansion

Can be SERVER_VERSION_NUM taken from connection info? Here is a version with that, quite easy as well as the information was already there for other checks. I have not updated "help.c" because the initial VERSION was not presented there in the first place. -- Fabien.diff --git

Re: [HACKERS] BRIN cost estimate

On 27 March 2017 at 00:44, Emre Hasegeli wrote: > > If we want to have a variable which stores the number of ranges, then > > I think numRanges is better than numBlocks. I can't imagine many > > people would disagree there. > > I renamed it with other two. > > > At the very

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 2 April 2017 at 21:21, David Rowley wrote: > I've attached an updated patch which updates the regression test output of > a recent commit to include the "Unique Inner" in the expected results. > The patch must've fallen off. Attempt number 2 at attaching. --

Re: [HACKERS] Performance improvement for joins where outer side is unique

On Sun, Apr 2, 2017 at 5:21 AM, David Rowley wrote: > I've attached an updated patch which updates the regression test output of a > recent commit to include the "Unique Inner" in the expected results. Was this email supposed to have a patch attached? > Tom, I'm

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, \echo :VERSION PostgreSQL 10devel on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609, 64-bit Probably some :VERSION_NUM would make some sense. See attached PoC patch. Would it make sense? Maybe better name for you CLIENT_VERSION_NUM If

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 9:45 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > For this case can be nice to have function that returns server version as >> number some like version_num() .. 1 >> > > The server side information can be queried: > > SELECT

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 9:45 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > For this case can be nice to have function that returns server version as >> number some like version_num() .. 1 >> > > The server side information can be queried: > > SELECT

[HACKERS] Moving GiST index constant to parameter

Hi all, The GiST index has a picksplit support procedure (in gistproc.c) with a constant set up using #define - LIMIT_RATIO, set to 0.3. The PostGIS extension which shares similar code for GiST has this set to 0.1 (gserialized_gist_picksplit_2d.c). Compiling new builds, I could see a

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 27 March 2017 at 15:51, David Rowley wrote: > On 27 March 2017 at 09:28, David Rowley > wrote: > > > Patch is attached which fixes up the conflict between the expression > > evaluation performance patch. > > Seems I forgot to commit

Re: [HACKERS] Variable substitution in psql backtick expansion

For this case can be nice to have function that returns server version as number some like version_num() .. 1 Another possible trick to get out of a script which does not support \if, relying on the fact that the unexpected command is simply ignored: -- exit version below 10 \if

Re: [HACKERS] Variable substitution in psql backtick expansion

Hello Pavel, For this case can be nice to have function that returns server version as number some like version_num() .. 1 The server side information can be queried: SELECT current_setting(‘server_version_num’) AS server_version_num \gset -- 90602 However client side is not so

Re: [HACKERS] Variable substitution in psql backtick expansion

2017-04-02 8:53 GMT+02:00 Fabien COELHO : > > Bonjour Daniel, > > I think that users would rather have the option to just put >> an SQL expression behind \if. >> > > Note that this is already available indirectly, as show in the > documentation. > > SELECT

Re: [HACKERS] Variable substitution in psql backtick expansion

Bonjour Daniel, I think that users would rather have the option to just put an SQL expression behind \if. Note that this is already available indirectly, as show in the documentation. SELECT some-boolean-expression AS okay \gset \if :okay \echo boolean expression was true \else