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 warnings:
gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclarati
On 16 March 2018 at 10:54, Craig Ringer wrote:
> On 16 March 2018 at 08:51, Peter Eisentraut com> wrote:
>
>> On 2/28/18 13:52, Peter Eisentraut wrote:> Second version, which uses an
>> OID. I added another field to the output> plugin options (next to the
>> output_type), to indicate whether th
On 21.03.2018 04:50, Peter Eisentraut wrote:
On 3/16/18 12:08, Konstantin Knizhnik wrote:
pq_putmessage_noblock copies data from ctx->out buffer to libpq buffers.
After it we write timestamp to ctx->out buffer.
And comments says that we should do it "as late as possible".
But this timestamp is
2018-03-20 17:31 GMT+01:00 Peter Eisentraut <
peter.eisentr...@2ndquadrant.com>:
> On 3/16/18 06:29, Pavel Stehule wrote:
> > attached patch fixes it
>
> The fix doesn't seem to work for LANGUAGE SQL procedures. For example:
>
> CREATE PROCEDURE ptest5(a int, b int DEFAULT 0)
> LANGUAGE SQL
> AS
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 weird things in the configure output.
Without --enable-debug:
conf
On Wed, Mar 21, 2018 at 10:33:19AM +1100, Haribabu Kommi wrote:
> On Wed, Mar 21, 2018 at 6:06 AM, Peter Eisentraut <
> peter.eisentr...@2ndquadrant.com> wrote:
>
>> On 3/16/18 00:03, Kyotaro HORIGUCHI wrote:
>>> I agree to the conclusion that PQhost() shouldn't return hostaddr
>>> "if it has any
Hi,
Am Dienstag, den 20.03.2018, 19:19 -0400 schrieb Stephen Frost:
> * Christoph Berg (christoph.b...@credativ.de) wrote:
> > Re: Tom Lane 2018-03-20 <12960.1521557...@sss.pgh.pa.us>
> > > It might help if the patch were less enthusiastic about trying to
> > > "optimize" by avoiding extra file op
On Tue, Mar 20, 2018 at 09:30:15PM +0100, Tomas Vondra wrote:
> On 03/20/2018 02:11 PM, Arthur Zakirov wrote:
> > max_shared_dictionaries_size is defined as PGC_SIGHUP now. Added check
> > of a new value to disallow to set zero if there are loaded dictionaries
> > and to decrease maximum allowed si
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 i386 virtual machine and installed Debian 9.4.
Next up, I have
> 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
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
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
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
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
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 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"
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.
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
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
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
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
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,
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
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
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,
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
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
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
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
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
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
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
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
> 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.
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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
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
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/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
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/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 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 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?
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 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 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 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-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 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
>> .
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: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
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: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()
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
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,
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 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
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
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
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: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 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 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 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
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 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
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 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
> 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 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
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 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
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
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
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
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
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 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 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 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 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
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 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
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 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
1 - 100 of 109 matches
Mail list logo
