Hi,
As of now partition_join.sql is not having test cases covering cases
where partition table have default partition, attaching a small test
case patch to cover those.
Here is a link of previous discussion :
https://www.postgresql.org/message-id/CAKcux6%3DLO-
On 6 June 2018 at 03:07, David Rowley wrote:
> Please see the attached patch. I've only just finished with it and
> it's not fully done yet as there's still an XXX comment where I've not
> quite thought about Exprs with Vars from higher levels. These might
> always be converted to Params, so the
Andres Freund writes:
> In my understanding FunctionCallInfoData is basically per-call data,
> whereas FmgrInfo is information about the function. It makes some sense
> that ->context is in FunctionCallInfoData, after all it's used for
> per-row data like the trigger context. But we don't
On Wed, Jun 06, 2018 at 09:58:34AM +0530, Amit Kapila wrote:
> On Wed, Jun 6, 2018 at 8:28 AM, Michael Paquier wrote:
>> Ouch. Including directly c.h as you do here is against project policy
>> code. See recent commit a72f0365 for example. pgwin32_open() is
>> visibly able to handle frontend
On Wed, Jun 6, 2018 at 8:28 AM, Michael Paquier wrote:
> On Tue, Jun 05, 2018 at 04:15:00PM +0200, Laurenz Albe wrote:
>
> > --- a/src/bin/pg_test_fsync/pg_test_fsync.c
> > +++ b/src/bin/pg_test_fsync/pg_test_fsync.c
> > @@ -3,6 +3,8 @@
> > * tests all supported fsync() methods
> >
On Wed, Jun 6, 2018 at 8:11 AM, Thomas Munro
wrote:
> On Mon, Mar 5, 2018 at 8:13 PM, Rajkumar Raghuwanshi
> wrote:
>> On Wed, Feb 7, 2018 at 2:00 PM, Ashutosh Bapat
>> Changed partition-wise statement to partitionwise.
>> Attached re-based patch.
>>
>>> The patch looks good to me. I don't think
On Tue, Jun 5, 2018 at 10:04 PM, MauMau wrote:
> From: Ashutosh Bapat
>> In order to normalize parse trees, we need to at
>> least replace various OIDs in parse-tree with something that the
>> foreign server will understand correctly like table name on the
>> foreign table pointed to by local
On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan
wrote:
> At my talk at pgcon last Friday [1] I presented some ideas for how people
> could run a full buildfarm run against their code, including a 4 line recipe
> using some Docker recipes I had created. Thomas Munro suggested it would be
> even
On Wed, Jun 06, 2018 at 01:14:04AM +0900, MauMau wrote:
> I don't think an immediate server like the coordinators in XL is
> necessary. That extra hop can be eliminated by putting both the
> coordinator and the data node roles in the same server process. That
> is, the node to which an
On Tue, Jun 5, 2018 at 7:49 PM, Ashutosh Sharma
wrote:
> Hi,
>
> I am not able to reproduce this issue on HEAD. Seems like the
> following git-commit fixes it,
>
> commit 01deec5f8ae64b5120cc8c93d54fe0e19e477b02
> Author: Andrew Dunstan
> Date: Mon May 28 16:44:13 2018 -0400
>
> Return a
On Tue, Jun 05, 2018 at 04:15:00PM +0200, Laurenz Albe wrote:
> The attached patch makes pg_test_fsync use pgwin32_open on Windows, which is
> what
> we use elsewhere.
Well, pg_upgrade may benefit from that as one example, as any other
tools.
> That should fix the problem.
> Ist there a better
On Mon, Mar 5, 2018 at 8:13 PM, Rajkumar Raghuwanshi
wrote:
> On Wed, Feb 7, 2018 at 2:00 PM, Ashutosh Bapat
> Changed partition-wise statement to partitionwise.
> Attached re-based patch.
>
>> The patch looks good to me. I don't think we can reduce it further.
>> But we need some tests to test
On Tue, Jun 05, 2018 at 01:00:30PM +0200, Petr Jelinek wrote:
> I didn't say anything about CreateDecodingContext though. I am talking
> about the fact that we then use the same variable as input to
> XLogReadRecord later in the logical slot code path. The whole point of
> having restart_lsn for
On 5 June 2018 at 17:34, Ozz Nixon wrote:
> Sorry...
>
> > 1) CoC might result in developers leaving projects
>
>
> I know this on going regurgitation is going to cause my team to
> leave the project, right around 100 posts on this off topic topic it
> was bad enough when the
Hello Hackers!
My name is Kefan Yang, and I am working on my Google Summer of Code 2018
project. For the first evaluation, I should be able to hand in:
1. the benchmark implementations of introsort, timsort, dual-pivot quicksort
and radixsort.
2. Phase 1(random array) and 2(worst case) of the
On Wed, Jun 6, 2018 at 2:06 AM, Konstantin Knizhnik
wrote:
> Thank you for review. Updated version of the patch fixing all reported
> problems is attached.
Small problem on Windows[1]:
C:\projects\postgresql\src\include\common/zpq_stream.h(17): error
C2143: syntax error : missing ')' before
On Tue, Jun 05, 2018 at 11:20:57AM -0400, Peter Eisentraut wrote:
> On 6/5/18 09:12, Andres Freund wrote:
>> I'd rather create a new 2018-07, and just manually move old patches to
>> it.
>
> My concern is whether the commitfest app will handle that well. There
> is no "move to previous commit
On Wed, Jun 6, 2018 at 12:29 AM, Michael Paquier
wrote:
> On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote:
> > Let's keep the tech side of this simple and just do the rename as
> > suggested and then we can encourage committers to review the
> > smaller/older patches by providing
On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote:
> Let's keep the tech side of this simple and just do the rename as
> suggested and then we can encourage committers to review the
> smaller/older patches by providing information about the objective size
> and age of them, which will
> On Jun 5, 2018, at 15:20, Peter Geoghegan wrote:
> I don't follow. Practically any organized group has rules around
> conduct, with varying degrees of formality, means of enforcement, etc.
I believe the objection is to setting up a separate CoC committee, rather than
using the core team as
On Tue, Jun 5, 2018 at 2:06 PM, Sven R. Kunze wrote:
> 1) CoC might result in developers leaving projects
> http://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html
This guy left LLVM for several reasons. The pertinent reason for us
was that he had to agree to a code of conduct in order to
Teodor Sigaev wrote:
Ah, I think this is the missing, essential component:
CREATE INDEX ON t(right(i::text,1)) WHERE i::text LIKE '%1';
Finally, I reproduce it with attached script.
In attachment simplified version of script. psql uses ordinary sql query
to get info about index with usual
Sorry...
> 1) CoC might result in developers leaving projects
I know this on going regurgitation is going to cause my team to leave
the project, right around 100 posts on this off topic topic it was bad
enough when the original idea came up (2 years ago I think). It used to be
> "Matthew" == Matthew Woodcraft writes:
Matthew> A few days ago there was a suggestion on this list to add a
Matthew> .editorconfig file specifying tab width:
Matthew>
https://www.postgresql.org/message-id/87efhuz9be.fsf%40news-spur.riddles.org.uk
Matthew> The .editorconfig format
> "Peter" == Peter Eisentraut writes:
>> + (lambda () (add-to-list 'write-file-functions
>> 'delete-trailing-whitespace)
Peter> dir-locals doesn't work this way. It's not a general lisp file.
Right. The correct approach is
+ (eval add-hook
On June 5, 2018 9:47 PM, Paul A Jungwirth p...@illuminatedcomputing.com wrote:
> On Sat, May 26, 2018 at 1:56 PM, Vik Fearing vik.fear...@protonmail.com wrote:
>
>> SQL:2011 introduced the concept of a "period". It takes two existing columns
>> and basically does the same thing as our range types
On 2018-06-05 18:22, David Fetter wrote:
> Folks,
>
> Here's my attempt to $subject. I've tested with vim, but I'm much less
> certain I got the EMACS code right.
>
> Is there any interest in such a feature?
A few days ago there was a suggestion on this list to add a
.editorconfig file
On 06/05/2018 05:14 PM, Daniel Gustafsson wrote:
This comment should say “perlcheck/..” and not “pgperlcritic/.." I assume:
Thanks. will fix.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On 5 Jun 2018, at 16:31, Andrew Dunstan
> wrote:
> The patch contains a simple script to run the checks. The code that finds
> perl files is put in a function in a single file that is sourced by the three
> locations that need it.
+1 on centralizing the find-files function.
> The
On 06/05/2018 04:57 PM, Andres Freund wrote:
> But we don't really change the
> collation of function invocations per-call.
Is that true? (Not a rhetorical question; I'm unsure.)
Is your argument that the expression's collation is determined once
for each call /site/, and thereafter doesn't
Hi PostgreSQL Community,
some points I like to make mainly because of observations of how other
open source projects handle this topic:
1) CoC might result in developers leaving projects
http://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html
2) CoC might result in not so equal peers
Hi,
In my understanding FunctionCallInfoData is basically per-call data,
whereas FmgrInfo is information about the function. It makes some sense
that ->context is in FunctionCallInfoData, after all it's used for
per-row data like the trigger context. But we don't really change the
collation of
On Mon, Jun 4, 2018 at 9:46 AM, Fujii Masao wrote:
> Generally the recovery performance of DROP DATABASE is not critical
> for many users. But unfortunately my colleague's project might need to
> sometimes drop the database using multiple tablespaces, for some reasons.
> So, if the fix is not so
On 6/5/18 13:37, Tom Lane wrote:
> I note that Peter E. seems to have a recipe for finding such issues,
> which I suspect is grounded in some obscure git feature or other.
> That might be easier to work with, since you'd only need one fix
> not one per editor.
I have a git alias:
On 6/5/18 13:22, David Fetter wrote:
> diff --git a/.dir-locals.el b/.dir-locals.el
> index 9525d6b604..858461e6bd 100644
> --- a/.dir-locals.el
> +++ b/.dir-locals.el
> @@ -4,7 +4,8 @@
> (c-file-style . "bsd")
> (fill-column . 78)
> (indent-tabs-mode . t)
>
On 5 June 2018 at 13:06, Peter Eisentraut
wrote:
> On 6/5/18 03:09, Michael Paquier wrote:
> > I just had a quick look at this patch, lured by the smell of your latest
> > messages... And it seems to me that this patch needs a heavy amount of
> > work as presented. There are a couple of things
On Tue, Jun 5, 2018 at 12:47 PM, Paul A Jungwirth
wrote:
> Also, this may not be very helpful, but I started an extension to
> support temporal foreign keys here:
>
> https://github.com/pjungwir/time_for_keys
>
> It uses intervals, not periods, but maybe you can steal some ideas.
Sorry for two
Hi,
On 2018-06-05 15:08:33 -0400, Peter Eisentraut wrote:
> On 6/5/18 13:29, Andres Freund wrote:
> > Besides the change here, I think we should also go much further with the
> > conversion to NullableDatum. There's two main areas of change: I want
> > to move the execExpr.c related code so
On Fri, May 11, 2018 at 4:48 AM, Paul A Jungwirth
wrote:
> I'm traveling and can't write much more at the moment, but I'll try to
> reply more fully in a week or two.
Sorry it took awhile to continue this discussion! If people are
interested in implementing temporal features in Postgres, I wrote
On 6/5/18 13:29, Andres Freund wrote:
> Besides the change here, I think we should also go much further with the
> conversion to NullableDatum. There's two main areas of change: I want
> to move the execExpr.c related code so steps return data into
> NullableDatums - that removes a good chunk of
Thomas Munro writes:
> On Sat, May 26, 2018 at 6:58 AM, Robbie Harwood wrote:
>> Me and the bot are having an argument. This should green Linux but I
>> dunno about Windows.
>
> BTW if you're looking for a way to try stuff out on Windows exactly
> the way cfbot does it without posting a new
I use FileStly plugin to vim [1]. But I slightly modify it, see in attachment.
FileStyle, sorry.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
I once tried to have vim highlight trailing whitespace, spaces before
tabs, and overlength lines (>80 chars), and while I could do each thing
in isolation, I wasn't able to get it to highlight the three of them at
the same time. If you have a recipe for that, I welcome it.
I use FileStly
Thanks for the patch. This (missing) optimization popped-up repeatedly recently,
and I was planning to look into it for PG12. So now I don't have to, because
you've done all the hard work ;-)
You are welcome. Actually one of out customers faced the problem with GROUP BY
column order and
Greetings,
* Magnus Hagander (mag...@hagander.net) wrote:
> On Tue, Jun 5, 2018 at 4:45 PM, Chris Travers
> wrote:
> > If I may suggest: The committee should be international as well and
> > include people from around the world. The last thing we want is for it to
> > be dominated by people
From: Simon Riggs
On 1 June 2018 at 16:56, Ashutosh Bapat
wrote:
>> I think partitioning + FDW provide basic infrastructure for
>> distributing data, planning queries working with such data. We need
>> more glue to support node management, cluster configuration. So, I
>> agree with your
Hi,
On 2018-06-05 10:47:49 -0700, Jeff Davis wrote:
> The thing I don't like about it is that it requires running two memory-
> hungry operations at once. How much of work_mem do we use for sorted
> runs, and how much do we use for the hash table?
Is that necessarily true? I'd assume that we'd
On Tue, Jun 05, 2018 at 01:28:54PM -0400, Alvaro Herrera wrote:
> On 2018-Jun-05, David Fetter wrote:
> Hi David
>
> > Here's my attempt to $subject. I've tested with vim, but I'm much less
> > certain I got the EMACS code right.
> >
> > Is there any interest in such a feature?
>
> I'd rather
On Tue, 2018-06-05 at 05:42 -0700, Andres Freund wrote:
> That's an interesting idea, but it seems simpler to stick to
> > hashing
> > rather than using a combination strategy. It also seems like it
> > would
> > take less CPU effort.
> Isn't the locality of access going to considerably better
Hi,
On 2018-06-05 10:40:22 -0700, se...@rielau.com wrote:
> Big +1 on this one.
Cool.
> Here is what we did. It's very crude, but minimized the amount of pain:
I think I'd rather go for my approach in core though. Needlessly
carrying around a bunch of pointers, and adding the necessary
Big +1 on this one.
Here is what we did. It's very crude, but minimized the amount of pain:
It helps that the C compiler treats arrays and pointers the same.
I can dig for the complete patch if you want...
Cheers
Serge
/*
* This struct is the data actually passed to an fmgr-called
Alvaro Herrera writes:
> On 2018-Jun-05, David Fetter wrote:
>> Is there any interest in such a feature?
> I'd rather have the editor warn me (highlight) such things rather than
> fix them silently (I wonder if it'd cause a mess with regression .out
> files for example, which I do edit on
> On Jun 5, 2018, at 10:14 AM, Tom Lane wrote:
>
> Michael Paquier writes:
>> Okay. If we tend toward this direction, I propose to do this switch in
>> two days my time (Thursday afternoon in Tokyo) if there are no
>> objections, so as anybody has hopefully time to argue back.
>
> I think
Hi,
While prototyping codegen improvements for JITed expression evaluation,
I once more hit the issue that the FunctionCallInfoData structs are
really large (936 bytes), despite arguments beyond the fourth barely
every being used. I think we should fix that.
What I think we should do is convert
On Tue, 2018-06-05 at 08:39 -0700, se...@rielau.com wrote:
> Strange. We don't see this overeahd and measure a lot more than just
> a single metric:
Let's investigate again. I wasn't able to repro the overhead on x86;
Robert saw it on a POWER machine, and it was somewhat noisy. I don't
think we
On 2018-Jun-05, David Fetter wrote:
Hi David
> Here's my attempt to $subject. I've tested with vim, but I'm much less
> certain I got the EMACS code right.
>
> Is there any interest in such a feature?
I'd rather have the editor warn me (highlight) such things rather than
fix them silently (I
David Fetter writes:
> On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
>> True. Although not all built in aggregates have those defined.
> Just out of curiosity, which ones don't? As of
> 3f85c62d9e825eedd1315d249ef1ad793ca78ed4, pg_aggregate has both of
> those as NOT NULL.
NOT
Folks,
Here's my attempt to $subject. I've tested with vim, but I'm much less
certain I got the EMACS code right.
Is there any interest in such a feature?
Best,
David.
---
.dir-locals.el| 3 ++-
src/tools/editors/vim.samples | 1 +
2 files changed, 3 insertions(+), 1
On 2018-06-05 19:04:11 +0200, David Fetter wrote:
> On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> > On 5 June 2018 at 06:52, Andres Freund wrote:
> > > That part has gotten a bit easier since, because we have serialize
> > > / deserialize operations for aggregates these days.
>
From: Merlin Moncure
> FWIW, Distributed analytical queries is the right market to be in.
> This is the field in which I work, and this is where the action is
at.
> I am very, very, sure about this. My view is that many of the
> existing solutions to this problem (in particular hadoop class
>
On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> On 5 June 2018 at 06:52, Andres Freund wrote:
> > That part has gotten a bit easier since, because we have serialize
> > / deserialize operations for aggregates these days.
>
> True. Although not all built in aggregates have those
On 2018-Jun-05, Amit Langote wrote:
> On 2018/06/05 16:41, Ashutosh Bapat wrote:
> > On Tue, Jun 5, 2018 at 1:07 PM, Amit Langote
> > wrote:
> >> On 2018/06/05 1:25, Alvaro Herrera wrote:
> >>> In the meantime, my inclination is to fix the documentation to point out
> >>> that AFTER triggers are
On 6/5/18 03:09, Michael Paquier wrote:
> I just had a quick look at this patch, lured by the smell of your latest
> messages... And it seems to me that this patch needs a heavy amount of
> work as presented. There are a couple of things which are not really
> nice, like forcing the presentation
From: Ashutosh Bapat
> Each node need to be confiugred and maintained. That requires
efforts.
> So we need to keep the number of nodes to a minimum. With a
> coordinator and worker node segregation, we require at least two
nodes
> in a cluster and just that configuration doesn't provide much
>
From: Ashutosh Bapat
> In order to normalize parse trees, we need to at
> least replace various OIDs in parse-tree with something that the
> foreign server will understand correctly like table name on the
> foreign table pointed to by local foreign table OR (schema
qualified)
> function names and
From: Ashutosh Bapat
> In order to normalize parse trees, we need to at
> least replace various OIDs in parse-tree with something that the
> foreign server will understand correctly like table name on the
> foreign table pointed to by local foreign table OR (schema
qualified)
> function names and
> Those underscore-prefixed names are defined in Microsoft's
> [3][4]. So now I'm wondering if win32_port.h needs to
> #include if (_MSC_VER < 1800).
I don't have the C experience to decide the correct way. There are
currently many .c files that are including float.h conditionally or
On 06/05/2018 12:09 PM, Andrew Dunstan wrote:
notice at lines 36 and 34 or the Appveyor output, (from lines 16 and
19 of the recipe appveyor.yml) that this recipe does make a couple of
adjustments.
Of course that's lines 36 and 43. I seem to be getting more dyslectic as
I get older ...
From: Robert Haas
On Thu, May 31, 2018 at 8:12 AM, MauMau wrote:
>> Oh, I didn't know you support FDW approach mainly for analytics. I
>> guessed the first target was OLTP read-write scalability.
>
> That seems like a harder target to me, because you will have an
extra
> hop involved -- SQL from
At my talk at pgcon last Friday [1] I presented some ideas for how
people could run a full buildfarm run against their code, including a 4
line recipe using some Docker recipes I had created. Thomas Munro
suggested it would be even nicer if you could just point something like
Appveypr at the
On Tue, Jun 5, 2018 at 4:45 PM, Chris Travers
wrote:
>
>
> On Mon, Jun 4, 2018 at 6:59 PM, Joshua D. Drake
> wrote:
>
>> On 06/03/2018 04:08 PM, Gavin Flower wrote:
>>
>> My comments:
1) Reiterate my contention that this is a solution is search of
problem. Still it looks like it
On 05.06.2018 10:09, Michael Paquier wrote:
On Tue, Jun 05, 2018 at 06:04:21PM +1200, Thomas Munro wrote:
On Thu, May 17, 2018 at 3:54 AM, Konstantin Knizhnik
Speaking of configuration, are you planning to support multiple
compression libraries at the same time? It looks like the current
On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
> On 5 June 2018 at 06:52, Andres Freund wrote:
> > That part has gotten a bit easier since, because we have serialize /
> > deserialize operations for aggregates these days.
>
> True. Although not all built in aggregates have those
2018-06-05 17:07 GMT+02:00 David Rowley :
> On 5 June 2018 at 22:31, Amit Langote
> wrote:
> > Maybe, David (added to cc) has something to say about all this,
> especially
> > whether he considers this a feature and not a bug fix.
>
> Thanks, Amit. I had missed this thread.
>
> Yeah. I admit if
On 06/05/2018 07:45 AM, Chris Travers wrote:
It is my hope that PostgreSQL.Org -Core chooses members for that
committee that are exceedingly diverse otherwise it is just an echo
chamber for a single ideology and that will destroy this community.
If I may suggest: The committee
Right now, when a TAP test reports a failure, it looks something like this:
# Failed test 'creating a replication slot'
# at
/../postgresql/src/bin/pg_basebackup/../../../src/test/perl/TestLib.pm
line 371.
That file location is where we call out to the test function provided by
On 6 June 2018 at 03:17, Andres Freund wrote:
> On 2018-06-06 03:14:58 +1200, David Rowley wrote:
>> On 6 June 2018 at 02:20, Tom Lane wrote:
>> > I thought the idea was to clear out the underbrush of small, ready-to-go
>> > patches. How old they are doesn't enter into that.
>>
>> I don't
On 6/5/18 09:12, Andres Freund wrote:
> I'd rather create a new 2018-07, and just manually move old patches to
> it.
My concern is whether the commitfest app will handle that well. There
is no "move to previous commit fest" button. So you'd have to do it in
some evil way, possibly confusing the
On 2018-06-06 03:14:58 +1200, David Rowley wrote:
> On 6 June 2018 at 02:20, Tom Lane wrote:
> > I thought the idea was to clear out the underbrush of small, ready-to-go
> > patches. How old they are doesn't enter into that.
>
> I don't recall a 'fest where small ready to go patches getting
>
On 6 June 2018 at 02:20, Tom Lane wrote:
> I thought the idea was to clear out the underbrush of small, ready-to-go
> patches. How old they are doesn't enter into that.
I don't recall a 'fest where small ready to go patches getting
anything but priority.
--
David Rowley
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway writes:
> > On 06/05/2018 10:43 AM, Andres Freund wrote:
> >> I think we've not fully agreed on that. I'd argue we should manually
> >> filter things into the next CF. And both small patches and older things
> >> should qualify.
>
On 06/05/2018 10:43 AM, Andres Freund wrote:
On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
Andres Freund writes:
I'd rather create a new 2018-07, and just manually move old patches to
it. Otherwise we'll not really focus on the glut of old things, but
everyone just restarts working on
El 2018-06-05 10:54, gilberto.casti...@etecsa.cu escribió:
Hello,
Maybe must include policy of money support from several at member from
country less earnings.
El 2018-06-05 10:45, Chris Travers escribió:
On Mon, Jun 4, 2018 at 6:59 PM, Joshua D. Drake
wrote:
On 06/03/2018 04:08 PM, Gavin
Joe Conway writes:
> On 06/05/2018 10:43 AM, Andres Freund wrote:
>> I think we've not fully agreed on that. I'd argue we should manually
>> filter things into the next CF. And both small patches and older things
>> should qualify.
> Would it work to rename 2018-09 to 2018-07 and then make a
On 06/05/2018 10:43 AM, Andres Freund wrote:
> On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> I'd rather create a new 2018-07, and just manually move old patches to
>>> it. Otherwise we'll not really focus on the glut of old things, but
>>> everyone just restarts
On Mon, Jun 4, 2018 at 6:59 PM, Joshua D. Drake
wrote:
> On 06/03/2018 04:08 PM, Gavin Flower wrote:
>
> My comments:
>>>
>>> 1) Reiterate my contention that this is a solution is search of problem.
>>> Still it looks like it is going forward, so see below.
>>>
>>> 2) "... engaging in behavior
On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'd rather create a new 2018-07, and just manually move old patches to
> > it. Otherwise we'll not really focus on the glut of old things, but
> > everyone just restarts working on their own new thing.
>
> I thought the
Attached is a rebased patch version. Also included it in the upcoming
commitfest :
https://commitfest.postgresql.org/18/1660/
In the rebased version, the new test cases are added in the existing
isolation/specs/partition-key-update-1.spec test.
--
Thanks,
-Amit Khandekar
EnterpriseDB
Here is a follow up patch to last weeks commit allowing all perl files
to be checked clean for compile time errors and warnings.
The patch contains a simple script to run the checks. The code that
finds perl files is put in a function in a single file that is sourced
by the three locations
On Sun, Jun 03, 2018 at 10:39:22PM -0500, Justin Pryzby wrote:
> Find attached an update which also supports column completion using the legacy
> non-parenthesized syntax.
Thank you!
> BTW..should that be toast.tuple_target ??
I think shouldn't. From the documentation "This parameter cannot be
Andres Freund writes:
> I'd rather create a new 2018-07, and just manually move old patches to
> it. Otherwise we'll not really focus on the glut of old things, but
> everyone just restarts working on their own new thing.
I thought the idea was to clear out the underbrush of small, ready-to-go
Amit Kapila wrote:
> On Fri, Jun 1, 2018 at 8:18 PM, Laurenz Albe wrote:
> > Amit Kapila wrote:
> > > On Fri, Jun 1, 2018 at 3:13 PM, Laurenz Albe
> > > wrote:
> > > > I recently read our documentation about reliability on Windows:
> > > >
> > > > > On Windows, if wal_sync_method is
Michael Paquier writes:
> Okay. If we tend toward this direction, I propose to do this switch in
> two days my time (Thursday afternoon in Tokyo) if there are no
> objections, so as anybody has hopefully time to argue back.
I think we probably have to wait longer. It's not clear to me when the
On 05.06.2018 09:04, Thomas Munro wrote:
On Thu, May 17, 2018 at 3:54 AM, Konstantin Knizhnik
wrote:
Concerning specification of compression level: I have made many experiments
with different data sets and both zlib/zstd and in both cases using
compression level higher than default doesn't
On 05.06.2018 08:26, Thomas Munro wrote:
On Thu, May 17, 2018 at 3:54 AM, Konstantin Knizhnik
wrote:
Thank you for this notice.
Updated and rebased patch is attached.
Hi Konstantin,
Seems very useful. +1.
+ rc = inflate(>rx, Z_SYNC_FLUSH);
+ if (rc != Z_OK)
+ {
+ return
On 06/05/2018 03:41 PM, se...@rielau.com wrote:
In our code base we have added a WithStats-Flavor for creating memory
contexts.
This api accepts a pointer to metric for accounting and it is inherited
by all subcontexts unless overridden.
So we only needed to change context creation API where we
In our code base we have added a WithStats-Flavor for creating memory contexts.
This api accepts a pointer to metric for accounting and it is inherited by all
subcontexts unless overridden.
So we only needed to change context creation API where we wanted (such as
TopTansactionContext, Message
On Tue, Jun 5, 2018 at 6:24 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 5 June 2018 at 12:31, Amit Langote wrote:
>>
>> doesn't look quite right. What says expr is really a Param? The patch
>> appears to work because, by setting pinfo->execparams to *something*, it
>> triggers
Hi,
On my win-7, I am facing $SUBJECT. I am consistently getting below error:
Copying build output files...Could not copy postgres.exe
at install.pl line 26.
On digging, I found that it started failing with commit 3a7cc727 (Don't
fall off the end of perl functions). It seems that we have
On 06/05/2018 03:17 PM, David Rowley wrote:
On 6 June 2018 at 01:09, Andres Freund wrote:
On 2018-06-06 01:06:39 +1200, David Rowley wrote:
My concern is that only accounting memory for the group and not the
state is only solving half the problem. It might be fine for
aggregates that don't
1 - 100 of 133 matches
Mail list logo
