On 3 February 2018 at 11:46, Tom Lane wrote:
> Chapman Flack writes:
> > ... which led me to the idea of a function parameter
> > declaration, putting the function definer in control of what
> > bits should get redacted.
>
> +1 for thinking outside the box, but ...
>
> > Would anyone else see so
Hi
2018-02-03 1:48 GMT+01:00 David G. Johnston :
> I've done a non-compilation documentation review, the diff from the poc
> patch and the diff from master are attached.
>
> Comments are inter-twined in the patch in xml comment format; though I
> reiterate (some of?) them below.
>
> On Fri, Feb
Chapman Flack writes:
> ... which led me to the idea of a function parameter
> declaration, putting the function definer in control of what
> bits should get redacted.
+1 for thinking outside the box, but ...
> Would anyone else see some value in this capability? Could it
> (or some suitable res
On Fri, Feb 2, 2018 at 4:31 PM, Peter Geoghegan wrote:
> On Fri, Feb 2, 2018 at 1:58 PM, Andres Freund wrote:
>> Not saying you're wrong, but you should include a comment on why this is
>> a benign warning. Presumably it's some padding memory somewhere, but
>> it's not obvious from the above blea
On Mon, Jan 29, 2018 at 1:53 AM, Andres Freund wrote:
>> https://git.postgresql.org/git/users/andresfreund/postgres.git
There's a patch in there to change the scan order. I suggest that you
rename the GUC "synchronize_seqscans" to something more generic like
"optimize_scan_order", and use it to
Tomas Vondra writes:
> BTW wouldn't it be possible to derive "traditional" proof in relational
> algebra, similarly to other transforms?
Perhaps. The patch depends on CTID, but you could probably model that
as a primary key in a proof.
regards, tom lane
On 02/02/2018 03:26 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> ISTM this patch got somewhat stuck as we're not quite sure the
>> transformation is correct in all cases. Is my impression correct?
>
> Yeah, that's the core issue.
>
>> If yes, how to we convince ourselves? Would some sort of a
CREATE FUNCTION commence_primary_ignition(target text, password text)
RETURNS void AS ...;
SELECT commence_primary_ignition(target=>'Alderaan', password=>'1234');
/* 1234 could appear in logs, activity stats ... disturbing */
CREATE OR REPLACE FUNCTION commence_primary_ignition(
target tex
On Fri, Feb 2, 2018 at 1:58 PM, Andres Freund wrote:
> Not saying you're wrong, but you should include a comment on why this is
> a benign warning. Presumably it's some padding memory somewhere, but
> it's not obvious from the above bleat.
Sure. This looks slightly more complicated than first ant
Robert Haas writes:
> Is there some good reason why get_relation_info() copies all of the
> data that will be needed later in planning into the RelOptInfo instead
> of just storing a pointer to the Relation directly into the
> RelOptInfo? Of course, if we did that, then it would have to leave
> t
Please forgive my inexperience with the codebase, but as the guy who
reported this bugger:
https://www.postgresql.org/message-id/flat/151724453314.1238.409882538067070269%40wrigleys.postgresql.org#151724453314.1238.409882538067070...@wrigleys.postgresql.org,
I thought I'd follow your hints, as it's
Robert Haas writes:
> On Fri, Feb 2, 2018 at 4:40 PM, Peter Eisentraut
> wrote:
>> There might be other options, but one way to solve this would be to
>> treat partition bounds as a general expression in the grammar and then
>> check in post-parse analysis that it's a constant.
> Yeah -- isn't t
On Thu, Jan 25, 2018 at 6:21 PM, Thomas Munro
wrote:
> On Fri, Jan 26, 2018 at 9:38 AM, Claudio Freire
> wrote:
>> I had the tests running in a loop all day long, and I cannot reproduce
>> that variance.
>>
>> Can you share your steps to reproduce it, including configure flags?
>
> Here are two
On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila wrote:
> So, this means that in case of logical replication, it won't generate
> the error this patch is trying to introduce. I think if we want to
> handle this we need some changes in WAL and logical decoding as well.
>
> Robert, others, what do you
On Fri, Feb 2, 2018 at 4:40 PM, Peter Eisentraut
wrote:
> There might be other options, but one way to solve this would be to
> treat partition bounds as a general expression in the grammar and then
> check in post-parse analysis that it's a constant.
Yeah -- isn't the usual way of handling this
... are posted at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=bf641d3376018c40860f26167a60febff5bc1f51
They should appear in the website's development docs in a couple of hours,
too.
Please comment before Sunday if you see anything that could be improved.
Peter Eisentraut writes:
> There might be other options, but one way to solve this would be to
> treat partition bounds as a general expression in the grammar and then
> check in post-parse analysis that it's a constant.
That's pretty much what I said upthread. What I basically don't like
about
On 2018-02-02 13:35:59 -0800, Peter Geoghegan wrote:
> On Fri, Feb 2, 2018 at 10:38 AM, Peter Geoghegan wrote:
> > On Fri, Feb 2, 2018 at 10:37 AM, Robert Haas wrote:
> >> If you could keep an eye on the buildfarm and investigate anything
> >> that breaks, I would appreciate it.
>
> > I can keep
On 2/2/18 04:39, Amit Langote wrote:
> Most of the code does treat partition bound values as Node values doing
> coercing before calling the input value good and failing upon not being
> able to convert to the desired type for whatever reason.
>
> create table b (a bool) partition by list (a);
> c
On Fri, Feb 2, 2018 at 10:38 AM, Peter Geoghegan wrote:
> On Fri, Feb 2, 2018 at 10:37 AM, Robert Haas wrote:
>> If you could keep an eye on the buildfarm and investigate anything
>> that breaks, I would appreciate it.
> I can keep an eye on it throughout the day.
There is a benign Valgrind err
Is there some good reason why get_relation_info() copies all of the
data that will be needed later in planning into the RelOptInfo instead
of just storing a pointer to the Relation directly into the
RelOptInfo? Of course, if we did that, then it would have to leave
the relation open instead of clo
On Fri, Feb 2, 2018 at 9:33 AM, Robert Haas wrote:
>> Updated set of patches attached (patches 0002 onward mostly unchanged,
>> except I incorporated the delta patch posted by David upthread).
>
> Committed 0001. Thanks.
Some preliminary thoughts...
Regarding 0002, I can't help noticing that th
Robert Haas writes:
> On Fri, Feb 2, 2018 at 3:01 PM, Tom Lane wrote:
>> Do you mind if I change that Assert to a run-time test?
> Hrm, I guess I could have done something like
> shm_toc_lookup(pcxt->toc, PARALLEL_KEY_ERROR_QUEUE, (pcxt->nworkers ==
> 0)).
OK, that'd work too. I'll make it so.
> On 1 February 2018 at 11:24, Arthur Zakirov wrote:
>
> I fixed those messages, but in a different manner. I think that an
> unexpected character is unknown and neither space nor separator. And
> better to say that was expected space/separator character.
Sounds good, thanks.
> Attached fixed pa
On Fri, Feb 2, 2018 at 3:35 PM, Peter Geoghegan wrote:
> On Fri, Feb 2, 2018 at 12:30 PM, Robert Haas wrote:
>> For the record, I typically construct the list of reviewers by reading
>> over the thread and adding all the people whose names I find there in
>> chronological order, excluding things
On Fri, Feb 2, 2018 at 12:30 PM, Robert Haas wrote:
> For the record, I typically construct the list of reviewers by reading
> over the thread and adding all the people whose names I find there in
> chronological order, excluding things that are clearly not review
> (like "Bumped to next CF.") and
On Fri, Feb 2, 2018 at 3:23 PM, Peter Geoghegan wrote:
> On Fri, Feb 2, 2018 at 10:38 AM, Peter Geoghegan wrote:
>> Thanks everyone
>
> I would like to acknowledge the assistance of Corey Huinker with early
> testing of the patch (this took place in 2016, and much of it was not
> on-list). Even t
On Fri, Feb 2, 2018 at 10:38 AM, Peter Geoghegan wrote:
> Thanks everyone
I would like to acknowledge the assistance of Corey Huinker with early
testing of the patch (this took place in 2016, and much of it was not
on-list). Even though he wasn't credited in the commit message, he
should appear i
Konstantin>I do not have explanation of performance degradation in case of
this
particular workload.
A) Mongo Java Client uses a connection-pool of 100 connections by default.
That is it does not follow "connection per client" (in YCSB terms), but it
is capped by 100 connections. I think it can be
On Fri, Feb 2, 2018 at 3:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> That turned out to produce more than one problem. I find that the
>> select_parallel test then fails like this:
>> ERROR: could not find key 18446744073709486082 in shm TOC at 0x10be98040
>> The fix for that problem seems
Robert Haas writes:
> That turned out to produce more than one problem. I find that the
> select_parallel test then fails like this:
> ERROR: could not find key 18446744073709486082 in shm TOC at 0x10be98040
> The fix for that problem seems to be:
> /* Recreate error queues. */
> erro
On 2 February 2018 at 18:46, Robert Haas wrote:
> On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
>> In PG11, I propose the following command, sticking mostly to Ants'
>> syntax, and allowing to wait for multiple events before it returns. It
>> doesn't hold snapshot and will not get cancelled
On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
> In PG11, I propose the following command, sticking mostly to Ants'
> syntax, and allowing to wait for multiple events before it returns. It
> doesn't hold snapshot and will not get cancelled by Hot Standby.
>
> WAIT FOR event [, event ...] optio
On Fri, Feb 2, 2018 at 10:37 AM, Robert Haas wrote:
> And that patch you attached is also, now, committed.
>
> If you could keep an eye on the buildfarm and investigate anything
> that breaks, I would appreciate it.
Fantastic!
I can keep an eye on it throughout the day.
Thanks everyone
--
Pete
On Fri, Feb 2, 2018 at 11:16 AM, Peter Geoghegan wrote:
> Attached patch has these changes.
And that patch you attached is also, now, committed.
If you could keep an eye on the buildfarm and investigate anything
that breaks, I would appreciate it.
--
Robert Haas
EnterpriseDB: http://www.enterp
On Fri, Feb 2, 2018 at 9:26 AM, Oliver Ford wrote:
> On Thu, Feb 1, 2018 at 1:46 AM, David G. Johnston
> wrote:
>
> > The three callers of WinGetFuncArgInFrame don't use the isout argument;
> they
> > probably need to read that and a new isexcluded argument. Start at the
> > head, loop until is
On Fri, Feb 2, 2018 at 1:27 AM, Masahiko Sawada wrote:
> Thank you for suggestion. It sounds more smarter. So it would be more
> better if we vacuums database for anti-wraparound in ascending order
> of relfrozenxid?
Currently, we're doing it based on datfrozenxid. I was looking for a
small, rel
On 01.02.2018 23:28, Vladimir Sitnikov wrote:
> config/pgjsonb-local.dat
Do you use standard "workload" configuration values?
(e.g. recordcount=1000, maxscanlength=100)
Yes, I used default value for workload. For example, workload-A has the
following settings:
# Yahoo! Cloud System Bench
On Fri, Feb 2, 2018 at 4:22 AM, Andrey Borodin wrote:
> I can try to do this before next CF. But ISTM that EDB and Postgres Pro
> already have various flavours of similar feature. Maybe they are planning to
> publish that?
I would definitely review that patch.
--
Peter Geoghegan
On Fri, Feb 2, 2018 at 6:11 AM, Robert Haas wrote:
>> Fair enough, you can proceed with the patch.
>
> Committed. Now, on to the main event!
Thank you both.
--
Peter Geoghegan
On Wed, Jan 31, 2018 at 11:53 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Why not write `is_separator_char` using `isprint`, `isalpha`, `isdigit` from
> ctype.h? Something like:
>
> return isprint(*str) && !isalpha(*str) && !isdigit(*str)
>
> From what I see in the source code they do ex
On Thu, Feb 1, 2018 at 7:21 PM, Simon Riggs wrote:
> Yes, it would be about 99% of the time.
>
> But you have it backwards - we are not assuming that case. That is the
> only case that has risk - the one where an old WAL record starts at
> exactly the place the latest one stops. Otherwise the rest
On Fri, Feb 2, 2018 at 1:43 AM, Amit Khandekar wrote:
> On 2 February 2018 at 03:50, Thomas Munro
> wrote:
>> Whatever logic bug might be causing the query to hang, it's not good
>> that we're unable to SIGINT/SIGTERM our way out of this state. See
>> also this other bug report for a known prob
On Thu, Feb 1, 2018 at 8:09 PM, Tatsuo Ishii wrote:
> Initially I thought all base tables including ones in a subquery also
> should be locked like you. But after some discussions with Yugo, I
> agree that locking table in a subquery is less valuable for users (and
> I am afraid it may introduce m
Hi,
Attached patch introduces prefix operator ^@ for text type. For 'a ^@ b'
it returns true if 'a' starts with 'b'. Also there is spgist index
support for this operator.
It could be useful as an alternative for LIKE for 'something%'
templates. Or even used in LIKE queries instead of ~>=~ and ~<~
On Fri, Feb 2, 2018 at 1:04 AM, Amit Langote
wrote:
> Your proposed cleanup sounds much better, so I implemented it in the
> attached updated 0001, while dropping the previously proposed
> PartitionBoundCmpArg approach.
>
> Updated set of patches attached (patches 0002 onward mostly unchanged,
> e
Tomas Vondra writes:
> ISTM this patch got somewhat stuck as we're not quite sure the
> transformation is correct in all cases. Is my impression correct?
Yeah, that's the core issue.
> If yes, how to we convince ourselves? Would some sort of automated testing
> (generating data and queries) help
On Thu, Feb 1, 2018 at 9:34 PM, Masahiko Sawada wrote:
> On Mon, Jan 29, 2018 at 11:31 PM, Claudio Freire
> wrote:
>> On Mon, Jan 29, 2018 at 4:12 AM, Masahiko Sawada
>> wrote:
>>> On Sat, Jul 29, 2017 at 9:42 AM, Claudio Freire
>>> wrote:
Introduce a tree pruning threshold to FreeSpace
On Thu, Feb 1, 2018 at 9:48 PM, Amit Kapila wrote:
> On Thu, Feb 1, 2018 at 9:09 PM, Robert Haas wrote:
>> On Wed, Jan 31, 2018 at 10:08 PM, Amit Kapila
>> wrote:
>>> I think suggesting to use this API to wait "for a specific worker"
>>> doesn't seem like a good idea as it doesn't have any such
On Fri, Feb 2, 2018 at 8:25 AM, Jeevan Chalke
wrote:
>> The problem is that create_partition_agg_paths() is doing *exactly*
>> same thing that add_paths_to_grouping_rel() is already doing inside
>> the blocks that say if (grouped_rel->partial_pathlist). We don't need
>> two copies of that code.
On Thu, Feb 1, 2018 at 5:08 AM, Christoph Berg wrote:
> Re: Peter Eisentraut 2018-01-03
> <99680dba-cf63-8151-1de2-46ca93897...@2ndquadrant.com>
>> One scenario is that if GnuTLS goes in, it's quite plausible that the
>> PG11 packages for Debian and Ubuntu will use it by default. But if it
>> do
On Fri, Feb 2, 2018 at 1:41 AM, Robert Haas wrote:
> On Thu, Feb 1, 2018 at 8:59 AM, Jeevan Chalke
> wrote:
> > I wrote a patch for this (on current HEAD) and attached separately here.
> > Please have a look.
>
> Yes, this is approximately what I had in mind, though it needs more
> work (e.g. it
On 01/04/2018 11:50 PM, Tom Lane wrote:
> I wrote:
>> Jim Nasby writes:
>>> I've verified that the patch still applies and make check-world is clean.
>
>> Not any more :-(. Here's a v3 rebased over HEAD. No substantive
>> change from v2.
>
> Again rebased up to HEAD; still no substantive chang
Hello!
> 1 февр. 2018 г., в 19:09, Peter Eisentraut
> написал(а):
>
> On 1/31/18 11:48, Vladimir Borodin wrote:
>> Will it work only for a particular database? Or for a whole cluster
>> during initdb also? Any chance to get this done in 11?
>
> I'm currently not working on it.
>
> It's basica
(2018/01/25 23:33), Stephen Frost wrote:
I'm afraid a good bit of this patch is now failing to apply. I don't
have much else to say except to echo the performance concern that Amit
Langote raised about expanding the inheritence tree twice.
To address that concern, I'm thinking to redesign the
Greetings,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2018/01/23 8:57, Thomas Munro wrote:
> > On Tue, Jan 23, 2018 at 12:41 PM, Thomas Munro
> > wrote:
> >> On Mon, Jan 15, 2018 at 2:32 PM, Stephen Frost wrote:
> >>> If someone else would like to review it, that'd be great, othe
Hi.
> 2 февр. 2018 г., в 13:25, Andrey Borodin написал(а):
>
>> Do folks here think that speedups would be worth it?
> I've seen backup verification via COPY TO to /dev/null in production. These
> copies were parallelized on the side of verification script.
> Not sure this counts for feature or
(2018/02/02 19:33), Etsuro Fujita wrote:
(2018/01/25 23:33), Stephen Frost wrote:
I'm afraid a good bit of this patch is now failing to apply. I don't
have much else to say except to echo the performance concern that Amit
Langote raised about expanding the inheritence tree twice.
To address th
On Friday, February 2, 2018 10:48:16 AM CET Pierre Ducroquet wrote:
> On Monday, January 29, 2018 10:53:50 AM CET Andres Freund wrote:
> > Hi,
> >
> > On 2018-01-23 23:20:38 -0800, Andres Freund wrote:
> > > == Code ==
> > >
> > > As the patchset is large (500kb) and I'm still quickly evolving it
Hi!
Michael, thanks for the patch!
> 2 февр. 2018 г., в 9:22, Michael Paquier
> написал(а):
>
> On Thu, Feb 01, 2018 at 02:24:46PM +0100, Michael Banck wrote:
>> dumping a database to /dev/null via pg_dump is (AFAIK) one recommended
>> way to check for corruption. However, dumping to /dev/nul
(2018/01/30 18:52), Etsuro Fujita wrote:
(2018/01/30 18:39), Amit Langote wrote:
Will wait for your comments before sending a new version then.
Ok, I'll post my comments as soon as possible.
* ExecInitPartitionResultRelInfo is called from ExecFindPartition, but
we could call that another wa
Hi,
On 2018-02-02 18:22:34 +1300, Thomas Munro wrote:
> The clang that was used for bitcode was the system /usr/bin/clang,
> version 4.0. Is it a problem that I used that for compiling the
> bitcode, but LLVM5 for JIT? I actually tried
> CLANG=/usr/local/llvm50/bin/clang but ran into weird failu
Hi David.
On 2018/02/01 8:57, David Rowley wrote:
> On 31 January 2018 at 21:03, Amit Langote
> wrote:
>> Update patch set attached. Thanks again.
>
> (My apologies for being slow to respond here. I've been on leave this
> week and I'm off again next week. I now have a little time to reply)
N
On Monday, January 29, 2018 10:53:50 AM CET Andres Freund wrote:
> Hi,
>
> On 2018-01-23 23:20:38 -0800, Andres Freund wrote:
> > == Code ==
> >
> > As the patchset is large (500kb) and I'm still quickly evolving it, I do
> > not yet want to attach it. The git tree is at
> >
> > https://git.po
Hi,
Am Freitag, den 02.02.2018, 13:22 +0900 schrieb Michael Paquier:
> On Thu, Feb 01, 2018 at 02:24:46PM +0100, Michael Banck wrote:
> > dumping a database to /dev/null via pg_dump is (AFAIK) one recommended
> > way to check for corruption. However, dumping to /dev/null is currently
> > not supp
On 2018/01/29 14:57, Tom Lane wrote:
> Amit Langote writes:
>> Partition bound literals as captured gram.y don't have any type
>> information attached.
>
> Isn't that design broken by definition? TRUE is not the same thing
> as 't', nor as 'true'. Nor are 1 and '1' the same thing; it's true
> t
Greetings,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 22 January 2018 at 23:21, Stephen Frost wrote:
>
> >> It sounds reasonable. I can offer the following version.
> >>
> >> WAIT LSN lsn_number;
> >> WAIT LSN lsn_number TIMEOUT delay;
> >> WAIT LSN lsn_number INFINITE;
> >> WAIT
On 2018-02-01 22:20:01 -0800, Jeff Davis wrote:
> Thanks! That worked, but I had to remove the "-stdlib=libc++" also,
> which was causing me problems.
That'll be gone as soon as I finish the shlib thing. Will hope to have
something over the weekend. Right now I'm at FOSDEM and need to prepare
a ta
Hi,
On 2018-02-02 18:22:34 +1300, Thomas Munro wrote:
> Is there something broken about my installation? I see simple
> arithmetic expressions apparently compiling and working but I can
> easily find stuff that breaks... so far I think it's anything
> involving string literals:
That definitely s
On 1 February 2018 at 09:32, Simon Riggs wrote:
> OK, thanks. Just checking my understanding and will add to the
> comments in the patch.
I'm feeling good about ths now, but for personal reasons won't be
committing this until late Feb/early March.
--
Simon Riggshttp://www.2ndQu
On 30 October 2017 at 17:25, Ivan Kartyshov wrote:
> It sounds reasonable. I can offer the following version.
>
> WAIT LSN lsn_number;
> WAIT LSN lsn_number TIMEOUT delay;
> WAIT LSN lsn_number INFINITE;
> WAIT LSN lsn_number NOWAIT;
>
>
> WAIT [token] wait_value [option];
>
> token
Hi Amit,
Sorry for the delayed response.
On Fri, Jan 26, 2018 at 11:58 AM, Amit Kapila wrote:
> On Wed, Jan 24, 2018 at 12:44 PM, amul sul wrote:
>> On Tue, Jan 23, 2018 at 7:01 PM, Amit Kapila wrote:
>>> On Fri, Jan 12, 2018 at 11:43 AM, amul sul wrote:
[]
> I think you can manually (via
72 matches
Mail list logo
