> > Similarly, a partition constraint
> > should also be enforced at the foreign server. Probably we should
> > update documentation of create foreign table to mention this.
>
> That is a good idea.
>
> Here's the patch. I am not able to build documents on my laptop because of
recent changes in d63
Hi,
I noticed that a deadlock can occur due to the way locking when dropping a
partition proceeds. Steps to reproduce:
1. Attach debugger to two sessions, one of which will do a select on the
partitioned parent and the other will drop one of its partitions.
2. In the first debugging session, se
Hi,
Recently my doc build has started failing with errors
runtime error: file stylesheet.xsl line 57 element call-template
The called template 'id.attribute' was not found.
runtime error: file stylesheet.xsl line 57 element call-template
The called template 'id.attribute' was not found.
runtime er
On 2017/04/01 1:32, Jeff Janes wrote:
On Thu, Mar 23, 2017 at 5:20 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
Done. Attached is a new version of the patch.
Is the fix for 9.6.3 going to be just a back port of this, or will it
look different?
+1 for backporting; althou
For some reason, my reply got sent to only Amit Langote instead of
reply-to-all. Below is the mail reply. Thanks Amit Langote for
bringing this to my notice.
On 31 March 2017 at 16:54, Amit Khandekar wrote:
> On 31 March 2017 at 14:04, Amit Langote wrote:
>> On 2017/03/28 19:12, Amit Khandekar w
Hi,
Attached fixes a comment typo in logical/worker.c file.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_typo_logical_worker_c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, Apr 1, 2017 at 4:28 PM, Noah Misch wrote:
> The pg_upgrade test suite originated in an age when "make check-world" was
> forbidden to depend on Perl; the choice was a shell script or a C program. We
> do maintain vcregress.pl:upgradecheck(), a Windows-specific Perl port of the
> suite. M
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 per-relation reindex has t
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 restore WL_LATCH_SET? I won't
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);
>>>
>>> /*
>>> + *
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 gather merge code needs a bit more test cover
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
> src/port/snpri
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 to do
> that now that
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
> its own subsection. Maybe a lon
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 first, but it didn't work with Visual
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 this
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 C99.
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 state) , client does not
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
> given the extra time?
Or perhap
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 tuplestores (if specifie
>
> > 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!)
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 a couple of comments, and
> slight
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 testing, and a mention in the docs that
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. Update the comment to reflect the current signature
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 is not much
> backsla
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.
--
Peter Geogheg
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
static, so it can be
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 fixes. So this item
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
-
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 gmail.com>
> > On Fri, Mar 17, 2017 at 6:48 PM, Kyotaro HORIGUCHI <
>
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
\
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 ${VA
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:tested, passed
>
> H
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 info
"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 command.
> Okay, leaving out \r
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 to run out of namespa
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 b/doc/src/sgml/
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 also powerful, provided
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
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
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 Solution.pm.
More to the
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/
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 \p
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 adds both client & serv
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 conflicts from
>> future ad
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 of other spare parts, along the
> >> lines of COALESCE or perhaps
>
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 varna
"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 mention
of the variant argum
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 o
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
>> \if not defined(x)
> In light of the backticks
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 sugge
>
>
> 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
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) 5.4.0 20160609, 64-bit
Probably some
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 variable is referenced, or a way to detect that a
> >
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 previous_
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 same thing, but
> maybe n
"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 was
confusing. We can cert
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 PoC patch.
>>> Would i
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 index stats (cannot
- 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), ba
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 (pgsql-hackers@postgresql.org)
To make change
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=# s
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 us
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.
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 question
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 analy
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 m
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 documen
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 a/doc/src/
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 least please write a c
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.
--
David Rowley
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 wondering if you think you'll get
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 i
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 current_setting(‘server_version_num’)
> AS server_
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 current_setting(‘server_version_num’)
> AS server_
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
differenc
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 locally before creating the patch... Here's
> the actual pat
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 fals
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
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 some-boolean-expression AS okay \gset
>
80 matches
Mail list logo
