On Thu, Mar 22, 2018 at 7:22 AM, Claudio Freire
wrote:
>
> If you're not planning on making any further changes, would you mind
> posting a coalesced patch?
>
> Notice that I removed the last offset thing only halfway, so it would
> need some cleanup.
>
Here is an updated patch. I removed the la
On 21 March 2018 at 16:29, Melanie Plageman wrote:
> For a small performance hit but an improvement in readability, the length
> check
> can be moved from the individual group by and distinct clause checks into the
> helper function
>
> if (list_length(parse->distinctClause) < 2)
>
On Thu, Mar 22, 2018 at 3:26 AM, Robert Haas wrote:
>
> Is there a good reason not to use input_rel->relids as the input to
> fetch_upper_rel() in all cases, rather than just at subordinate
> levels?
>
That would simplify some code in these patches. We have set
upper_rel->relids to NULL for non-o
On Tue, Mar 20, 2018 at 10:09 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> On 2018/03/20 13:30, Amit Langote wrote:
> > I have incorporated your patch in the main patch after updating the
> > comments a bit. Also, now that ee49f49 is in [1], the transition
> > table related test
On 2018/03/20 21:41, David Rowley wrote:
> On 21 March 2018 at 00:07, Amit Langote wrote:
>> Attached is further revised version.
>
> In the 0004 patch I see:
>
> @@ -1439,6 +1441,10 @@ inheritance_planner(PlannerInfo *root)
> if (IS_DUMMY_PATH(subpath))
> continue;
>
> + /* Add the current
On Wed, Mar 07, 2018 at 06:17:15PM -0500, Tom Lane wrote:
> I agree. My recollection is that we expended substantial sweat to make
> that type of setup work, and I do not think it was for idle reasons.
> The fact that the behavior is very old doesn't mean it was a bad choice.
> (Also, the fact tha
On Wed, Mar 07, 2018 at 05:06:59PM -0500, Robert Haas wrote:
> TBH I find that Homebrew example pretty odd. I would understand
> installing each major release in a version directory, but putting
> every point release in a different versioned directory seems like a
> bad plan.
That's a project po
Hi,
On 2018-03-22 16:09:51 +1300, Thomas Munro wrote:
> On Thu, Mar 22, 2018 at 1:36 PM, Thomas Munro
> wrote:
> > I've now run out of things to complain about for now. Nice work!
>
> I jumped on a POWER8 box. As expected, the same breakage occurs. So
> I hacked LLVM 6.0 thusly:
>
> diff --g
I wrote:
> I looked for rules with this bug by looking for comments that
> mention parser/Makefile. There may well be some more, but I have
> no good idea how to find them --- any thoughts?
I realized that grepping for line-ending semicolons in makefiles
would be a pretty efficient way to check t
On Thu, Mar 22, 2018 at 1:36 PM, Thomas Munro
wrote:
> I've now run out of things to complain about for now. Nice work!
I jumped on a POWER8 box. As expected, the same breakage occurs. So
I hacked LLVM 6.0 thusly:
diff --git a/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
b/lib/ExecutionEngine
Hi David.
On 2018/03/21 23:31, David Steele wrote:
> Hi Amit,
>
> On 3/6/18 9:44 AM, David Steele wrote:
>> On 3/2/18 2:27 AM, Amit Langote wrote:
>>> On 2018/03/02 15:58, Andres Freund wrote:
On 2018-02-02 17:00:24 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
>> There might be
On Tue, Mar 20, 2018 at 10:55:04AM -0400, Peter Eisentraut wrote:
> On 3/19/18 22:58, Michael Paquier wrote:
>> - Extend copy_file so as it is able to use fcopyfile.
>
> fcopyfile() does not support cloning. (This is not documented.)
You are right. I have been reading the documentation here to
Michael Paquier writes:
> On Wed, Mar 21, 2018 at 07:48:02AM -0400, Peter Eisentraut wrote:
>> I've pushed the configure tests. Let's see what they say.
> At least the buildfarm is green. Browsing the buildfarm logs manually
> is kind of annoying for any normal human being. I guess that you ha
On Mon, Mar 19, 2018 at 12:06 PM, Claudio Freire wrote:
> On Mon, Mar 19, 2018 at 11:57 AM, Pavan Deolasee
> wrote:
>>
>>
>> On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire
>> wrote:
>>>
>>>
>>>
>>> I applied the attached patches on top of your patch, so it would be
>>> nice to see if you can gi
On Thu, Mar 22, 2018 at 09:42:35AM +0800, Craig Ringer wrote:
> I'm super excited by the idea of multi-version support in TAP, if that's
> what you mean.
>
> Why? Because I use TAP heavily in extensions. Especially replication
> extensions. Which like to talk across multiple versions. I currently
On 22 March 2018 at 09:39, Michael Paquier wrote:
> On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote:
> > On 3/6/18 4:12 PM, Tom Lane wrote:
> > It seems the consensus is that we'll need a build farm update before we
> > can move forward with the patch and that we don't need to wait l
On Wed, Mar 21, 2018 at 07:48:02AM -0400, Peter Eisentraut wrote:
> I've pushed the configure tests. Let's see what they say.
At least the buildfarm is green. Browsing the buildfarm logs manually
is kind of annoying for any normal human being. I guess that you have
access to the database holdin
On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote:
> On 3/6/18 4:12 PM, Tom Lane wrote:
> It seems the consensus is that we'll need a build farm update before we
> can move forward with the patch and that we don't need to wait long for
> people to upgrade.
>
> Andrew, do you have a date
On Wed, Mar 21, 2018 at 09:07:41AM +0100, Michael Banck wrote:
> Am Dienstag, den 20.03.2018, 19:19 -0400 schrieb Stephen Frost:
>> Instead of trying to use pg_dump for this, we should provide a way to
>> actually check for corruption across everything (instead of just the
>> heap..), and have all
Michael Paquier writes:
> On Wed, Mar 21, 2018 at 01:40:23AM -0400, Tom Lane wrote:
>> I don't mind making it an ereport, but I think it needs to be FATAL
>> for the reason stated in the comment.
> Okay for the FATAL. I can see that at this time of the day your patch
> 0002 has already been push
Hi Nikhil,
I've been looking at this patch over the past few days, so here are my
thoughts so far ...
decoding aborted transactions
=
First, let's talk about handling of aborted transaction, which was
originally discussed in thread [1]. I'll try to summarize the stat
On Wed, Mar 21, 2018 at 01:40:23AM -0400, Tom Lane wrote:
> Michael Paquier writes:
>> On Tue, Mar 20, 2018 at 01:27:35PM -0400, Tom Lane wrote:
>>> + if (flags & GUC_LIST_QUOTE)
>>> + elog(FATAL, "extensions cannot define GUC_LIST_QUOTE
>>> variables");
>
>> This would be be
On Wed, Mar 21, 2018 at 8:06 PM, Thomas Munro
wrote:
> "make -C src/interfaces/ecpg/test check" consistently fails on my macOS
> machine:
>
> test compat_oracle/char_array ... stderr source FAILED
I can't reproduce this anymore on the tip of your jit branch. I don't
know what caused it or w
Here's v8, which addresses all your comments except the doc updates. I
added a few more tests, too. Thanks for the review! I intend to commit
this shortly, probably not before Friday to give some more time for
others to review/comment.
Some notes:
Peter Eisentraut wrote:
> I'm not sure why yo
On Thu, Mar 22, 2018 at 11:46 AM, Andres Freund wrote:
> On 2018-03-22 11:36:47 +1300, Thomas Munro wrote:
>> Not sure if we'll want to try to actively identify and avoid known
>> buggy versions or not?
>
> I'm currently not inclined to invest a lot of effort into it, besides
> trying to get the b
> On 12 March 2018 at 06:00, Ashutosh Bapat
> wrote:
> Thanks for the note. Here are rebased patches.
Since I started to look at this patch, I can share few random notes (although
it's not a complete review, I'm in the progress now), maybe it can be helpful.
In `partition_range_bounds_merge`
On 3/12/18 11:26, Nikita Glukhov wrote:
> I have reviewed this patch. Attached new 6th version of the patch with
> v5-v6 delta-patch.
Thanks for the update. I'm working on committing this.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
Hi,
On 2018-03-22 11:36:47 +1300, Thomas Munro wrote:
> On Thu, Mar 22, 2018 at 10:59 AM, Andres Freund wrote:
> > On 2018-03-22 10:50:52 +1300, Thomas Munro wrote:
> >> Hmm. There is no LLVM 6 in backports.
> >
> > I think there now is:
> > https://packages.debian.org/search?keywords=llvm&searc
On Thu, Mar 22, 2018 at 10:59 AM, Andres Freund wrote:
> On 2018-03-22 10:50:52 +1300, Thomas Munro wrote:
>> Hmm. There is no LLVM 6 in backports.
>
> I think there now is:
> https://packages.debian.org/search?keywords=llvm&searchon=names§ion=all&suite=stretch-backports
>
> Package llvm-6.0-dev
Hello Kackers,
As a new user of PostgreSQL, I have started using pg_stat_statements, and
was pleased but a little surprised:
First of all, the normalized form of the query string makes it impossible to
be used in EXPLAIN commands.
Second, normalized constants and parameters values where missing
On 2018-03-22 10:50:52 +1300, Thomas Munro wrote:
> On Thu, Mar 22, 2018 at 10:44 AM, Andres Freund wrote:
> > On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
> >> Next up, I have an arm64 system running Debian 9.4. It bombs in
> >> "make check" and in simple tests:
> >
> > Any chance you could
On Wed, Mar 21, 2018 at 11:33 AM, Jeevan Chalke
wrote:
> Let me try to explain this:
> 1. GROUPING_CAN_PARTITIONWISE_AGG
> 2. extra->is_partial_aggregation
> 3. extra->perform_partial_partitionwise_aggregation
Please find attached an incremental patch that attempts to refactor
this logic into a s
On Thu, Mar 22, 2018 at 10:50 AM, Thomas Munro
wrote:
> On Thu, Mar 22, 2018 at 10:44 AM, Andres Freund wrote:
>> On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
>>> Next up, I have an arm64 system running Debian 9.4. It bombs in
>>> "make check" and in simple tests:
>>
>> Any chance you could
On Thu, Mar 22, 2018 at 10:44 AM, Andres Freund wrote:
> On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
>> Next up, I have an arm64 system running Debian 9.4. It bombs in
>> "make check" and in simple tests:
>
> Any chance you could try w/ LLVM 6? It looks like some parts of ORC
> only got aa
On Tue, Mar 20, 2018 at 6:57 AM, Michael Paquier wrote:
> Now, why are people using pg_dump > /dev/null? Mainly the lack of
> better tools, which would be actually able to detect pages in corrupted
> pages in one run, and not only heap pages. I honestly think that
> amcheck is something that we
On Thu, Mar 22, 2018 at 10:36 AM, Andres Freund wrote:
> On 2018-03-21 14:21:01 -0700, Andres Freund wrote:
>> I think it's I that did something wrong not you. And the architecture
>> thing is a non-issue, because we're taking the target triple from the
>> right place. I think it's a separate iss
Hi,
On 2018-03-22 09:31:12 +1300, Thomas Munro wrote:
> Aside from whatever problem is causing this, we can see that there is
> no top-level handling of exceptions. That's probably fine if we are
> in a no throw scenario (unless there is something seriously corrupted,
> as is probably the case he
Hi,
On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
> Next up, I have an arm64 system running Debian 9.4. It bombs in
> "make check" and in simple tests:
Any chance you could try w/ LLVM 6? It looks like some parts of ORC
only got aarch64 in LLVM 6. I didn't *think* those were necessary, but
In https://postgr.es/m/32497.1519858...@sss.pgh.pa.us
I griped about a weird make failure I was having with VPATH builds.
I did not push the patch I suggested at the time, because I didn't
understand why it seemed to resolve the issue, and because neither
I nor anyone else could reproduce the issue
Hi,
On 2018-03-21 14:21:01 -0700, Andres Freund wrote:
> I think it's I that did something wrong not you. And the architecture
> thing is a non-issue, because we're taking the target triple from the
> right place. I think it's a separate issue. Notably the generated code
> is apparently corrupt,
Hi,
On 2018-03-22 10:09:23 +1300, Thomas Munro wrote:
> > FWIW, a 32bit chroot, on a 64bit kernel works:
> >
> > 2018-03-21 20:57:56.576 UTC [3708] DEBUG: successfully loaded LLVM in
> > current session
> > 2018-03-21 20:57:56.577 UTC [3708] DEBUG: JIT detected CPU "skylake", with
> > features
On Thu, Mar 22, 2018 at 9:59 AM, Andres Freund wrote:
> On 2018-03-22 09:51:01 +1300, Thomas Munro wrote:
>> Hah, that makes sense. I tried setting cpu to "x86", and now it fails
>> differently:
>
> Did you change the variable, or replace the value that's passed to the
> LLVMCreateTargetMachine()
On 2018-03-22 09:51:01 +1300, Thomas Munro wrote:
> On Thu, Mar 22, 2018 at 9:09 AM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-03-22 09:00:19 +1300, Thomas Munro wrote:
> >> 64 bit CPU, 32 bit OS. I didn't try Debian multi-arch i386 support on
> >> an amd64 system, but that's probably an easie
On Thu, Mar 22, 2018 at 9:09 AM, Andres Freund wrote:
> Hi,
>
> On 2018-03-22 09:00:19 +1300, Thomas Munro wrote:
>> 64 bit CPU, 32 bit OS. I didn't try Debian multi-arch i386 support on
>> an amd64 system, but that's probably an easier way to do this if you
>> already have one of those...
>
> Ah
Andres Freund writes:
> Hi,
>
> On 2018-03-21 20:06:49 +1300, Thomas Munro wrote:
>> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote:
>> > Indeed. I've pushed a rebased version now, that basically just fixes the
>> > issue Thomas observed.
>>
>> I set up a 32 bit i386 virtual machine and i
On Thu, Mar 22, 2018 at 9:06 AM, Andres Freund wrote:
> On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
>> Next up, I have an arm64 system running Debian 9.4. It bombs in
>> "make check" and in simple tests:
>
> Hum. Is it running a 32bit or 64 bit kernel/os?
checking size of void *... 8
>> .
Hi,
On 2018-03-22 09:00:19 +1300, Thomas Munro wrote:
> On Thu, Mar 22, 2018 at 8:47 AM, Andres Freund wrote:
> > On 2018-03-21 20:06:49 +1300, Thomas Munro wrote:
> >> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote:
> >> > Indeed. I've pushed a rebased version now, that basically just fix
On 2018-03-21 23:10:27 +1300, Thomas Munro wrote:
> On Wed, Mar 21, 2018 at 8:06 PM, Thomas Munro
> wrote:
> > On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote:
> >> Indeed. I've pushed a rebased version now, that basically just fixes the
> >> issue Thomas observed.
> >
> > I set up a 32 bit
Hi,
On 2018-03-21 08:26:28 +0100, Catalin Iacob wrote:
> On Wed, Mar 21, 2018 at 4:07 AM, Andres Freund wrote:
> > Indeed. I've pushed a rebased version now, that basically just fixes the
> > issue Thomas observed.
>
> Testing 2d6f2fba from your repository configured --with-llvm I noticed
> some
On Thu, Mar 22, 2018 at 8:47 AM, Andres Freund wrote:
> On 2018-03-21 20:06:49 +1300, Thomas Munro wrote:
>> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote:
>> > Indeed. I've pushed a rebased version now, that basically just fixes the
>> > issue Thomas observed.
>>
>> I set up a 32 bit i386
Hi,
On 2018-03-21 20:06:49 +1300, Thomas Munro wrote:
> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote:
> > Indeed. I've pushed a rebased version now, that basically just fixes the
> > issue Thomas observed.
>
> I set up a 32 bit i386 virtual machine and installed Debian 9.4.
> Compiler w
On Wed, Mar 21, 2018 at 5:23 AM, Pavan Deolasee
wrote:
>> * The docs say "A condition cannot contain subqueries, set returning
>> functions, nor can it contain window or aggregate functions". Thought
>> it can now?
>
>
> Yes, it now supports sub-queries. What about set-returning, aggregates etc?
On 3/15/18 4:33 AM, Andrew Dunstan wrote:
>
> rebased and mostly indented patch version attached. It's actually
> moderately difficult to produce a nicely indented patch that is
> against non-pgindented code. We should look at that a bit. Another
> item for my TODO list.
It looks like this should
On 3/15/18 1:12 AM, Kyotaro HORIGUCHI wrote:
> At Mon, 12 Mar 2018 17:34:08 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in >
> The attached is the patch set including this plancache stuff.
>
> 0001- catcache time-based expiration (The origin of this thread)
> 0002- introduces dynahas
On Thu, Mar 8, 2018 at 7:13 PM, Anastasia Lubennikova <
a.lubennik...@postgrespro.ru> wrote:
> 06.03.2018 11:52, Thomas Munro:
>
>> On Wed, Jan 31, 2018 at 3:09 AM, Anastasia Lubennikova
>> wrote:
>>
>>> Thank you for reviewing. All mentioned issues are fixed.
>>>
>> == Applying patch 0002-coveri
On 3/21/18, 12:57 PM, "Peter Eisentraut"
wrote:
> On 3/13/18 20:53, Bossart, Nathan wrote:
>> 0001: Fix division-by-zero error in pg_controldata
>
> committed that
Thanks!
>> 0002: Fix division-by-zero error in pg_resetwal
>
> This looks a bit more complicated than necessary to me. I think
Hello Teodor,
Patch seems usefull and commitable except comments in conditional.[ch]. I'd
like to top/header comment in each file more detailed and descriptive. As for
now it mentions only psql usage without explaining how it is basic or common.
Indeed, it was not updated.
I've fixed the fi
On 3/13/18 20:53, Bossart, Nathan wrote:
> Here is a new set of patches that addresses most of Peter's feedback.
> I've split it into four pieces:
>
> 0001: Fix division-by-zero error in pg_controldata
committed that
> 0002: Fix division-by-zero error in pg_resetwal
This looks a bit more co
Alvaro Herrera writes:
> David Steele wrote:
>> Are you planning to update this patch? If not, I think it should be
>> marked as Returned with Feedback and submitted to the next CF once it
>> has been updated.
> This is no new development, only code movement. I think it would be
> worse to have
Hi Vik,
On 3/10/18 9:02 AM, Tomas Vondra wrote:
>
> I've looked at this patch today. I like the idea / intent in general, as
> it helps with some investigation tasks. That being said, I have a couple
> of questions/comments based on read through the patch:
It looks like there are some privacy co
On 01.03.2018 23:15, Andres Freund wrote:
Hi,
This patch seems like quite a good improvement. One thing I've not
really looked at but am slightly concerned in passing: Are there cases
where we now would do a lot of predicate pruning work even though the
overhead of just evaluating the qual is
Hi Daniel,
On 3/10/18 1:49 AM, Fabien COELHO wrote:
>
>>> recordsep in the unaligned mode doesn't play the role of a line ending
>>> because the last line is not finished by recordsep. According to the
>>> source
>>> code, this is intended, see print_unaligned_text() in print.c:
>>
>> Something e
Matheus de Oliveira wrote:
> You think this should be applied to all versions that support ALTER
> CONSTRAINT, right?
This seems a bug fix to me, so yes.
> I can do that, no problem. It'll take awhile though, I'm on a trip and will
> be home around March 20th.
Please do send at your earliest co
Hi Matheus,
Do you plan to post an updated version of the patch, of what is your
response to the points raised last week?
I still haven't made my mind regarding usefulness of range opclasses, so
I suggest to split the patch into two parts - 0001 for the opclasses
we're confident are useful, and 0
Tomas Vondra writes:
> On 03/21/2018 02:18 PM, Jaime Soler wrote:
>> We still get out of memory error during pg_dump execution
>> pg_dump: reading large objects
>> out of memory
> H ... that likely happens because of this for loop copying a lot of
> data:
> https://github.com/postgres/postgre
On 21 March 2018 at 21:20, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 3/21/18 03:08, Craig Ringer wrote:
> > Why was relrewrite / Anum_pg_class_relrewrite inserted at position 28,
> > not appended to pg_class?
> >
> > I don't see how it'd cause any harm, I'm just curious abou
On Wed, Mar 21, 2018 at 7:46 PM, Robert Haas wrote:
> On Wed, Mar 21, 2018 at 8:01 AM, Jeevan Chalke
> wrote:
> >> In the patch as proposed, create_partial_grouping_paths() can get
> >> called even if GROUPING_CAN_PARTIAL_AGG is not set. I think that's
> >> wrong.
> >
> > I don't think so. For
John Naylor writes:
> [ v11-bootstrap-data-conversion.tar.gz ]
I've done a round of review work on this, focusing on the Makefile
infrastructure. I found a bunch of problems with parallel builds and
VPATH builds, which are addressed in the attached incremental patch.
The parallel-build issues a
Patch isn't applyed cleanly anymore.
Fabien COELHO wrote:
But now the documentation is back to its original state of silence on
what base or how many bases might be allowed. Could it just say
"or an unsigned decimal integer value"? Then no one will wonder.
Done in the attached.
Thanks for t
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> > > Fix CommandCounterIncrement in partition-related DDL
> >
> > Hmm, Prion seems unhappy about this. Looking
>
> Here's a patch that seems to fix the problem, and generally looks sane
> to me.
Pushed, after editing a cou
I finally managed to perform this test on sparc v9 machine which is 64
bit big-endian architecture. I run pgbench script (see previous message)
with default_seed=123 on both x86-64 and sparc machines and visualized
the results. You can find them in the attached chart. Both images showed
the same d
On 03/21/2018 02:18 PM, Jaime Soler wrote:
> Hi,
>
> We still get out of memory error during pg_dump execution
> ...
> pg_dump: reading row security enabled for table "public.lo_table"
> pg_dump: reading policies for table "public.lo_table"
> pg_dump: reading publications
> pg_dump: reading public
On 3/6/18 4:12 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 3/4/18 16:09, Andrew Dunstan wrote:
>>> If you want to do this soon I can put out a Buildfarm Client release
>>> fairly quickly.
>
>> I think the dependency is mostly the other way around. How quickly
>> would build farm owners
Hi Amit,
On 3/6/18 9:44 AM, David Steele wrote:
> On 3/2/18 2:27 AM, Amit Langote wrote:
>> On 2018/03/02 15:58, Andres Freund wrote:
>>> On 2018-02-02 17:00:24 -0500, Tom Lane wrote:
Peter Eisentraut writes:
> There might be other options, but one way to solve this would be to
> tre
Hi Victor,
On 3/5/18 7:52 AM, Aleksander Alekseev wrote:
> It seems that this patch doesn't apply anymore, see
> http://commitfest.cputube.org/
>
> The new status of this patch is: Waiting on Author
This patch needs a rebase and should address the comments from
Aleksander and Andres. We are no
> Yeah, that's there. We need both operators to be strict, I think;
> otherwise we can't really assume anything about what they'd return
> for NULL inputs. But if they are, we have NULL => NULL which is
> valid for all proof cases.
I understand. I don’t see any problems in this case.
No, not strictly. The "CASE WHEN" is an if *within* an expression:Okay, I see.
Patch seems usefull and commitable except comments in conditional.[ch]. I'd like
to top/header comment in each file more detailed and descriptive. As for now it
mentions only psql usage without explaining how it is
David Steele wrote:
> > Sorry about the confusing comment. It could be sometime later half of
> > the next week.
>
> We are now three weeks into the CF with no new patch.
>
> Are you planning to update this patch? If not, I think it should be
> marked as Returned with Feedback and submitted to
On Wed, Mar 21, 2018 at 8:01 AM, Jeevan Chalke
wrote:
>> In the patch as proposed, create_partial_grouping_paths() can get
>> called even if GROUPING_CAN_PARTIAL_AGG is not set. I think that's
>> wrong.
>
> I don't think so. For parallel case, we do check that. And for partitionwise
> aggregation
Hi Amit,
On 3/2/18 11:17 AM, Amit Langote wrote:
>
> On Fri, Mar 2, 2018 at 11:53 PM, David Steele wrote:
>> Hi Amit,
>>
>> On 2/16/18 3:36 AM, Amit Langote wrote:
>>>
>>> Attached updated version.
>>
>> This patch no longer applies and the conflicts do not appear to be trivial.
>>
>> I'm a bit
Emre Hasegeli writes:
> I am not sure if we are covering the case when clause_const and
> pred_const are both NULL. In this case, we should be able to return
> true only by checking op_strict(pred_op) or maybe even without
> checking that. Am I mistaken?
Yeah, that's there. We need both operat
On 3/21/18 03:40, Michael Paquier wrote:
>>> Moreover, I wonder whether we shouldn't remove the branch where
>>> conn->connhost is NULL. When would that be the case? The current
>>> behavior is to sometimes return the actual host connected to, and
>>> sometimes the host list. That doesn't make s
On 3/21/18 03:08, Craig Ringer wrote:
> Why was relrewrite / Anum_pg_class_relrewrite inserted at position 28,
> not appended to pg_class?
>
> I don't see how it'd cause any harm, I'm just curious about the rationale.
Adding it at the end would not be appropriate, since those are
variable-length
Hi,
We still get out of memory error during pg_dump execution
bin$ ./initdb -D /tmp/test
The files belonging to this database system will be owned by user "jsoler".
This user must also own the server process.
The database cluster will be initialized with locale "es_ES.UTF-8".
The default databas
Michael Banck wrote:
> Hi,
>
> Am Mittwoch, den 21.03.2018, 09:54 -0300 schrieb Alvaro Herrera:
> > Michael Banck wrote:
> > > I apparently managed to screw up so badly that no PQerrorMessage was
> > > set, so saw the above (which indeed has no error message after the
> > > colon).
> >
> > Well,
Hi,
per suggestion from my colleague Christoph Berg, it seems to make sense
to allow setting the (permanent) replication slot in recovery.conf even
if we don't stream WAL, i.e. allow
pg_basebackup -D foo -R --slot=foo -C -X none
Currently you get an error message "replication slots can only be u
Hi,
Am Mittwoch, den 21.03.2018, 09:54 -0300 schrieb Alvaro Herrera:
> Michael Banck wrote:
> > I apparently managed to screw up so badly that no PQerrorMessage was
> > set, so saw the above (which indeed has no error message after the
> > colon).
>
> Well, maybe that's a different bug, then: may
Alvaro Herrera wrote:
> Hi
>
> Michael Banck wrote:
>
> > I apparently managed to screw up so badly that no PQerrorMessage was
> > set, so saw the above (which indeed has no error message after the
> > colon).
>
> Well, maybe that's a different bug, then: maybe we should print
> something other
Hi
Michael Banck wrote:
> I apparently managed to screw up so badly that no PQerrorMessage was
> set, so saw the above (which indeed has no error message after the
> colon).
Well, maybe that's a different bug, then: maybe we should print
something other than PQerrorMessage (or maybe PQerrorMessa
Hi,
Am Mittwoch, den 21.03.2018, 09:46 -0300 schrieb Alvaro Herrera:
> Daniel Gustafsson wrote:
> > > On 21 Mar 2018, at 13:12, Michael Banck wrote:
> > > while working on something else, I noticed that some error messages in
> > > pg_basebackup do not have a "\n" at the end, resulting in output
Daniel Gustafsson wrote:
> > On 21 Mar 2018, at 13:12, Michael Banck wrote:
>
> > while working on something else, I noticed that some error messages in
> > pg_basebackup do not have a "\n" at the end, resulting in output like:
> >
> > |pg_basebackup: could not get COPY data stream: pg_basebacku
Thank you, pushed
David Steele wrote:
On 3/6/18 7:04 AM, Teodor Sigaev wrote:
I agree with Teodor (upthread, not quoted here) that the documentation
could use some editing.
I started to do it myself, but quickly realized I have no knowledge of
the content. I'm afraid I would destroy the meani
On Tue, Mar 6, 2018 at 7:59 PM, David Steele wrote:
> On 3/6/18 7:04 AM, Teodor Sigaev wrote:
> >> I agree with Teodor (upthread, not quoted here) that the documentation
> >> could use some editing.
> >>
> >> I started to do it myself, but quickly realized I have no knowledge of
> >> the content.
> On 21 Mar 2018, at 13:12, Michael Banck wrote:
> while working on something else, I noticed that some error messages in
> pg_basebackup do not have a "\n" at the end, resulting in output like:
>
> |pg_basebackup: could not get COPY data stream: pg_basebackup: removing
> |data directory “data2"
Hi,
while working on something else, I noticed that some error messages in
pg_basebackup do not have a "\n" at the end, resulting in output like:
|pg_basebackup: could not get COPY data stream: pg_basebackup: removing
|data directory "data2"
Patch attached.
Michael
--
Michael Banck
Projektle
On Wed, Mar 21, 2018 at 2:04 AM, Robert Haas wrote:
> On Tue, Mar 20, 2018 at 10:46 AM, Jeevan Chalke
> wrote:
> > I have added all these three patches in the attached patch-set and
> rebased
> > my changes over it.
> >
> > However, I have not yet made this patch-set dependednt on UPPERREL_TLIST
On 3/21/18 01:51, Tom Lane wrote:
> Andres Freund writes:
>> On March 20, 2018 8:24:41 PM PDT, Michael Paquier
>> wrote:
>>> Yeah, I agree with that. Just not using stdbool.h in those cases ought
>>> to be fine. Any platforms where sizeof(bool) is 4 involves macos older
>>> than 10.5 and Windo
Hi!
On Wed, Mar 21, 2018 at 2:30 PM, Darafei "Komяpa" Praliaskouski <
m...@komzpa.net> wrote:
> on a PostGIS system tuned for preferring parallelism heavily (
> min_parallel_table_scan_size=10kB) we experience issues with QGIS table
> discovery query with this patch:
>
> Failing query is:
> [loca
Hi,
on a PostGIS system tuned for preferring parallelism heavily (
min_parallel_table_scan_size=10kB) we experience issues with QGIS table
discovery query with this patch:
Failing query is:
[local] gis@gis=# SELECT
l.f_table_name,l.f_table_schema,l.f_geometry_column,upper(l.type),l.srid,l.coord_d
> After further thought, it seems like the place to deal with this is
> really operator_predicate_proof(), as in the attached draft patch
> against HEAD. This passes the smell test for me, in the sense that
> it's an arguably correct and general extension of the proof rules,
> but it could use mor
1 - 100 of 109 matches
Mail list logo
