On Sun, Sep 11, 2016 at 12:03 AM, Robert Haas wrote:
> It seems entirely unnecessary for the master and the standby to agree
> here. I think what we need is two GUCs. One of them, which affects
> only the master, controls whether the validation information is
> including in the WAL, and the othe
On 13 September 2016 at 13:27, Craig Ringer wrote:
> This was wrong for out-of-tree builds, updated.
>
> Still pending fix for PG_REGRESS path when invoked using
> $(prove_check) from PGXS
Looking further at this, I think a pgxs-specific patch to add support
for prove tests and isolation tests wo
On Mon, Sep 12, 2016 at 5:06 AM, Kuntal Ghosh
wrote:
>>+ void(*rm_checkConsistency) (XLogReaderState *record);
>>All your _checkConsistency functions share the same pattern, in short
>>they all use a for loop for each block, call each time
>>XLogReadBufferExtended, etc. And this leads to
On Tue, Sep 13, 2016 at 1:51 AM, Heikki Linnakangas wrote:
> I planned to commit this today, but while reading through it and testing, I
> ended up doing a bunch more changes, so this deserves another round of
> review.
OK, I am giving it a try. Note to people using OSX: at least for brew
there i
This was wrong for out-of-tree builds, updated.
Still pending fix for PG_REGRESS path when invoked using
$(prove_check) from PGXS
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From 462a0ab51935b45d17820b83b8e9f6abd4ad29
>
> 3. I think registerAlias stuff should happen really at the time of
>> creating paths and should be stored in fpinfo. Without that it
>> will be
>> computed every time we deparse the query. This means every time
>> we try
>> to EXPLAIN the query at
On 2016/09/09 18:47, Ashutosh Bapat wrote:
> A related change is renaming RangeBound structure in Amit
> Langote's patches to PartitionRangeBound to avoid name conflict with
> rangetypes.h. That change too should vanish once we decide where to keep
> that structure and its final name.
This change
On Sat, Sep 10, 2016 at 6:27 PM, Peter Eisentraut
wrote:
> In fsync_pgdata(), you have removed the progname from one error
> message, even though it is passed into the function.
Right. Good catch.
> Also, I think
> fsync_pgdata() should not be printing initdb's progress messages.
> That should s
Hi all
While updating an extension for 9.6 I noticed that while the
$(prove_check) definition is exposed for use by PGXS in
Makefile.global, extensions can't actually use the TAP tests because
we don't install the required Perl modules like PostgresNode.pm.
I don't see any reason not to make this
On 2016-09-13 10:54:01 +0800, Craig Ringer wrote:
> [zap]
Uhm, empty email ;)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Sep 13, 2016 at 3:58 AM, Mark Kirkwood
wrote:
> On 13/09/16 01:20, Jesper Pedersen wrote:
>>
>> On 09/01/2016 11:55 PM, Amit Kapila wrote:
>>>
>>> I have fixed all other issues you have raised. Updated patch is
>>> attached with this mail.
>>>
>>
>> The following script hangs on idx_val c
At Thu, 8 Sep 2016 07:09:51 +, "Tsunakawa, Takayuki"
wrote in
<0A3221C70F24FB45833433255569204D1F5E7D4A@G01JPEXMBYT05>
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Kyotaro
> > HORIGUCHI
> >
> > $ time psql postgres -c 'select t.a fr
Hello,
At Sat, 10 Sep 2016 07:40:16 +0200, Pavel Stehule
wrote in
> 2016-09-06 15:00 GMT+02:00 Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp>:
>
> > Hello, this is the new version of this patch. Rebased on the
> > current master.
..
> > This patch consists of the following files. Since
On Tue, Sep 13, 2016 at 10:37 AM, Andres Freund wrote:
> On 2016-09-13 10:35:38 +0900, Michael Paquier wrote:
>> On Sat, Sep 10, 2016 at 7:36 PM, Craig Ringer
>> wrote:
>> > We need it for tap tests. More and more will use pg_basebackup and it'll
>> > start hurting test speeds badly.
>>
>> Ah yes
Hello, thanks for revewing and the discussion.
At Sat, 10 Sep 2016 10:44:50 -0400, Tom Lane wrote in
<17326.1473518...@sss.pgh.pa.us>
> Michael Paquier writes:
> > On Fri, Sep 9, 2016 at 11:39 PM, Tom Lane wrote:
> >> So this change would deal nicely with the "peer application on the remote
>
On 2016-09-13 10:35:38 +0900, Michael Paquier wrote:
> On Sat, Sep 10, 2016 at 7:36 PM, Craig Ringer
> wrote:
> > We need it for tap tests. More and more will use pg_basebackup and it'll
> > start hurting test speeds badly.
>
> Ah yes, that's a good argument. hamster would suffer pretty badly
> a
On Sat, Sep 10, 2016 at 7:36 PM, Craig Ringer
wrote:
> We need it for tap tests. More and more will use pg_basebackup and it'll
> start hurting test speeds badly.
Ah yes, that's a good argument. hamster would suffer pretty badly
after that if nothing is done. I'll get an extra patch out for that,
On 2016/09/13 2:01, Corey Huinker wrote:
> Thanks for the review!
>
> I agree with all the code cleanups suggested and have made then in the
> attached patch, to save the committer some time.
Thanks. Have already marked the patch as ready for the committer.
> Also in this patch, I changed sgml
On 13 September 2016 at 06:03, Petr Jelinek wrote:
> Oh sure, I don't see that as big problem, the TupleData already contains
> type of the data it sends (to distinguish between nulls and text data) so
> that's mostly about adding some different type there and we'll also need
> type info in the c
On 2016-09-12 20:15:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 16:56:32 -0700, Andres Freund wrote:
> >> Attached is a noticeably expanded set of tests, with fixes for the stuff
> >> you'd found. I plan to push that soon-ish. Independent of the approach
> >> we'll be cho
Andres Freund writes:
> On 2016-09-12 16:56:32 -0700, Andres Freund wrote:
>> Attached is a noticeably expanded set of tests, with fixes for the stuff
>> you'd found. I plan to push that soon-ish. Independent of the approach
>> we'll be choosing, increased coverage seems quite useful.
> And for
On 9/12/16, Peter Eisentraut wrote:
> Thank you for this extensive testing. I will work on getting the bugs
> fixed. Just a couple of comments on some of your points:
>
> On 9/9/16 11:45 PM, Vitaly Burovoy wrote:
>> It compiles and passes "make check" tests, but fails with "make
>> check-world"
On Tue, Sep 13, 2016 at 3:50 AM, Peter Eisentraut
wrote:
> Add some tests. At least test that one entry from the directory list
> and one entry from the files list is not contained in the backup
> result. Testing the symlink handling would also be good. (The
> pg_basebackup tests claim that Win
On 2016-09-12 16:56:32 -0700, Andres Freund wrote:
> On 2016-09-12 09:14:47 -0700, Andres Freund wrote:
> > On 2016-09-12 10:19:14 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > >
> > > > 0001-Add-some-more-targetlist-srf-tests.patch
> > > > Add some test.
> > >
> > > I think you shoul
On 2016-09-12 09:14:47 -0700, Andres Freund wrote:
> On 2016-09-12 10:19:14 -0400, Tom Lane wrote:
> > Andres Freund writes:
> >
> > > 0001-Add-some-more-targetlist-srf-tests.patch
> > > Add some test.
> >
> > I think you should go ahead and push this tests-adding patch now, as it
> > adds doc
On 2016-09-12 19:35:22 -0400, Tom Lane wrote:
> >> You're inventing objections.
>
> > Heh, it's actually your own objection ;)
> > http://archives.postgresql.org/message-id/32673.1464023429%40sss.pgh.pa.us
>
> I'm changing my opinion in the light of unfavorable evidence. Is that
> wrong?
Nah, n
Andres Freund writes:
> On 2016-09-12 18:35:03 -0400, Tom Lane wrote:
>> You're inventing objections.
> Heh, it's actually your own objection ;)
> http://archives.postgresql.org/message-id/32673.1464023429%40sss.pgh.pa.us
I'm changing my opinion in the light of unfavorable evidence. Is that
wro
Hi,
On 2016-09-12 18:35:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think it'd be all that hard to add something like the current
> > LCM behaviour into nodeFunctionscan.c if we really wanted. But I think
> > it'll be better to just say no here.
>
> "Just say no" soon translate
Andres Freund writes:
> On 2016-09-12 17:36:07 -0400, Tom Lane wrote:
>> Um, I dunno. You've added half a thousand lines of not-highly-readable-
>> nor-extensively-commented code to the planner; that certainly reaches *my*
>> threshold of pain.
> Well, I certainly plan (and started to) make that
On 13/09/16 01:20, Jesper Pedersen wrote:
On 09/01/2016 11:55 PM, Amit Kapila wrote:
I have fixed all other issues you have raised. Updated patch is
attached with this mail.
The following script hangs on idx_val creation - just with v5, WAL patch
not applied.
Are you sure it is actually ha
On 2016-09-12 17:36:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 13:26:20 -0400, Tom Lane wrote:
> >> Stepping back a little bit ... way back at the start of this thread
> >> you muttered about possibly implementing tSRFs as a special pipeline
> >> node type, a la Result. T
On 12/09/16 22:21, Andres Freund wrote:
On 2016-09-12 21:57:39 +0200, Petr Jelinek wrote:
On 12/09/16 21:54, Andres Freund wrote:
On 2016-09-12 21:47:08 +0200, Petr Jelinek wrote:
On 09/09/16 06:33, Peter Eisentraut wrote:
The start_replication option pg_version option is not documented and
Andres Freund writes:
> On 2016-09-12 13:26:20 -0400, Tom Lane wrote:
>> Stepping back a little bit ... way back at the start of this thread
>> you muttered about possibly implementing tSRFs as a special pipeline
>> node type, a la Result. That would have the same benefits in terms
>> of being ab
Thank you for this extensive testing. I will work on getting the bugs
fixed. Just a couple of comments on some of your points:
On 9/9/16 11:45 PM, Vitaly Burovoy wrote:
> It compiles and passes "make check" tests, but fails with "make check-world"
> at:
> test foreign_data ... FAIL
Robert Haas writes:
> I think the only part of this that would be really brutal to try to
> represent is alternative join orders. I see no reasonable way for
> EXPLAIN to output useful information about what other join orders were
> considered and why they were not chosen; the only thing that see
On 2016-09-12 21:57:39 +0200, Petr Jelinek wrote:
> On 12/09/16 21:54, Andres Freund wrote:
> > On 2016-09-12 21:47:08 +0200, Petr Jelinek wrote:
> > > On 09/09/16 06:33, Peter Eisentraut wrote:
> > > > The start_replication option pg_version option is not documented and
> > > > not used in any lat
On Fri, Sep 9, 2016 at 12:35 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 9 September 2016 at 01:40, Roger Pack wrote:
>>> Today's explain tells us what loops and scans were used, and relative
>>> costs, etc. It doesn't seem to tell *why* the planner elected to use
>>> what it did.
>
>> One
On 12/09/16 21:54, Andres Freund wrote:
On 2016-09-12 21:47:08 +0200, Petr Jelinek wrote:
On 09/09/16 06:33, Peter Eisentraut wrote:
The start_replication option pg_version option is not documented and
not used in any later patch. We can probably do without it and just
rely on the protocol ver
Mark Dilger writes:
> there are several places in the code where variables defined as
> (char *) or as (const char *) are passed to the NameGetDatum()
> macro. I believe it would be better form to use CStringGetDatum()
> in these locations. I am aware that these two macros are internally
> the s
On 2016-09-12 21:47:08 +0200, Petr Jelinek wrote:
> On 09/09/16 06:33, Peter Eisentraut wrote:
> > The start_replication option pg_version option is not documented and
> > not used in any later patch. We can probably do without it and just
> > rely on the protocol version.
> >
>
> That's leftove
On 09/09/16 06:33, Peter Eisentraut wrote:
Review of 0003-Define-logical-replication-protocol-and-output-plugi.patch:
(This is still based on the Aug 31 patch set, but at quick glance I
didn't see any significant changes in the Sep 8 set.)
Yep.
The start_replication option pg_version option
Friends,
there are several places in the code where variables defined as
(char *) or as (const char *) are passed to the NameGetDatum()
macro. I believe it would be better form to use CStringGetDatum()
in these locations. I am aware that these two macros are internally
the same.
src/backend/com
Peter Eisentraut writes:
> On 8/19/16 1:04 AM, Masahiko Sawada wrote:
>> I agree with adding this as an option and removing directory by default.
>> And it looks good to me except for missing new line in usage output.
>>
>> printf(_(" -l, --label=LABEL set backup label\n"));
>> + prin
On 8/19/16 1:04 AM, Masahiko Sawada wrote:
> I agree with adding this as an option and removing directory by default.
> And it looks good to me except for missing new line in usage output.
>
> printf(_(" -l, --label=LABEL set backup label\n"));
> + printf(_(" -n, --noclean
On Mon, Sep 12, 2016 at 12:07 PM, Heikki Linnakangas wrote:
> Here's a fixed version. I'll go through Peter's comments and address those,
> but I don't think there was anything there that should affect performance
> much, so I think you can proceed with your benchmarking with this version.
> (You'
On 09/12/2016 06:47 PM, Claudio Freire wrote:
On Mon, Sep 12, 2016 at 12:02 PM, Claudio Freire wrote:
On Sun, Sep 11, 2016 at 12:47 PM, Heikki Linnakangas wrote:
Here's a new version of these patches, rebased over current master. I
squashed the two patches into one, there's not much point to
The comments on excludeDirContents are somewhat imprecise. For
example, none of those directories are actually removed or recreated
on startup, only the contents are.
The comment for pg_replslot is incorrect. I think you can copy
replication slots just fine, but you usually don't want to.
What
On 2016-09-12 14:05:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 13:48:05 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> >>> I kind of like ROWS FROM (... AS VALUE), that seems to confer the
> >>> meaning quite well. As VALUE isn't a reserved keyword, that'd afaik only
Andres Freund writes:
> On 2016-09-12 13:48:05 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> I kind of like ROWS FROM (... AS VALUE), that seems to confer the
>>> meaning quite well. As VALUE isn't a reserved keyword, that'd afaik only
>>> really work inside ROWS FROM() where AS is required
On Fri, Sep 9, 2016 at 6:39 AM, Dave Page wrote:
> Looking back at my old emails, apparently ICU 5.0 and later include
> ucol_strcollUTF8() which avoids the need to convert UTF-8 characters
> to 16 bit before sorting. RHEL 6 has the older 4.2 version of ICU.
At the risk of stating the obvious, th
On 2016-09-12 13:48:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 13:26:20 -0400, Tom Lane wrote:
> >> Andres Freund writes:
> > On 2016-09-12 12:10:01 -0400, Tom Lane wrote:
> I can't say that I like the proposed syntax much.
>
> >>> Me neither. But I haven't really fo
Andres Freund writes:
> On 2016-09-12 13:26:20 -0400, Tom Lane wrote:
>> Andres Freund writes:
> On 2016-09-12 12:10:01 -0400, Tom Lane wrote:
I can't say that I like the proposed syntax much.
>>> Me neither. But I haven't really found a better approach. It seems
>>> kinda consistent to ha
On 2016-09-12 13:26:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 12:10:01 -0400, Tom Lane wrote:
> >> I can't say that I like the proposed syntax much.
>
> > Me neither. But I haven't really found a better approach. It seems
> > kinda consistent to have ROWS FROM (... AS (
Hi,
On 2016-09-12 13:26:20 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-09-12 12:10:01 -0400, Tom Lane wrote:
> >> I can't say that I like the proposed syntax much.
>
> > Me neither. But I haven't really found a better approach. It seems
> > kinda consistent to have ROWS FROM (..
Andres Freund writes:
> On 2016-09-12 12:10:01 -0400, Tom Lane wrote:
>> I can't say that I like the proposed syntax much.
> Me neither. But I haven't really found a better approach. It seems
> kinda consistent to have ROWS FROM (... AS ()) change the picked out
> columns to 0, and just return t
On Mon, Sep 12, 2016 at 1:59 AM, Amit Langote wrote:
> On 2016/09/11 8:04, Corey Huinker wrote:
> > V2 of this patch:
> >
> > Changes:
> > * rebased to most recent master
> > * removed non-tap test that assumed the existence of Unix sed program
> > * added non-tap test that assumes the existence
Hi,
On 09/07/2016 05:58 AM, Amit Kapila wrote:
Okay, I have fixed this issue as explained above. Apart from that, I
have fixed another issue reported by Mark Kirkwood upthread and few
other issues found during internal testing by Ashutosh Sharma.
The locking issue reported by Mark and Ashutosh
Hi,
On 2016-09-12 12:10:01 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 0003-Avoid-materializing-SRFs-in-the-FROM-list.patch
> > To avoid performance regressions from moving SRFM_ValuePerCall SRFs to
> > ROWS FROM, nodeFunctionscan.c needs to support not materializing
> > output.
>
>
On 09/05/2016 02:52 PM, Heikki Linnakangas wrote:
On 09/05/2016 03:23 AM, Tom Lane wrote:
Judging by the number of people who have popped up recently with their
own OpenSSL 1.1 patches, I think there is going to be a lot of demand for
back-patching some sort of 1.1 support into our back branches
On Wed, Sep 7, 2016 at 11:44 AM, Peter Geoghegan wrote:
> I attach my V3.
I should point out that I'm leaving to go on Vacation this weekend.
I'll be away for a week, and will not be answering mail during that
period. If anyone has any questions on this for me, it might be
preferable to ask them
Andres Freund writes:
> On 2016-09-12 11:29:37 -0400, Tom Lane wrote:
>> I'm on board with disallowing SRFs in UPDATE, because it produces
>> underdetermined and unspecified results; but the other restriction
>> seems 100% arbitrary. There is no semantic difference between
>> SELECT a, b FROM ...
On 2016-09-12 11:29:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 0002-Shore-up-some-weird-corner-cases-for-targetlist-SRFs.patch
> > Forbid UPDATE ... SET foo = SRF() and ORDER BY / GROUP BY containing
> > SRFs that would change the number of returned rows. Without the
> > latter e
Thanks for the review!
I agree with all the code cleanups suggested and have made then in the
attached patch, to save the committer some time.
Also in this patch, I changed sgml para to
Changing table-level options requires superuser privileges, for security
reasons: only a superuser should
On 2016-09-12 10:19:14 -0400, Tom Lane wrote:
> Andres Freund writes:
>
> > 0001-Add-some-more-targetlist-srf-tests.patch
> > Add some test.
>
> I think you should go ahead and push this tests-adding patch now, as it
> adds documentation of the current behavior that is a good thing to have
> i
Andres Freund writes:
> 0003-Avoid-materializing-SRFs-in-the-FROM-list.patch
> To avoid performance regressions from moving SRFM_ValuePerCall SRFs to
> ROWS FROM, nodeFunctionscan.c needs to support not materializing
> output.
Personally I'd put this one later, as it's a performance optimiz
On Mon, Sep 12, 2016 at 8:47 AM, Claudio Freire wrote:
> I spoke too soon, git AM had failed and I didn't notice.
I wrote the regression test that causes Postgres to crash with the
patch applied. It tests, among other things, that CLUSTER tuples are
fixed-up by a routine like the current MOVETUP(
Andres Freund writes:
> 0002-Shore-up-some-weird-corner-cases-for-targetlist-SRFs.patch
> Forbid UPDATE ... SET foo = SRF() and ORDER BY / GROUP BY containing
> SRFs that would change the number of returned rows. Without the
> latter e.g. SELECT 1 ORDER BY generate_series(1,10); returns 10
On Sun, Sep 11, 2016 at 12:47 PM, Heikki Linnakangas wrote:
> Here's a new version of these patches, rebased over current master. I
> squashed the two patches into one, there's not much point to keep them
> separate.
I don't know what was up with the other ones, but this one works fine.
Benchma
On Mon, Sep 12, 2016 at 8:14 AM, Kevin Grittner wrote:
> On Mon, Sep 12, 2016 at 7:55 AM, Tom Lane wrote:
>> The query you committed is flat wrong, because it doesn't
>> account for database ownership being granted via role membership.
>
> Ah, there was a flaw in my testing script. It appeared
Andres Freund writes:
> Attached is a significantly updated patch series (see the mail one up
> for details about what this is, I don't want to quote it in its
> entirety).
I've finally cleared my plate enough to start reviewing this patchset.
> 0001-Add-some-more-targetlist-srf-tests.patch
>
On 3 August 2016 at 02:58, Tomas Vondra wrote:
> Attached is v19 of the "multivariate stats" patch series
Hi,
I started looking at this - just at a very high level - I've not read
much of the detail yet, but here are some initial review comments.
I think the overall infrastructure approach for
On 09/01/2016 11:55 PM, Amit Kapila wrote:
I have fixed all other issues you have raised. Updated patch is
attached with this mail.
The following script hangs on idx_val creation - just with v5, WAL patch
not applied.
Best regards,
Jesper
zero.sql
Description: application/sql
--
Sent
ilm...@ilmari.org (Dagfinn Ilmari Mannsåker) writes:
> Hi hackers,
>
> Here's a patch to add psql tab completion for the recently-added ALTER
> TYPE … RENAME VALUE feature (thanks to Tom for fixing it up and
> committing it).
I've added it to the 2016-11 commit fest:
https://commitfest.postgresql
On Mon, Sep 12, 2016 at 7:55 AM, Tom Lane wrote:
> Kevin Grittner writes:
>> But that gives incorrect results for the case I asked about earlier
>> on the thread, while the query I pushed gives correct results:
>
> AFAICS, my query gives correct results for that case. bob is permitted
> to copy
Kevin Grittner writes:
> But that gives incorrect results for the case I asked about earlier
> on the thread, while the query I pushed gives correct results:
AFAICS, my query gives correct results for that case. bob is permitted
to copy fred's databases db1 and postgres, or would be if he had cr
On Mon, Sep 12, 2016 at 9:08 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Mon, Sep 12, 2016 at 4:19 PM, Simon Riggs wrote:
>>> Why would we need to backpatch this commit?
>
>> You are right there is no need to get that into 9.6. Sorry for the mistake.
>
> Oh, that's my fault, I'd incorrec
On 9/12/16, Kevin Grittner wrote:
> On Sun, Sep 11, 2016 at 8:07 PM, Tom Lane wrote:
>
>> I wasn't aware that this patch was doing anything nontrivial ...
>
> Well, it is not doing anything other than showing candidate
> templates for tab completion beyond those flagged as template
> databases.
>
On 2016/09/09 21:35, Etsuro Fujita wrote:
On 2016/09/08 19:51, Etsuro Fujita wrote:
On 2016/09/06 22:07, Ashutosh Bapat wrote:
This patch tries to do two things at a time 1. support join pushdown for
FULL join when the joining relations have remote conditions 2. better
support for fetching plac
On Sun, Sep 11, 2016 at 8:07 PM, Tom Lane wrote:
> I wasn't aware that this patch was doing anything nontrivial ...
Well, it is not doing anything other than showing candidate
templates for tab completion beyond those flagged as template
databases.
> After looking at it I think it's basically u
Michael Paquier writes:
> On Mon, Sep 12, 2016 at 4:19 PM, Simon Riggs wrote:
>> Why would we need to backpatch this commit?
> You are right there is no need to get that into 9.6. Sorry for the mistake.
Oh, that's my fault, I'd incorrectly remembered this commit as having been
further back than
On Mon, Sep 12, 2016 at 12:20 PM, Prabhat Sahu <
prabhat.s...@enterprisedb.com> wrote:
> Hi,
>
> While testing "Aggregate pushdown", i found the below error:
> -- GROUP BY alias showing different behavior after adding patch.
>
> -- Create table "t1", insert few records.
> create table t1(c1 int);
On Thu, Sep 8, 2016 at 10:41 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
>
>
>> While checking for shippability, we build the target list which is passed
>> to
>> the foreign server as fdw_scan_tlist. The target list contains
>> a. All the GROUP BY expressions
>> b. Shippable
Hi hackers,
Here's a patch to add psql tab completion for the recently-added ALTER
TYPE … RENAME VALUE feature (thanks to Tom for fixing it up and
committing it).
It's modelled on the ALTER TYPE … RENAME ATTRIBUTE completion, but
tweaked to return string literals instead of identifiers.
- ilmari
On Tue, Sep 6, 2016 at 8:39 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 06.09.2016 07:44, Pavan Deolasee:
>
> 2. I don't understand the difference between PageGetItemHeapHeaderOnly()
> and PageGetItemHeap(). They seem to do exactly the same thing and can be
> used interchang
Hello,
At Thu, 01 Sep 2016 16:12:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160901.161231.110068639.horiguchi.kyot...@lab.ntt.co.jp>
> There's perfomance degradation for non-asynchronous nodes, as
> shown as 't0' below.
>
> The patch adds two "if-then" and one additional fun
On Mon, Sep 12, 2016 at 4:59 PM, Simon Riggs wrote:
> On 12 September 2016 at 08:28, Michael Paquier
> wrote:
>> On Mon, Sep 12, 2016 at 4:19 PM, Simon Riggs wrote:
>>> On 12 September 2016 at 03:27, Michael Paquier
>>> wrote:
>>>
So I'd propose the attached for 9.6 and HEAD.
>>>
>>> The $
On Fri, Sep 9, 2016 at 6:49 AM, Andres Freund wrote:
> On 2016-09-08 18:13:06 -0300, Alvaro Herrera wrote:
>> > I can't vouch for the windows stuff, and
>> > the invocations indeed look vulnerable. I'm not sure if the fix actually
>> > matters on windows, given . is the default for pretty much eve
On 11 September 2016 at 23:56, Daniel Gustafsson wrote:
> The IDENTIFICATION filename in src/backend/storage/ipc/dsm_impl.c is
> incorrectly labelling the file dsm.c. Patch fixing the typo attached.
>
> cheers ./daniel
Applied, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
On 12 September 2016 at 08:28, Michael Paquier
wrote:
> On Mon, Sep 12, 2016 at 4:19 PM, Simon Riggs wrote:
>> On 12 September 2016 at 03:27, Michael Paquier
>> wrote:
>>
>>> So I'd propose the attached for 9.6 and HEAD.
>>
>> The $OP commit was against HEAD only, not against 9.6
>>
>> Why would
Hi Fabien,
On 2016/09/07 23:01, Fabien COELHO wrote:
>> Custom script looks like:
>>
>> \;
>> select a \into a
>>from tab where a = 1;
>> \set i debug(:a)
>>
>> I get the following error:
>>
>> undefined variable "a"
>> client 0 aborted in state 1; execution of meta-command failed
>
> Good ca
On Mon, Sep 12, 2016 at 4:19 PM, Simon Riggs wrote:
> On 12 September 2016 at 03:27, Michael Paquier
> wrote:
>
>> So I'd propose the attached for 9.6 and HEAD.
>
> The $OP commit was against HEAD only, not against 9.6
>
> Why would we need to backpatch this commit?
You are right there is no nee
On 12 September 2016 at 03:27, Michael Paquier
wrote:
> So I'd propose the attached for 9.6 and HEAD.
The $OP commit was against HEAD only, not against 9.6
Why would we need to backpatch this commit?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
2016-09-12 9:07 GMT+02:00 Craig Ringer :
> On 12 September 2016 at 14:29, Pavel Stehule
> wrote:
>
> >> I would've expected once per query. There's no way the expressions can
> >> reference the row data, so there's no reason to evaluate them each
> >> time.
> >
> > I disagree - it is hypothetical
On 12 September 2016 at 14:29, Pavel Stehule wrote:
>> I would've expected once per query. There's no way the expressions can
>> reference the row data, so there's no reason to evaluate them each
>> time.
>
> I disagree - it is hypothetical situation but it is possible
>
> if somebody store docum
95 matches
Mail list logo
