On 04/06/2018 08:13 PM, Andres Freund wrote:
> On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote:
>> On 04/06/2018 07:46 PM, Andres Freund wrote:
Sure. But what would that be? I can't think of anything. A process that
modifies a buffer (or any other piece of shared state) without holding
I felt it was worth spending some extra effort on documentation for
this change, since it's going to impact a lot of future patches.
Accordingly, I've taken John's proposed README text and moved it
into the SGML format, and done a fair amount of editing to extend
the text and bring it all up to
On 04/06/2018 08:13 PM, Andres Freund wrote:
> On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote:
>> On 04/06/2018 07:46 PM, Andres Freund wrote:
Sure. But what would that be? I can't think of anything. A process that
modifies a buffer (or any other piece of shared state) without
Michael,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Fri, Apr 06, 2018 at 09:15:15AM -0400, Stephen Frost wrote:
> > I'll reply to David's last email (where the latest set of patches were
> > included) with my comments/suggestions and I expect we'll be able to get
> > those addressed
Sorry for this late reply, I was very busy with the patch for pgbench..
On 04-04-2018 20:07, Simon Riggs wrote:
...
Which debug mode are we talking about, please?
-d 5
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Oh, one more thing: looking again at the contents of pg_proc.dat,
I find myself annoyed at the need to specify pronargs. That's
entirely derivable from proargtypes, and if we did so, we'd get
down to this for the first few pg_proc entries:
{ oid => '1242', descr => 'I/O',
proname => 'boolin',
So I pushed this 25 minutes ago, and already there's a couple of
buildfarm members complaining:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=quokka=2018-04-06%2020%3A09%3A52
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=termite=2018-04-06%2019%3A55%3A07
Both show exactly the
On Thu, Apr 5, 2018 at 2:41 PM, Michael Banck
wrote:
> Hi,
>
> On Thu, Apr 05, 2018 at 01:02:27PM +0200, Magnus Hagander wrote:
> > On Wed, Apr 4, 2018 at 8:22 PM, Michael Banck >
> > wrote:
> > > Otherwise, I had a quick look and there is
On 4/5/18, 9:48 PM, "Michael Paquier" wrote:
> On Fri, Apr 06, 2018 at 06:41:14AM +0900, Michael Paquier wrote:
>> That would be wiser. We are two days away from the end of the CF and
>> this patch gets quite invasive with a set of new concepts, so my
>> recommendation would
Robert Haas wrote:
> On Wed, Apr 4, 2018 at 1:03 PM, Alvaro Herrera
> wrote:
> > Foreign keys on partitioned tables
> >
> > Author: Álvaro Herrera
> > Discussion:
> > https://postgr.es/m/20171231194359.cvojcour423ulha4@alvherre.pgsql
> > Reviewed-by: Peter Eisentraut
>
It sure looks like there's been a frantic push to commit stuff that
maybe wasn't quite fully baked. I'm not terribly on board with that,
because it's likely to be hard to disentangle who broke what.
But in particular, it's clear that partition_prune and
isolation/checksum_cancel are showing big
On Fri, Apr 6, 2018 at 11:19 PM, Andres Freund wrote:
> On 2018-04-06 23:12:19 +0200, Magnus Hagander wrote:
> > Daniel is working on investigating the isolationtester thing. See a mail
> on
> > one of the threads where initial indications were the "atomics with no
> real
> >
On 2018-04-06 19:59:17 +0200, Tomas Vondra wrote:
> On 04/06/2018 07:46 PM, Andres Freund wrote:
> >> Sure. But what would that be? I can't think of anything. A process that
> >> modifies a buffer (or any other piece of shared state) without holding
> >> some sort of lock seems broken by default.
> I've created a draft patch that provides access to plans in a view
> called pg_stat_statements_plans.
++ I like it !
> There is no column that indicates whether the plan is "good" or "bad",
> because that is evident from the execution time of both plans and because
> that would require
On 2018-04-06 17:28:00 -0300, Alvaro Herrera wrote:
> So I pushed this 25 minutes ago, and already there's a couple of
> buildfarm members complaining:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=quokka=2018-04-06%2020%3A09%3A52
>
On Thu, Apr 5, 2018 at 5:01 PM, Andres Freund wrote:
> I've commented weeks ago about my doubts, and Robert concurred:
> http://archives.postgresql.org/message-id/CA%2BTgmoZPRfMqZoK_Fbo_tD9OH9PdPFcPBsi-sdGZ6Jg8OMM2PA%40mail.gmail.com
Yes, and I expressed some previous
On Fri, Apr 6, 2018 at 8:43 PM, Andres Freund wrote:
> On 2018-04-06 20:39:26 +0300, Alexander Korotkov wrote:
> > On Fri, Apr 6, 2018 at 7:56 PM, Andres Freund
> wrote:
> >
> > > On 2018-04-06 12:22:09 -0400, Bruce Momjian wrote:
> > > > And as Robert
Greetings,
* Stephen Frost (sfr...@snowman.net) wrote:
> Great, thanks. I'll be doing more review of it myself and see about
> pushing it later this afternoon.
Took a bit longer as I wanted to check over a few more things, but I've
now pushed this. Thanks much for all of the help with review
On Fri, Apr 6, 2018 at 10:59 PM, Tom Lane wrote:
> It sure looks like there's been a frantic push to commit stuff that
> maybe wasn't quite fully baked. I'm not terribly on board with that,
> because it's likely to be hard to disentangle who broke what.
> But in particular,
On 2018-04-06 23:12:19 +0200, Magnus Hagander wrote:
> Daniel is working on investigating the isolationtester thing. See a mail on
> one of the threads where initial indications were the "atomics with no real
> atomics" (or whatever you'd call it) were to blame. We could redo that
> thing without
On Sat, Apr 7, 2018 at 1:50 AM, Andres Freund wrote:
> Hi,
>
> On 2018-04-06 21:30:36 +0930, Andrew Dunstan wrote:
>> OK, I think this is now committable.
>
>> The changes are small, fairly isolated in effect, and I think every
>> objection has been met, partly by reducing the
Claudio Freire wrote:
> On Fri, Apr 6, 2018 at 11:00 AM, Alvaro Herrera
> wrote:
> > FWIW I liked the idea of having this abstraction possibly do other
> > things -- for instance to vacuum brin indexes you'd like to mark index
> > tuples as "containing tuples that were
I'm sorry I was very busy with the patch for pgbench..
On 04-04-2018 19:19, Tom Lane wrote:
...
BTW, poking around in the grammar, I notice that MergeStmt did not
get added to RuleActionStmt. That seems like a rather serious
omission.
Thank you very much! I will try to do this, if you do
On 2018-03-05 17:07:10 -0500, Tom Lane wrote:
> Joe Conway writes:
> > On 03/05/2018 11:19 AM, Tom Lane wrote:
> >> Joe, I wonder if you could add "log_autovacuum_min_duration = 0" to
> >> rhinoceros' extra_config options, temporarily? Correlating that log
> >> output with
Hi,
On 2018-04-06 14:27:39 -0400, Tom Lane wrote:
> John and I are probably both too close to the patch to be able to
> review this documentation for clarity and usefulness, so if anyone
> else wants to have a look, please comment.
Quick skim only:
> diff --git a/doc/src/sgml/bki.sgml
Hi,
I'm still not particularly happy with this. Checking whether I can
polish it up.
a) the new function names are partially non-descriptive and their
meaning is undocumented. As an extreme example:
- if (!FD_ISSET(sock, _mask))
+
On 2018-04-06 14:14:40 -0400, Robert Haas wrote:
> and granted, too, what is Magnus supposed to do about a couple of
> committers expressing doubts about whether something really ought to
> be committed? Is that an absolute bar? It wasn't phrased as such,
> nor do we really have the authority.
On Sun, Apr 1, 2018 at 6:07 PM, Magnus Hagander wrote:
> On Sun, Apr 1, 2018 at 6:01 PM, Julian Markwort <
> julian.markw...@uni-muenster.de> wrote:
>
>> On 1. of April 2018 17:46:38 MESZ wrote Magnus Hagander <
>> mag...@hagander.net>:
>>
>> >I assume this is a patch that's
Greetings,
* Heikki Linnakangas (hlinn...@iki.fi) wrote:
> On 06/04/18 19:39, Andres Freund wrote:
> >On 2018-04-06 07:39:28 -0400, Stephen Frost wrote:
> >>While I tend to agree that it'd be nice to just make it cheaper, that
> >>doesn't seem like something that we'd be likely to back-patch and
Greetings Fabien,
* Fabien COELHO (fabien.coe...@mines-paristech.fr) wrote:
> >>Here is a v14, after yet another rebase, and some comments added to
> >>answer your new comments.
> >
> >Attached v15 is a simple rebase after Teodor push of new functions &
> >operators in pgbench.
>
> Patch v16 is
On Fri, Apr 6, 2018 at 7:37 AM, Tom Kincaid wrote:
> So given all this, I am not sure why people feel this patch was rushed
> through or has a flawed design. The comments from Andres while I am
> sure they have merit came before the commit but technically after the
>
David,
* David Steele (da...@pgmasters.net) wrote:
> The GUC shows the current mode of the data directory, while the
> variables in file_perm.c store the mode that should be used to create
> new dirs/files. One is certainly based on the other but I thought it
> best to split them for clarity.
Andres Freund writes:
> Quick skim only:
> "developers" here could possibly be understood to be any sort of
> developer, rather than postgres ones. Perhaps just say "But the
> structure of the catalogs can change between major versions."?
OK.
> This sounds like an
Hi all,
This is the other Alexander K. speaking.
On 06.04.2018 20:26, Tomas Vondra wrote:
I personally am OK with reducing the scope of the patch like this. It's
still beneficial for the common ORDER BY + LIMIT case, which is good. I
don't think it may negatively affect other cases (at least
Hi,
On 2018-04-06 16:59:11 -0400, Tom Lane wrote:
> It sure looks like there's been a frantic push to commit stuff that
> maybe wasn't quite fully baked. I'm not terribly on board with that,
> because it's likely to be hard to disentangle who broke what.
> But in particular, it's clear that
On Fri, Apr 6, 2018 at 11:44 PM, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-04-06 16:59:11 -0400, Tom Lane wrote:
> >> But in particular, it's clear that partition_prune and
> >> isolation/checksum_cancel are showing big problems.
>
> > While I'm
Andres Freund writes:
> I'm still not particularly happy with this.
I'm a bit confused as to what the point is. It seems unlikely that one
pgbench process can effectively drive enough backends for select's
limitations to really be an issue.
regards,
On 4/6/18 6:04 PM, David Steele wrote:
On 4/6/18 3:02 PM, Stephen Frost wrote:
- Further discussion in the commit messages
Agreed, these need some more work. I'm happy to do that but I'll need a
bit more time. Have a look at the new patches and I'll work on some
better messages.
I'm
On Tue, Mar 27, 2018 at 9:51 AM, Jonathan S. Katz wrote:
> The Release Management Team (RMT) for the PostgreSQL 11 release
> has been assembled and has determined that the feature freeze date
> for the PostgreSQL 11 release will be April 7, 2018. This means that any
>
Andres,
* Andres Freund (and...@anarazel.de) wrote:
> On 2018-04-06 19:31:56 -0400, Stephen Frost wrote:
> > I'm quite sure that bringing up MERGE in this thread and saying it needs
> > to be reverted without even having the committer of that feature on the
> > CC list isn't terribly useful and
Hi,
On 2018-04-06 19:46:25 -0400, Chapman Flack wrote:
> Hasn't been updated as built-in support grew for temp files, DSM segments,
> and JIT contexts.
>
> With enough luck, a README update won't break anything.
Wouldn't it be a better idea not to have a list there, that's guaranteed
to get out
On Fri, Apr 6, 2018 at 11:08 AM, Alexander Korotkov
wrote:
> OK, incorporated into v15. I've also added sentence about pg_upgrade
> to the commit message.
I will summarize my feelings on this patch. I endorse committing the
patch, because I think that the benefits of
David,
* David Steele (da...@pgmasters.net) wrote:
> On 4/6/18 6:04 PM, David Steele wrote:
> >On 4/6/18 3:02 PM, Stephen Frost wrote:
> >>
> >>- Further discussion in the commit messages
> >
> >Agreed, these need some more work. I'm happy to do that but I'll need a
> >bit more time. Have a
Magnus Hagander writes:
> On Fri, Apr 6, 2018 at 11:44 PM, Tom Lane wrote:
>> (I'm also not real happy about the amount of time the checksum-xxx
>> tests consume.)
> The isolation tester ones, or the regular ones? Because the regular ones
> finish in <<
Hi,
On 2018-04-06 02:28:17 +0200, Daniel Gustafsson wrote:
> Applying this makes the _cancel test pass, moving the failure instead to the
> following _enable test (which matches what coypu and mylodon are seeing).
FWIW, I'm somewhat annoyed that I'm now spending time debugging this to
get the
On Fri, Apr 6, 2018 at 6:54 PM, Jonathan S. Katz wrote:
> Yes. It follows the format from the previous ones, i.e:
>
> https://www.postgresql.org/message-id/ca+tgmoy56w5fozeeo+i48qehl+bsvtwy-q1m0xjuhucwggw...@mail.gmail.com
I think my confusion resulted from the fact that
On Fri, Apr 6, 2018 at 6:56 PM, Andres Freund wrote:
> no one can entirely quibble with the rationale that this is ok (I'll
> post a patch cleaning up the atomics simulation of flags in a bit), but
> this is certainly not a correct locking strategy.
I think we have enough
On 2018-04-07 01:04:50 +0200, Daniel Gustafsson wrote:
> > I'm fairly certain that the bug here is a simple race condition in the
> > test (not the main code!):
>
> I wonder if it may perhaps be a case of both?
See my other message about the atomic fallback bit.
> > It's
> > exceedingly
> On 07 Apr 2018, at 01:13, Andres Freund wrote:
>
> On 2018-04-07 01:04:50 +0200, Daniel Gustafsson wrote:
>>> I'm fairly certain that the bug here is a simple race condition in the
>>> test (not the main code!):
>>
>> I wonder if it may perhaps be a case of both?
>
> See
On 7 April 2018 at 10:45, David Rowley wrote:
> I'm looking over the rebased patches now.
I've made a complete read of 0001 and 0002 so far.
Your rebase looks fine.
After the complete read, I only have the following comments:
0001:
1. missing "the" before
On 04/06/18 19:52, Andres Freund wrote:
> On 2018-04-06 19:46:25 -0400, Chapman Flack wrote:
>> Hasn't been updated as built-in support grew for temp files, DSM segments,
>> and JIT contexts.
>>
>> With enough luck, a README update won't break anything.
>
> Wouldn't it be a better idea not to
Alvaro Herrera wrote:
> I rebased this series on top of the committed version of the other patch.
> Here's v22, with no other changes than rebasing. I did not include
> 0005, though.
Apologies, I forgot to "git add" one fixup for 0001.
--
Álvaro Herrera
On Fri, Apr 6, 2018 at 12:51 PM, Alvaro Herrera
wrote:
> My patch is hidden in a very long thread, so I thought letting more
> widely known that I'm proposing to add a new subdir "partitioning" under
> src/backend and src/include.
> TBH I think the new idea is better
On Thu, Apr 5, 2018 at 6:21 AM, Etsuro Fujita
wrote:
> Attached is an updated version of the patch set plus the patch in [1]. Patch
> 0003_foreign-routing-fdwapi-6.patch can be applied on top of patch
> 0001_postgres-fdw-refactoring-6.patch and
>
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Apr 6, 2018 at 6:56 PM, Andres Freund wrote:
> > no one can entirely quibble with the rationale that this is ok (I'll
> > post a patch cleaning up the atomics simulation of flags in a bit), but
> > this is
Robert Haas wrote:
> On Fri, Apr 6, 2018 at 8:24 AM, Alvaro Herrera
> wrote:
> > I don't actually like very much the idea of putting all this code in
> > optimizer/util. This morning it occurred to me that we should create a new
> > src/backend/partitioning/ (and a
On 7 April 2018 at 11:39, Robert Haas wrote:
> Committed. Thanks to David for the report and analysis and to Peter
> for the patch and study.
Thanks for pushing!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support,
On Fri, Apr 6, 2018 at 4:39 PM, Robert Haas wrote:
> Committed. Thanks to David for the report and analysis and to Peter
> for the patch and study.
Thanks!
--
Peter Geoghegan
On 2018-04-07 01:27:13 +0200, Daniel Gustafsson wrote:
> > On 07 Apr 2018, at 01:13, Andres Freund wrote:
> >
> > On 2018-04-07 01:04:50 +0200, Daniel Gustafsson wrote:
> >>> I'm fairly certain that the bug here is a simple race condition in the
> >>> test (not the main
Hi Stephen,
On 4/6/18 3:02 PM, Stephen Frost wrote:
Alright, changes I've made, since I got impatient and it didn't seem to
make sense to bounce these back to David instead of just making them (I
did discuss them with him on the phone today tho, just to be clear).
- The PG_FILE_MODE_DEFAULT,
On 7 April 2018 at 09:29, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> I rebased this series on top of the committed version of the other patch.
>> Here's v22, with no other changes than rebasing. I did not include
>> 0005, though.
>
> Apologies, I forgot to "git
On 2018-04-06 14:33:48 -0700, Andres Freund wrote:
> On 2018-04-06 02:28:17 +0200, Daniel Gustafsson wrote:
> > Looking into the isolationtester failure on piculet, which builds using
> > --disable-atomics, and locust which doesn’t have atomics, the code for
> > pg_atomic_test_set_flag seems a bit
> On Apr 6, 2018, at 6:53 PM, Robert Haas wrote:
>
> On Tue, Mar 27, 2018 at 9:51 AM, Jonathan S. Katz
> wrote:
>> The Release Management Team (RMT) for the PostgreSQL 11 release
>> has been assembled and has determined that the feature freeze date
On 2018-04-06 19:31:56 -0400, Stephen Frost wrote:
> Greetings,
>
> * Robert Haas (robertmh...@gmail.com) wrote:
> > On Fri, Apr 6, 2018 at 6:56 PM, Andres Freund wrote:
> > > no one can entirely quibble with the rationale that this is ok (I'll
> > > post a patch cleaning up
Here's a pass through the patch:
@@ -1033,7 +1034,7 @@ XLogInsertRecord(XLogRecData *rdata,
Assert(RedoRecPtr < Insert->RedoRecPtr);
RedoRecPtr = Insert->RedoRecPtr;
}
- doPageWrites = (Insert->fullPageWrites || Insert->forcePageWrites);
+
On 04/06/18 20:19, Chapman Flack wrote:
> On 04/06/18 19:52, Andres Freund wrote:
>> Wouldn't it be a better idea not to have a list there, that's guaranteed
>> to get out of date?
>
> That might look like this, then.
>
> But I'm not sure how bad it is to have a list. How often does
On Sat, Apr 7, 2018 at 10:31 AM, David Rowley
wrote:
> On 7 April 2018 at 12:43, David Rowley wrote:
>> On 7 April 2018 at 12:35, Amit Langote wrote:
>>> So this same failure occurs on (noting the
Hasn't been updated as built-in support grew for temp files, DSM segments,
and JIT contexts.
With enough luck, a README update won't break anything.
-Chap
>From fb06e17916ad6b445b1cf6361de6a7f2749ea225 Mon Sep 17 00:00:00 2001
From: Chapman Flack
Date: Fri, 6 Apr 2018
Thank you Alvaro for rest of the cleanup and committing.
On Sat, Apr 7, 2018 at 5:28 AM, Alvaro Herrera wrote:
> So I pushed this 25 minutes ago, and already there's a couple of
> buildfarm members complaining:
>
On 7 April 2018 at 12:35, Amit Langote wrote:
> Thank you Alvaro for rest of the cleanup and committing.
+10!
> So this same failure occurs on (noting the architecture):
>
> ppc64:
>
Tom Lane wrote:
> It sure looks like there's been a frantic push to commit stuff that
> maybe wasn't quite fully baked. I'm not terribly on board with that,
> because it's likely to be hard to disentangle who broke what.
> But in particular, it's clear that partition_prune and
>
On 2018-04-06 02:28:17 +0200, Daniel Gustafsson wrote:
> Looking into the isolationtester failure on piculet, which builds using
> --disable-atomics, and locust which doesn’t have atomics, the code for
> pg_atomic_test_set_flag seems a bit odd.
>
> TAS() is defined to return zero if successful,
Andres Freund writes:
> On 2018-04-06 16:59:11 -0400, Tom Lane wrote:
>> But in particular, it's clear that partition_prune and
>> isolation/checksum_cancel are showing big problems.
> While I'm obviously also unhappy about the frantic push to push semi
> baked stuff, I'm not
> On 07 Apr 2018, at 00:23, Andres Freund wrote:
> On 2018-04-06 02:28:17 +0200, Daniel Gustafsson wrote:
>> Applying this makes the _cancel test pass, moving the failure instead to the
>> following _enable test (which matches what coypu and mylodon are seeing).
>
> FWIW,
On Fri, Apr 6, 2018 at 6:59 PM, Jonathan S. Katz wrote:
> Best of luck to everyone over the next 24hrs!
I think that's the wrong sentiment, honestly. I think we have too
many committers relying way too much on luck already.
--
Robert Haas
EnterpriseDB:
On 7 April 2018 at 12:43, David Rowley wrote:
> On 7 April 2018 at 12:35, Amit Langote wrote:
>> So this same failure occurs on (noting the architecture):
>>
>> Seems to be due to that the hashing function used in partitioning
>> gives
On 7 April 2018 at 13:50, Amit Langote wrote:
> On Sat, Apr 7, 2018 at 10:31 AM, David Rowley
>> I looked at all the regression test diffs for each of the servers you
>> mentioned and I verified that the diffs match on each of the 7
>> servers.
>>
>> Maybe the best
On 7 April 2018 at 12:03, David Rowley wrote:
> Continuing to read 0003 and 0004 now.
0003:
1. "setup" -> "set"
/* If run-time partition pruning is enabled, then setup that up now */
2. We should be able to get rid of as_noopscan and just have another
special
On 7 April 2018 at 13:31, David Rowley wrote:
> Maybe the best solution is to pull those tests out of
> partition_prune.sql then create partition_prune_hash and just have an
> alternative .out file with the partitions which match on bigendian
> machines.
Here's 1 of
On Fri, Apr 6, 2018 at 10:00 PM, Peter Eisentraut
wrote:
> On 4/3/18 18:05, Andrew Dunstan wrote:
>> Currently we seem to have only two machines doing the cross-version
>> upgrade checks, which might make it easier to rearrange anything if
>> necessary.
>
> I
On Fri, Apr 6, 2018 at 4:49 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> On Wed, Apr 4, 2018 at 1:03 PM, Alvaro Herrera
>> wrote:
>> > Foreign keys on partitioned tables
>> >
>> > Author: Álvaro Herrera
>> > Discussion:
>> >
On Fri, Apr 6, 2018 at 8:24 AM, Alvaro Herrera wrote:
> I don't actually like very much the idea of putting all this code in
> optimizer/util. This morning it occurred to me that we should create a new
> src/backend/partitioning/ (and a src/include/partitioning/ to go
> On Apr 6, 2018, at 6:57 PM, Robert Haas wrote:
>
> On Fri, Apr 6, 2018 at 6:54 PM, Jonathan S. Katz wrote:
>> Yes. It follows the format from the previous ones, i.e:
>>
>>
Hi,
As Daniel pointed out in:
https://postgr.es/m/fb948276-7b32-4b77-83e6-d00167f8e...@yesql.se the
pg_atomic_flag fallback implementation is broken. That has gone
unnoticed because the fallback implementation wasn't testable until now:
- /* ---
-* Can't run the test under the semaphore
On Fri, Apr 6, 2018 at 5:25 PM, Claudio Freire wrote:
> On Fri, Apr 6, 2018 at 10:39 AM, Heikki Linnakangas wrote:
>> On 06/04/18 01:59, Claudio Freire wrote:
>>>
>>> The iteration interface, however, seems quite specific for the use
>>> case of
On 2018-04-07 14:42:53 +1200, David Rowley wrote:
> On 7 April 2018 at 13:31, David Rowley wrote:
> > Maybe the best solution is to pull those tests out of
> > partition_prune.sql then create partition_prune_hash and just have an
> > alternative .out file with the
On 2018-04-07 15:04:37 +1200, David Rowley wrote:
> On 7 April 2018 at 15:00, Andres Freund wrote:
> > On 2018-04-07 14:42:53 +1200, David Rowley wrote:
> >> On 7 April 2018 at 13:31, David Rowley
> >> wrote:
> >> > Maybe the best solution is to
On 7 April 2018 at 15:18, Andres Freund wrote:
> I've pushed the two patches (collapsed). Trying to get the BF green-ish
> again...
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Hi,
On 2018-04-06 23:41:22 -0400, Tom Lane wrote:
> David Rowley writes:
> > Sounds like you're saying that if we have too many alternative files
> > then there's a chance that one could pass by luck.
>
> Yeah, exactly: it passed, but did it pass for the right
On Sat, Apr 7, 2018 at 11:26 AM, David Rowley
wrote:
> Everything else looks fine from my point of view.
Me too, although I still think having struct names PartitionPruning
and PartitionRelPruning is going to be a bit confusing. We should
think about naming the
On 7 April 2018 at 16:26, Amit Langote wrote:
> Maybe, PartitionPruneState, because it parallels the
> PartitionPruneInfo that comes from the planner for every partitioned
> table in the tree.
I like that.
--
David Rowley http://www.2ndQuadrant.com/
On 7 April 2018 at 15:14, Ashutosh Bapat
wrote:
> On Sat, Apr 7, 2018 at 8:37 AM, David Rowley
>> Why is writing tests that produce the same output required?
>>
>> We have many tests with alternative outputs. Look in
>> src/tests/regress/expected for files
On 2018-04-07 13:26:51 +0900, Amit Langote wrote:
> On Sat, Apr 7, 2018 at 11:26 AM, David Rowley
> wrote:
> > Everything else looks fine from my point of view.
>
> Me too, although I still think having struct names PartitionPruning
> and PartitionRelPruning is
On Sat, Apr 7, 2018 at 1:58 PM, David Rowley
wrote:
> Probably if we need to explain more there about how pruning works then
> it should be a fixup patch to 9fdb675fc, no?
Yes, I just replied and working on a patch.
Thanks,
Amit
On 2018-04-07 16:58:01 +1200, David Rowley wrote:
> On 7 April 2018 at 16:31, Andres Freund wrote:
> > I've not followed this thread/feature at all, but I don't find the
> > comments atop partprune.c even remotely sufficient. Unless there's an
> > README hidden or such hidden
Fabien,
* Fabien COELHO (fabien.coe...@mines-paristech.fr) wrote:
> Patch v16 is a rebase.
Here's that review.
> diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
> index d52d324..203b6bc 100644
> --- a/doc/src/sgml/ref/pgbench.sgml
> +++ b/doc/src/sgml/ref/pgbench.sgml
On Sat, Apr 7, 2018 at 8:37 AM, David Rowley
wrote:
> On 7 April 2018 at 15:03, Ashutosh Bapat
> wrote:
>> On Sat, Apr 7, 2018 at 7:25 AM, David Rowley
>>> The only alternative would be to change all the hash functions so that
>>>
On 7 April 2018 at 15:41, Tom Lane wrote:
> I'm also wondering how come we had hash partitioning before and
> did not have this sort of problem. Is it just that we added a
> new test that's more sensitive to the details of the hashing
> (if so, could it be made less so)? Or
David Rowley writes:
> Sounds like you're saying that if we have too many alternative files
> then there's a chance that one could pass by luck.
Yeah, exactly: it passed, but did it pass for the right reason?
If there's just two expected-files, it's likely not a
On 7 April 2018 at 15:18, Andres Freund wrote:
> I've pushed the two patches (collapsed). Trying to get the BF green-ish
> again...
termite has now gone green.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
1 - 100 of 196 matches
Mail list logo