Hello, hackers!
I found in src/backend/utils/mb/wchar.c: pg_verify_mbstr_len() that it
reports ASCII Null character (\000) as invalid. As for me, it should
pass validation. However, ASCII Null character breaks a line and the
end of the line is missed, try:
INSERT INTO mytable VALUES (E'a\001b\000
On Thu, Nov 30, 2017 at 9:00 AM, Ashutosh Bapat
wrote:
> On Thu, Nov 30, 2017 at 8:50 AM, Michael Paquier
> wrote:
>> On Fri, Mar 24, 2017 at 10:50 PM, Tom Lane wrote:
>>> Ashutosh Bapat writes:
> Do you have test case, which can reproduce the issue you
> explained above?
>>>
No. I
> On 30 Nov 2017, at 03:30, Petr Jelinek wrote:
>
> On 30/11/17 00:47, Andres Freund wrote:
>> On 2017-11-30 00:45:44 +0100, Petr Jelinek wrote:
>>> I don't understand. I mean sure the SnapBuildWaitSnapshot() can live
>>> with it, but the problematic logic happens inside the
>>> XactLockTableIns
On Thu, Nov 30, 2017 at 1:36 AM, Antonin Houska wrote:
> The following test
>
> -- Input relation to aggregate push down hook is not safe to pushdown and
> thus
> -- the aggregate cannot be pushed down to foreign server.
> explain (verbose, costs off)
> select count(t1.c3) from ft1 t1, ft1 t2 whe
On Thu, Nov 30, 2017 at 4:01 AM, Robert Haas wrote:
>> Better ideas?
>
> How about this:
>
> 1. Remove es_query_dsa altogether.
> 2. Add a dsa_area * to ExecParallelInitializeDSMContext.
> 3. In ExecParallelInitializeDSM, pass the dsa_area * as a separate to
> the per-node-type function.
> 4. If t
On Thu, Nov 30, 2017 at 3:44 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Thu, Nov 30, 2017 at 1:36 AM, Antonin Houska wrote:
>
>> The following test
>>
>> -- Input relation to aggregate push down hook is not safe to pushdown and
>> thus
>> -- the aggregate cannot be pushed
Hi,
>> So perhaps better approach would be to not return
>> HEAPTUPLE_DEAD if the transaction id is newer than the OldestXmin (same
>> logic we use for deleted tuples of committed transactions) in the
>> HeapTupleSatisfiesVacuum() even for aborted transactions. I also briefly
>> checked HOT pruni
On 30 November 2017 at 11:30, Petr Jelinek wrote:
> On 30/11/17 00:47, Andres Freund wrote:
>> On 2017-11-30 00:45:44 +0100, Petr Jelinek wrote:
>>> I don't understand. I mean sure the SnapBuildWaitSnapshot() can live
>>> with it, but the problematic logic happens inside the
>>> XactLockTableInser
On Wed, Nov 29, 2017 at 5:33 AM, Robert Haas wrote:
> On Sun, Nov 26, 2017 at 9:33 PM, Masahiko Sawada
> wrote:
>> Attached latest patch incorporated all comments so far. Please review it.
>
> I think you only need RelExtLockReleaseAllI() where we currently have
> LockReleaseAll(DEFAULT_LOCKMETH
> On 28 Nov 2017, at 02:07, Michael Paquier wrote:
>
> On Tue, Nov 28, 2017 at 12:11 AM, Daniel Gustafsson wrote:
>>> The patch needs a rebase, and there are a couple of places that need
>>> an extra lookup I think:
>>> $ git grep defname -- *.c | grep strcasecmp | wc -l
>>> 39
>>
>> Rebase
David Rowley wrote:
> I wonder if it should be this patches job to alter the code in
> get_relation_info() which causes the indexes not to be loaded for
> partitioned tables:
>
> /*
> * Make list of indexes. Ignore indexes on system catalogs if told to.
> * Don't bother with indexes for an inhe
Michael Paquier wrote:
> On Wed, Nov 15, 2017 at 2:49 AM, Alvaro Herrera
> wrote:
> > Here's the remaining bits, rebased.
>
> At least patch 3 has conflicts with HEAD. I am moving this patch to
> next CF per a lack of reviews, switching status to waiting on author.
Thanks, will submit a new ver
On Thu, Nov 30, 2017 at 6:39 AM, Peter Geoghegan wrote:
> On Wed, Nov 29, 2017 at 8:34 PM, Michael Paquier
> wrote:
> > The patch does not currently apply. I am noticing as well that Peter
> > Geoghegan has registered himself as a reviewer a couple of hours back,
> > so moved to next CF with wai
On Thu, Nov 30, 2017 at 12:20 PM, David Rowley
wrote:
> Thanks for looking over this and my apologies for the delay in my
> response. I've been on leave and out of range of the internet for most
> of that time.
>
> On 23 November 2017 at 02:30, Ashutosh Bapat
> wrote:
>>
>> @@ -597,15 +615,25 @@
(2017/11/30 7:32), Tom Lane wrote:
AFAICT, [1] just demonstrates that nobody had thought about the scenario
up to that point, not that the subsequently chosen solution was a good
one. In that example,
LockRows (cost=100.00..101.18 rows=4 width=70)
Output: tab.a, tab.b, tab.ctid, foo.*, bar
While addressing Thomas's point about test scenarios not yet covered,
I observed the following ...
Suppose an UPDATE RLS policy with a WITH CHECK clause is defined on
the target table. Now In ExecUpdate(), the corresponding WCO qual gets
executed *before* the partition constraint check, as per exi
Etsuro Fujita writes:
> (2017/11/30 7:32), Tom Lane wrote:
>> the output of the foreign join cannot change during EPQ, since the remote
>> server already locked the rows before returning them. The only thing that
>> can change is the output of the local scan on public.tab. Yes, we then
>> need t
Alexey Chernyshov writes:
> I found in src/backend/utils/mb/wchar.c: pg_verify_mbstr_len() that it
> reports ASCII Null character (\000) as invalid. As for me, it should
> pass validation.
This is intentional and we're not going to change it. There is too
much code in the backend that relies on
On Fri, Mar 24, 2017 at 9:50 AM, Tom Lane wrote:
> Yeah. I think the code in mark_dummy_rel is newer and better-thought-out
> than what's in create_unique_path. It probably makes sense to change over.
I did a bit of archaeology here. create_unique_path() first appears
in commit bdfbfde1b168b33
On Wed, Nov 29, 2017 at 11:55 PM, Thomas Munro
wrote:
> Thank you for the original pointer and the commit. Everything here
> seems to make intuitive sense and the accompanying throw-away tests
> that I posted above seem to produce sensible results except in some
> cases that we discussed, so I th
On Thu, 30 Nov 2017 00:30:37 +0100
Tomas Vondra wrote:
> While the results may look differently for other datasets, my
> conclusion is that it's unlikely we'll find another general-purpose
> algorithm beating pglz (enough for people to switch to it, as they'll
> need to worry about testing, deplo
On Wed, Nov 29, 2017 at 10:33 PM, Michael Paquier
wrote:
> On Fri, Sep 15, 2017 at 4:36 AM, Alexander Korotkov
> wrote:
>> +1,
>> FDW looks OK for prototyping pluggable storage, but it doesn't seem suitable
>> for permanent implementation.
>> BTW, Hadi, could you visit "Pluggable storage" thread
On Wed, Nov 29, 2017 at 10:50 PM, Michael Paquier
wrote:
> On Thu, Nov 23, 2017 at 12:23 AM, Arthur Zakirov
> wrote:
>> Messages have the following format now:
>>
>> SELECT to_timestamp('97/Feb/16', 'FXYY:Mon:DD');
>> ERROR: unexpected character "/", expected ":"
>> HINT: In FX mode, punctuatio
On 11/30/2017 05:51 AM, Michael Paquier wrote:> One thing that could be
improved in my
opinion is that patch authors should try more to move a patch to a
following commit fest once the end gets close...This would leverage
slightly the load of work for the CFM.
Thanks for the suggestion. I had n
On Wed, Nov 29, 2017 at 11:07 PM, Michael Paquier
wrote:
> On Fri, Nov 24, 2017 at 11:47 AM, Amit Langote
> wrote:
>> On 2017/11/24 11:45, Amit Langote wrote:
>>> Meanwhile, rebased patch is attached.
>>
>> Oops, forgot to attach in the last email. Attached now.
>
> Moved to next CF.
I have two
On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane wrote:
> The thing that makes me uncomfortable about this is that we used to have a
> catcache size limitation mechanism, and ripped it out because it had too
> much overhead (see commit 8b9bc234a). I'm not sure how we can avoid that
> problem within a f
On Tue, Nov 21, 2017 at 4:36 AM, Peter Moser wrote:
> Hi hackers,
> we like to rethink our approach...
>
> For simplicity I'll drop ALIGN for the moment and focus solely on NORMALIZE:
>
> SELECT * FROM (R NORMALIZE S ON R.x = S.y WITH (R.time, S.time)) c;
>
> Our normalization executor node ne
On 11/29/2017 11:45 PM, Tom Lane wrote:
> Noah Misch writes:
>> On Wed, Nov 29, 2017 at 11:34:56PM -0500, Tom Lane wrote:
>>> I don't really have an opinion about the relative merits of these changes,
>>> but why do anything? The existing solution has the buildfarm happy, and
>>> we've not hear
On Wed, Nov 29, 2017 at 11:35 PM, Michael Paquier
wrote:
> On Mon, Nov 27, 2017 at 11:41 AM, Jing Wang wrote:
>> This is a patch for current_database working on ALTER ROLE/GRANT/REVOKE
>> statements which should be applied after the previous patch
>> "comment_on_current_database_no_pgdump_v4.4.pa
On Thu, Nov 30, 2017 at 6:20 AM, Masahiko Sawada wrote:
>> This code ignores the existence of multiple databases; RELEXTLOCK
>> contains a relid, but no database OID. That's easy enough to fix, but
>> it actually causes no problem unless, by bad luck, you have two
>> relations with the same OID i
Hi, Peter!
> 29 нояб. 2017 г., в 8:45, Peter Geoghegan написал(а):
>
> It looks like amcheck needs to be patched -- a simple oversight.
> amcheck is probably calling _bt_compare() without realizing that
> internal pages don't have the extra attributes (just leaf pages,
> although they should also
On 11/29/17 14:17, Andrew Dunstan wrote:
> On 11/28/2017 10:03 AM, Peter Eisentraut wrote:
>> Here is a new patch that addresses the previous review comments.
>>
>> If there are no new comments, I think this might be ready to go.
>
> Looks good to me. Marking ready for committer.
committed
--
Hi
2017-11-30 3:44 GMT+01:00 Michael Paquier :
> On Wed, Sep 13, 2017 at 12:51 PM, Pavel Stehule
> wrote:
> >
> >
> > 2017-09-13 1:42 GMT+02:00 Daniel Gustafsson :
> >>
> >> > On 08 Apr 2017, at 15:46, David Steele wrote:
> >> >
> >> >> On 1/13/17 6:55 AM, Marko Tiikkaja wrote:
> >> >>> On Fri,
On Thu, Nov 30, 2017 at 6:40 AM, Daniel Gustafsson wrote:
> For reasons unknown to me I had avoided poking in contrib/. Attached patch
> handles the additional defname comparisons in contrib that are applicable.
I am having a bit of trouble understanding why the first hunk in
DefineAggregate() i
On Thu, Nov 30, 2017 at 7:02 AM, Alvaro Herrera wrote:
> Great question. So you're thinking that the planner might have an
> interest in knowing what indexes are defined at the parent table level
> for planning purposes; but for that to actually have any effect we would
> need to change the plann
On 11/30/2017 04:20 PM, Ildus Kurbangaliev wrote:
> On Thu, 30 Nov 2017 00:30:37 +0100
> Tomas Vondra wrote:
>
> ...
>
>> I can imagine other interesting use cases - for example values in
>> JSONB columns often use the same "schema" (keys, nesting, ...), so
>> can I imagine building a "dictionar
On 1 December 2017 at 01:40, Ashutosh Bapat
wrote:
> The patch looks good to me.
> It applies cleanly, compiles on my laptop without warnings or errors.
> make check does not show any failures. Marking it as ready for
> committer.
Great. Many thanks for the review!
--
David Rowley
On Wed, Nov 29, 2017 at 5:32 PM, Tom Lane wrote:
> AFAICT, [1] just demonstrates that nobody had thought about the scenario
> up to that point, not that the subsequently chosen solution was a good
> one.
But have a look at this:
http://postgr.es/m/561e12d4.7040...@lab.ntt.co.jp
That shows a cas
On 11/30/17 03:13, Alexey Chernyshov wrote:
> I found in src/backend/utils/mb/wchar.c: pg_verify_mbstr_len() that it
> reports ASCII Null character (\000) as invalid. As for me, it should
> pass validation. However, ASCII Null character breaks a line and the
> end of the line is missed, try:
>
> I
On Thu, Nov 30, 2017 at 10:39:56AM -0500, Robert Haas wrote:
>
> So is it now the case that all of the regression test cases in this
> patch produce the same results as they would on Oracle?
>
Yes, exactly. All new cases give the same result as in Oracle, except
text of error messages.
--
Arth
On Fri, Dec 1, 2017 at 7:48 AM, Peter Eisentraut
wrote:
> On 11/29/17 14:17, Andrew Dunstan wrote:
>> On 11/28/2017 10:03 AM, Peter Eisentraut wrote:
>>> Here is a new patch that addresses the previous review comments.
>>>
>>> If there are no new comments, I think this might be ready to go.
>>
>>
On Wed, Nov 29, 2017 at 11:53 AM, Sergei Kornilov wrote:
> Here is new patch with check only existed valid constraints and without SPI
> at all.
Please use pgindent or anyway try to follow project style. { needs to
go on a line by itself, for example.
isSetNotNullNeedsTableScan seems different
On Mon, Sep 4, 2017 at 12:27 PM, Greg Stark wrote:
> 1) Why do we gather a per-session log line number? Is it just to aid
> people importing to avoid duplicate entries from partial files? Is
> there some other purpose given that entries will already be sequential
> in the csv file?
I think the id
On Fri, Dec 1, 2017 at 4:05 AM, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 11:55 PM, Thomas Munro
> wrote:
>> Thank you for the original pointer and the commit. Everything here
>> seems to make intuitive sense and the accompanying throw-away tests
>> that I posted above seem to produce sensibl
On Tue, Nov 21, 2017 at 9:26 AM, Amit Kapila wrote:
> +1. I was also once confused with these macros. I think this is a
> good cleanup. On a quick look, I don't see any problem with your
> changes.
One difference between those two macros is that IndexTupleSize
forcibly casts the argument to In
On Thu, Nov 30, 2017 at 1:48 PM, Robert Haas wrote:
> One difference between those two macros is that IndexTupleSize
> forcibly casts the argument to IndexTuple, which means that you don't
> get any type-checking when you use that one. I suggest that in
> addition to removing IndexTupleDSize as p
Thank you for review! My apologies for my errors. It seems i read developers
wiki pages not enough carefully. I will reread wiki, code style and then update
patch with all your remarks.
> The comment /* T if we added new NOT NULL constraints */ should
> probably be changed to /* T if we should r
Tomas Vondra wrote:
> On 11/30/2017 04:20 PM, Ildus Kurbangaliev wrote:
> > CREATE COMPRESSION METHOD ts1 FOR tsvector HANDLER
> > tsvector_compression_handler;
>
> Understood. Good to know you've considered it, and I agree it doesn't
> need to be there from the start (which makes the patch simp
On Fri, Dec 1, 2017 at 12:44 AM, Andreas Karlsson wrote:
> On 11/30/2017 05:51 AM, Michael Paquier wrote:> One thing that could be
> improved in my
>>
>> opinion is that patch authors should try more to move a patch to a
>> following commit fest once the end gets close...This would leverage
>> sli
On Fri, Dec 1, 2017 at 10:41 AM, Thomas Munro
wrote:
> On Fri, Dec 1, 2017 at 4:05 AM, Robert Haas wrote:
>> Hmm, do you have an example of the better but still-funky estimates
>> handy? Like an EXPLAIN plan?
>
> Sure. Here's some EXPLAIN ANALYZE output from scale 3 TPCH + a few
> indexes[1].
Alexey Kondratov wrote:
> I have rebased my branch and squashed all commits into one, since the
> patch is quite small. Everything seems to be working fine now, patch
> passes all regression tests.
On a *very* quick look, please use an enum to return from NextCopyFrom
rather than 'int'. The chun
On 24 November 2017 at 14:20, Andres Freund wrote:
> Pushed a fix to the relevant branches, including tests of the
> trans/combine functions returns NULL cases.
Apologies for my silence here. I've been on leave and out of internet
range for two weeks.
Thank you for making the fix.
--
David Ro
On Fri, Dec 1, 2017 at 4:14 AM, Robert Haas wrote:
> I think the changes in DefineView and ATExecSetRelOptions is wrong,
> because transformRelOptions() is still using pg_strcasecmp. With the
> patch:
>
> rhaas=# create view v(x) with ("Check_option"="local") as select 1;
> CREATE VIEW
> rhaas=#
On Fri, Dec 1, 2017 at 3:04 AM, Robert Haas wrote:
> On Thu, Nov 30, 2017 at 6:20 AM, Masahiko Sawada
> wrote:
>>> This code ignores the existence of multiple databases; RELEXTLOCK
>>> contains a relid, but no database OID. That's easy enough to fix, but
>>> it actually causes no problem unless
On 2017/12/01 1:02, Robert Haas wrote:
> On Wed, Nov 29, 2017 at 11:07 PM, Michael Paquier
> wrote:
>> On Fri, Nov 24, 2017 at 11:47 AM, Amit Langote
>> wrote:
>>> On 2017/11/24 11:45, Amit Langote wrote:
Meanwhile, rebased patch is attached.
>>>
>>> Oops, forgot to attach in the last email.
On Thu, Nov 30, 2017 at 8:19 PM, Robert Haas wrote:
> On Fri, Mar 24, 2017 at 9:50 AM, Tom Lane wrote:
>> Yeah. I think the code in mark_dummy_rel is newer and better-thought-out
>> than what's in create_unique_path. It probably makes sense to change over.
>
> I did a bit of archaeology here.
On Wed, Nov 29, 2017 at 7:42 AM, Peter Eisentraut
wrote:
> On 11/28/17 17:33, Michael Paquier wrote:
>> 1) Have a special value in the parameter saslchannelbinding proposed
>> in patch 0001. For example by specifying "none" then no channel
>> binding is used.
>
> I was thinking if it's empty then
On 24 November 2017 at 13:45, Amit Langote
wrote:
>> Why? There is no caller that needs information.
>
> It is to be used if and when ExecInsert() calls
> ExecCheckIndexConstraints() in the code path to handle ON CONFLICT DO
> NOTHING that we're intending to support in some cases. Note that it w
On Thu, Nov 30, 2017 at 10:17 AM, Amit Langote
wrote:
> Oops, I messed up taking the diff and mistakenly added noise to the patch.
Which is that bit:
- * BuildSlotPartitionKeyDescription
+ * ExecBuildSlotPartitionKeyDescription
> Fixed in the attached.
For information, it is easy enough to run
On Fri, Nov 24, 2017 at 11:38 PM, Simon Riggs wrote:
> On 23 November 2017 at 11:11, Michael Paquier
> wrote:
>
>> This is older than the bug report of this thread. All those
>> indications point out that the patch has *not* been committed. So it
>> seems to me that you perhaps committed it to y
On Wed, Nov 29, 2017 at 7:36 AM, Michael Paquier
wrote:
> On Wed, Nov 29, 2017 at 6:44 AM, Robert Haas wrote:
>> On Tue, Nov 21, 2017 at 4:32 AM, Masahiko Sawada
>> wrote:
>>> Thank you for comments. Attached updated patch.
>>
>> I see that Michael has marked this Ready for Committer, but also
On Tue, Nov 7, 2017 at 1:34 AM, Fabien COELHO wrote:
> Let's now hope that a committer gets around to consider these patch some
> day.
Which is not the case yet, so moved to CF 2018-01. Please note that
the patch proposed does not apply anymore, so its status is changed to
"waiting on author" for
On Sat, Nov 4, 2017 at 8:05 PM, Fabien COELHO wrote:
>>> Here is a v13, which is just a rebase after the documentation
>>> xml-ization.
>
> Here is a v14, after yet another rebase, and some comments added to answer
> your new comments.
The last patch sent still applies, but its status of "ready f
On Wed, Oct 25, 2017 at 5:57 PM, Pavel Stehule wrote:
> 2017-10-20 18:36 GMT+02:00 Fabien COELHO :
> Here is a v13. No code changes, but TAP tests added to maintain pgbench
> coverage to green.
>>
>>
>> Here is a v14, which is just a rebase after the documentation xml-ization.
>
> all test
On Wed, Nov 29, 2017 at 5:50 AM, Robert Haas wrote:
> On Mon, Aug 7, 2017 at 11:14 AM, Fabrízio de Royes Mello
> wrote:
>> I also test against all current supported versions (9.2 ... 9.6) and didn't
>> find any issue.
>>
>> Changed status to "ready for commiter".
>
> On a very fast read this patc
Hi hackers,
The manual implies that only Linux can use huge pages. That is not
true: FreeBSD, Illumos and probably others support larger page sizes
using transparent page coalescing algorithms. On my FreeBSD box
procstat -v often shows PostgreSQL shared buffers in "S"-flagged
memory. I think we
On Fri, Nov 24, 2017 at 9:28 AM, Tsunakawa, Takayuki
wrote:
> From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
>> I hope Tsunakawa-san doesn't mind me posting another rebased version of
>> his patch. The last version conflicted with the change from SGML to XML
>> that just landed in comm
On Wed, Nov 8, 2017 at 12:54 AM, Fabrízio de Royes Mello
wrote:
> Great. Changed status to ready for commiter.
The patch still applies, but no committer seem to be interested in the
topic, so moved to next CF.
--
Michael
On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
> Hi hackers,
>
> The manual implies that only Linux can use huge pages. That is not
> true: FreeBSD, Illumos and probably others support larger page sizes
> using transparent page coalescing algorithms. On my FreeBSD box
> procstat -
Robert Haas writes:
> On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane wrote:
>> The thing that makes me uncomfortable about this is that we used to have a
>> catcache size limitation mechanism, and ripped it out because it had too
>> much overhead (see commit 8b9bc234a). I'm not sure how we can avoid
On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby wrote:
> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
>> Hi hackers,
>>
>> The manual implies that only Linux can use huge pages. That is not
>> true: FreeBSD, Illumos and probably others support larger page sizes
>> using transparent
On 1 December 2017 at 01:02, Alvaro Herrera wrote:
> we currently (I mean after my
> patch) don't mark partitioned-table-level indexes as valid or not valid
> depending on whether all its children exist, so trying to use that in
> the planner without having a flag could cause invalid plans to be
>
On 2017/12/01 11:27, Simon Riggs wrote:
> On 24 November 2017 at 13:45, Amit Langote
> wrote:
>
>>> Why? There is no caller that needs information.
>>
>> It is to be used if and when ExecInsert() calls
>> ExecCheckIndexConstraints() in the code path to handle ON CONFLICT DO
>> NOTHING that we're
On 2017/12/01 11:48, Michael Paquier wrote:
> On Thu, Nov 30, 2017 at 10:17 AM, Amit Langote
> wrote:
>> Oops, I messed up taking the diff and mistakenly added noise to the patch.
>
> Which is that bit:
> - * BuildSlotPartitionKeyDescription
> + * ExecBuildSlotPartitionKeyDescription
Yep.
>> F
On Sat, Nov 11, 2017 at 12:57 AM, Pavel Stehule wrote:
> 2017-11-10 16:38 GMT+01:00 Fabien COELHO :
>> So I switched the patch to "ready for committer".
>
> Thank you very much
Patch moved to CF 2018-01 with same status: ready for committer.
--
Michael
On Thu, Nov 30, 2017 at 12:06 AM, Masahiko Sawada wrote:
> On Wed, Nov 29, 2017 at 11:05 PM, Simon Riggs wrote:
>> Unless there is disagreement on the above, it seems we should apply
>> Yura's patch (an edited version, perhaps).
>>
>
> IIRC the patches that makes the cleanup scan skip has a probl
On Wed, Sep 13, 2017 at 4:07 PM, Ashutosh Bapat
wrote:
> For a partitioned table, this patch saves the time to run constraint
> exclusion on all the partitions if constraint exclusion succeeds on
> the partitioned table. If constraint exclusion fails, we have wasted
> CPU cycles on one run of cons
On Tue, Nov 28, 2017 at 4:10 AM, Jesper Pedersen
wrote:
> On 11/27/2017 07:41 AM, Юрий Соколов wrote:
>> Oh... there were stupid error in previos file.
>> Attached fixed version.
>
> I can reconfirm my performance findings with this patch; system same as
> up-thread.
I have moved this patch to ne
On Tue, Oct 3, 2017 at 1:20 AM, chenhj wrote:
> I had filled the authors field of this patch in commitfest, and will rebase
> this patch if needed. Thank you for your help!
The documentation of the patch needs a rebase, so I am moving it to
next CF with "waiting on author" as status.
$ git diff
On Thu, Nov 30, 2017 at 12:15 PM, Ashutosh Bapat
wrote:
> On Wed, Nov 29, 2017 at 7:42 PM, Stephen Frost wrote:
>> Ashutosh,
>>
>> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>>> On Wed, Nov 29, 2017 at 4:56 AM, Stephen Frost wrote:
>>> > The "global rethink" being contemplated see
On Tue, Nov 28, 2017 at 5:14 PM, Aleksander Alekseev
wrote:
> The new status of this patch is: Ready for Committer
Patch moved to CF 2018-01. Perhaps a committer will look at it at some point.
--
Michael
On Thu, Nov 30, 2017 at 3:28 AM, Emre Hasegeli wrote:
> It would at least be dump-and-restore hazard if we don't let them in.
> The new version allows NaNs.
>
>> This gives a wrong result for NaN-containing objects.
>
> I removed the NaN aware comparisons from FP macros, and carefully
> reviewed t
On Mon, Nov 20, 2017 at 7:47 PM, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>> On 19 November 2017 at 16:13, Arthur Zakirov
>> wrote:
>>
>> I think it is time to mark the patch as "Ready for Commiter". I've
>> marked it.
>
> Good, thank you for the comprehensive review.
Documentation in patch 4
On Tue, Nov 21, 2017 at 8:24 PM, Martín Marqués wrote:
> Thank you very much for reviewing the patch and for your valuable
> input (you made me read the Microsoft Visual C specs ;))
+ if (!isatty(fileno(stderr)))
+ fprintf(stderr, "\n");
+ else
+ fprintf(stderr, "\r");
Er, why is
On Thu, Nov 30, 2017 at 1:51 PM, Michael Paquier
wrote:
> Remains 22 patches as of now, exactly *one* for each committer.
And the last 21 patches have been classified as well. Here is the
final score for this time:
Committed: 55.
Moved to next CF: 103.
Rejected: 1.
Returned with Feedback: 47.
Tot
Hello Michaël,
Here is a v14, after yet another rebase, and some comments added to answer
your new comments.
The last patch sent still applies, but its status of "ready for
committer" does not look adapted as this version got no reviews. So I
am switching back the patch as "needs review". Fee
Hello Michaël,
And the last 21 patches have been classified as well. Here is the
final score for this time:
Committed: 55.
Moved to next CF: 103.
Rejected: 1.
Returned with Feedback: 47.
Total: 206.
Thanks to all the contributors for this session! The CF is now closed.
Thanks for the CF mana
On Tue, Oct 31, 2017 at 2:45 PM, Robert Haas wrote:
>> OK, committed. This is a good example of how having good code
> coverage doesn't necessarily mean you've found all the bugs. :-)
>
As of now partition_join.sql is not having test cases covering cases
where partition table have default partit
On 2017/12/01 11:01, Amit Langote wrote:
> On 2017/12/01 1:02, Robert Haas wrote:
>> Second, this would be the first place where the second argument to
>> ExecOpenIndices() is passed simply as true. The only other caller
>> that doesn't pass constant false is in nodeModifyTable.c and looks
>> like
89 matches
Mail list logo
