Re: Online enabling of checksums

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

Documentation for bootstrap data conversion

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

Re: Online enabling of checksums

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

Re: PATCH: Configurable file mode mask

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

Re: Add support for printing/reading MergeAction nodes

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

Re: WIP: a way forward on bootstrap data

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',

Re: [HACKERS] path toward faster partition pruning

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

Re: pgsql: Validate page level checksums in base backups

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

Re: BUG #14941: Vacuum crashes

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

Re: pgsql: Foreign keys on partitioned tables

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 >

The buildfarm is in a pretty bad way, folks

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

Re: The buildfarm is in a pretty bad way, folks

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 > >

Re: Online enabling of checksums

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.

Re: [FEATURE PATCH] pg_stat_statements with plans (v02)

> 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

Re: [HACKERS] path toward faster partition pruning

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 >

Re: Online enabling of checksums

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

Re: pgsql: New files for MERGE

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

Re: Add default role 'pg_access_server_files'

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

Re: The buildfarm is in a pretty bad way, folks

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,

Re: The buildfarm is in a pretty bad way, folks

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

Re: [HACKERS] logical decoding of two-phase transactions

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

Re: Vacuum: allow usage of more than 1GB of work mem

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

Re: Add support for printing/reading MergeAction nodes

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

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

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

Re: Documentation for bootstrap data conversion

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

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

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)) +

Re: Online enabling of checksums

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.

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

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

Re: Excessive PostmasterIsAlive calls slow down WAL redo

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

Re: [HACKERS] pgbench - allow to store select results into variables

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

Re: pgsql: New files for MERGE

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 >

Re: PATCH: Configurable file mode mask

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.

Re: Documentation for bootstrap data conversion

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

Re: [HACKERS] [PATCH] Incremental sort

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

Re: The buildfarm is in a pretty bad way, folks

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

Re: The buildfarm is in a pretty bad way, folks

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

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

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,

Re: PATCH: Configurable file mode mask

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

Re: PostgreSQL 11 Release Management Team & Feature Freeze

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 >

Re: Online enabling of checksums

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

Re: [PATCH] Update README for Resource Owners

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

Re: WIP: Covering + unique indexes.

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

Re: PATCH: Configurable file mode mask

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

Re: The buildfarm is in a pretty bad way, folks

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 <<

Re: Online enabling of checksums

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

Re: PostgreSQL 11 Release Management Team & Feature Freeze

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

Re: Online enabling of checksums

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

Re: Online enabling of checksums

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

Re: Online enabling of checksums

> 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

Re: [HACKERS] Runtime Partition Pruning

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

Re: [PATCH] Update README for Resource Owners

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

Re: [HACKERS] Runtime Partition Pruning

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

Re: src/backend/partitioning

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

Re: [HACKERS] Add support for tuple routing to foreign partitions

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 >

Re: Online enabling of checksums

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

Re: [HACKERS] path toward faster partition pruning

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

Re: Parallel index creation does not properly cleanup after error

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,

Re: Parallel index creation does not properly cleanup after error

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

Re: Online enabling of checksums

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

Re: PATCH: Configurable file mode mask

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,

Re: [HACKERS] Runtime Partition Pruning

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

Re: Online enabling of checksums

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

Re: PostgreSQL 11 Release Management Team & Feature Freeze

> 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

Re: Online enabling of checksums

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

Re: Online enabling of checksums

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); +

Re: [PATCH] Update README for Resource Owners

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

Re: [HACKERS] path toward faster partition pruning

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

[PATCH] Update README for Resource Owners

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

Re: [HACKERS] path toward faster partition pruning

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: >

Re: [HACKERS] path toward faster partition pruning

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: >

Re: The buildfarm is in a pretty bad way, folks

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 >

Re: Online enabling of checksums

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,

Re: The buildfarm is in a pretty bad way, folks

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

Re: Online enabling of checksums

> 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,

Re: PostgreSQL 11 Release Management Team & Feature Freeze

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:

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] Runtime Partition Pruning

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] logical decoding of two-phase transactions

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

Re: pgsql: Foreign keys on partitioned tables

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: >> >

Re: [HACKERS] path toward faster partition pruning

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

Re: PostgreSQL 11 Release Management Team & Feature Freeze

> 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: >> >>

Bring atomic flag fallback up to snuff

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

Re: Vacuum: allow usage of more than 1GB of work mem

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] Runtime Partition Pruning

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

Re: [HACKERS] Runtime Partition Pruning

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/

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] Runtime Partition Pruning

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

Re: [HACKERS] Runtime Partition Pruning

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

Re: [HACKERS] Runtime Partition Pruning

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

Re: [HACKERS] pgbench - allow to store select results into variables

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

Re: [HACKERS] path toward faster partition pruning

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 >>>

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] path toward faster partition pruning

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

Re: [HACKERS] path toward faster partition pruning

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   2   >