Re: [HACKERS] Runtime Partition Pruning

On Sat, Apr 7, 2018 at 1:58 PM, Amit Langote wrote: > On Sat, Apr 7, 2018 at 1:31 PM, 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

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

On Apr 7, 2018, at 12:49 AM, Tom Lane wrote: > 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

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] 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 Sat, Apr 7, 2018 at 1:31 PM, Andres Freund wrote: > 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

Re: [HACKERS] Runtime Partition Pruning

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 somewhere? There's not a README file. The comments for

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

Amit Langote writes: > Given that the difference only appeared on animals that David pointed > out have big-endian architecture, it seems we'd only need two output > files. Dunno, I'm wondering whether 32 vs 64 bit will make a difference.

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 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] path toward faster partition pruning

On Sat, Apr 7, 2018 at 1:09 PM, Andres Freund wrote: > Hi, > > On 2018-04-07 15:49:54 +1200, David Rowley wrote: >> Right, I suggest we wait and see if all members go green again as a >> result of 40e42e1024c, and if they're happy then we could maybe leave >> it as is with the

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 &

Re: [HACKERS] path toward faster partition pruning

On 7 April 2018 at 16:09, Andres Freund wrote: > I've also attempted to fix rhinoceros's failure I remarked upon a couple > hours ago in > https://postgr.es/m/20180406210330.wmqw42wqgiick...@alap3.anarazel.de Oh, thanks! I had just been looking at that too... -- David

Re: [HACKERS] path toward faster partition pruning

On 7 April 2018 at 09:03, Andres Freund wrote: > There's also > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=rhinoceros=2018-04-06%2020%3A45%3A01 > *** > /opt/src/pgsql-git/build-farm-root/HEAD/pgsql.build/contrib/sepgsql/expected/misc.out >2018-02-20

Re: [HACKERS] path toward faster partition pruning

Hi, On 2018-04-07 15:49:54 +1200, David Rowley wrote: > Right, I suggest we wait and see if all members go green again as a > result of 40e42e1024c, and if they're happy then we could maybe leave > it as is with the 2 alternatives output files. At least the first previously borked animal came

Re: [HACKERS] path toward faster partition pruning

On 7 April 2018 at 15:41, 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

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] 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 Sat, Apr 7, 2018 at 8:55 AM, David Rowley wrote: > 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

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Hi Tom, All, On 2018-04-06 14:19:02 +0530, amul sul wrote: > Thanks for the reminder -- fixed in the attached version. Tom, this seems to be the best approach for fixing the visibility issues around this. I've spent a good chunk of time looking at corruption issues like the ones you feared (see

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

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] 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: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 >> they normalise their endianness. It does not sound like something that >> will perform very

Re: [HACKERS] path toward faster partition pruning

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 pull those tests out of >> > partition_prune.sql then create

Re: [HACKERS] path toward faster partition pruning

On Sat, Apr 7, 2018 at 7:25 AM, David Rowley wrote: > 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

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

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

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

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

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

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

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

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

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

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

  1   2   >