Re: How can we submit code patches that implement our (pending) patents?

On 07/25/18 01:56, Nico Williams wrote: > Wrong. With patents the important thing is not to know about them when > you implement -- if you come up with the same idea by accident (which, > of course, is obviously entirely possible) then you are not subject to > trebble damages. Even if the damage

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 24 Jul 2018, at 22:57, Daniel Gustafsson wrote: > >> On 6 Jul 2018, at 02:18, Thomas Munro wrote: >> >> On Fri, Jun 15, 2018 at 9:56 AM, Daniel Gustafsson wrote: >>> attached >> >> Hi Daniel, >> >> 6118 --select pg_cancel_backend(pg_backend_pid(), 'it brings on many >> changes'); >> 6

Re: How can we submit code patches that implement our (pending) patents?

On Wed, Jul 25, 2018 at 12:56 PM, Nico Williams wrote: > On Tue, Jul 24, 2018 at 06:29:37PM -0400, Isaac Morland wrote: > > On 24 July 2018 at 18:17, Nico Williams wrote: > > > Note that it's OK to *accidentally* implement patented algorithms as > > > long as the author of the contribution didn'

Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian

On 2018/07/21 0:17, David Rowley wrote: > On 20 July 2018 at 21:44, Amit Langote wrote: >> But I don't think the result of make_partition_pruneinfo itself has to be >> List of PartitionedRelPruneInfo nested under PartitionPruneInfo. I gather >> that each PartitionPruneInfo corresponds to each roo

Re: ToDo: show size of partitioned table

Hi Pavel. On 2018/07/23 20:46, Pavel Stehule wrote: > Hi > > I am sending a prototype of patch. Now, it calculates size of partitioned > tables with recursive query. When any more simple method will be possible, > the size calculation will be changed. > > postgres=# \dt+ >

Re: ToDo: show size of partitioned table

2018-07-25 11:09 GMT+02:00 Amit Langote : > Hi Pavel. > > On 2018/07/23 20:46, Pavel Stehule wrote: > > Hi > > > > I am sending a prototype of patch. Now, it calculates size of partitioned > > tables with recursive query. When any more simple method will be > possible, > > the size calculation wil

Re: Online enabling of checksums

> On 24 Jul 2018, at 11:05, Sergei Kornilov wrote: > > The following review has been posted through the commitfest application: > make installcheck-world: tested, failed > Implements feature: not tested > Spec compliant: not tested > Documentation:tested, failed > >

Re: Locking B-tree leafs immediately in exclusive mode

On 13 July 2018 at 03:14, Imai, Yoshikazu wrote: > On Mon, July 9, 2018 at 5:25 PM, Simon Riggs wrote: >> Please can you check insertion with the index on 2 keys >> 1st key has 10,000 values >> 2nd key has monotonically increasing value from last 1st key value >> >> So each session picks one 1st k

Re: Online enabling of checksums

Hello Thank you for update! I did only quick test now: patch applied and build clean. But i have reproducible error during check-world: > t/001_standby_checksum.pl .. 6/10 > # Failed test 'ensure checksums are enabled on standby' > # at t/001_standby_checksum.pl line 84. > # got: 'i

Re: Global snapshots

Hello, I have looked through the patches and found them pretty accurate. I'd fixed a lot of small issues here and there; updated patchset is attached. But first, some high-level notes: * I agree that it would be cool to implement functionality like current "snapshot too old": that is, abort t

Fwd: Re[2]: Alter index rename concurrently to

Понедельник, 23 июля 2018, 18:06 +03:00 от Peter Eisentraut < peter.eisentr...@2ndquadrant.com >: > >You appear to be saying that you think that renaming an index >concurrently is not safe No, I didn't say it about renaming indexes. I tried to say that it does not make sense exactly to rename a ta

Re: "WIP: Data at rest encryption" patch and, 2 phase commit.

Toshi Harada wrote: > Hi. > > I applied the patch "WIP: Data at rest encryption" to PostgreSQL 11 - beta 2 > and I'm working on it. > > When this patch is applied, the following problem occurs. > > * An error occurs when CHECKPOINT is executed during two-phase commit. > * After an error occur

Re: Locking B-tree leafs immediately in exclusive mode

Hi! On Tue, Jul 10, 2018 at 4:39 PM 今井 良一 wrote: > On 2018/07/10 20:36, Alexander Korotkov wrote: > > Thank you for the experiments! It seems that there is real regression > > here... BTW, which script were you using in this benchmark: > > script_unordered.sql or script_duplicated.sql? > > Sorr

Re: Locking B-tree leafs immediately in exclusive mode

Hi! On Wed, Jul 25, 2018 at 1:19 PM Simon Riggs wrote: > On 13 July 2018 at 03:14, Imai, Yoshikazu > wrote: > > From an attached graph("some_contention_points_on_leaf_nodes.png"), as > > contention points dispersed, we can see that TPS is increased and TPS > > difference between master and pa

Re: Locking B-tree leafs immediately in exclusive mode

On Wed, Jul 25, 2018 at 5:54 AM Imai, Yoshikazu wrote: > On Mon, July 9, 2018 at 3:19 AM, Imai, Yoshikazu wrote: > > I'm planning to do code review and send it in the next mail. > > Sorry for delaying the code review. > > I did the code review, and I think there are no logical wrongs > with B-Tree

Re: LLVM jit and matview

> On Wed, 25 Jul 2018 at 07:49, Michael Paquier wrote: > > On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote: > > FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll > > try older ones, as soon as they finish rebuilding. But perhaps you could > > re-verify that this

Using test_ddl_deparse as an extension

I am interested in using the exact functionality in test_ddl_deparse which provides the sub command types for alter table statements. I would prefer to leverage this code which has already been vetted by the community, and also not just duplicate this code myself, or package it up myself. It woul

Optimizer misses big in 10.4 with BRIN index

Hi, Before spamming the list with reproduction examples I want to make sure the issue isn't already known. Moving to 10.4 from 9.2 (AWS RDS but repro on local laptop as well) we've discovered that an optimizer prefers a seq scan to fully analyzed consistent BRIN index, ending up with a query

Re: [HACKERS] WAL logging problem in 9.4.3?

On Wed, Jul 18, 2018 at 05:58:16PM +0300, Heikki Linnakangas wrote: > I'd suggest that we continue based on the patch that Kyotaro posted at > https://www.postgresql.org/message-id/20180330.100646.86008470.horiguchi.kyotaro%40lab.ntt.co.jp. Whatever happens here, perhaps one way to move on would b

Re: Explain buffers wrong counter with parallel plans

> On Jul 7, 2018, at 12:03 AM, Amit Kapila wrote: > > On Sat, Jul 7, 2018 at 7:45 AM, Amit Kapila > wrote: >> On Sat, Jul 7, 2018 at 12:44 AM, Robert Haas wrote: >>> On Fri, Jul 6, 2018 at 9:44 AM, Amit Kapila wrote: I have tried this idea, but it doesn't

Re: Missing pg_control crashes postmaster

On 7/23/18 7:00 PM, Tom Lane wrote: Brian Faherty writes: > There does not really seem to be a need for this behavior as all the information postgres needs is in memory at this point. I propose with a patch to just recreate pg_control on updates if it does not exist. I would vote to reject a

Re: Missing pg_control crashes postmaster

On July 25, 2018 7:18:30 AM PDT, David Steele wrote: >On 7/23/18 7:00 PM, Tom Lane wrote: >> Brian Faherty writes: > > >>> There does not really seem to be a need for this behavior as all the >>> information postgres needs is in memory at this point. I propose >with >>> a patch to just recreat

Re: Missing pg_control crashes postmaster

On 7/25/18 10:37 AM, Andres Freund wrote: On July 25, 2018 7:18:30 AM PDT, David Steele wrote: It seems like an easy win if we can find a safe way to do it, though I admit that this is only a benefit in corner cases. What would we win here? Which scenario that's not contrived would be less b

Re: How can we submit code patches that implement our (pending) patents?

On Tue, Jul 24, 2018 at 06:13:37AM +, Tsunakawa, Takayuki wrote: > From: Bruce Momjian [mailto:br...@momjian.us] > > On Tue, Jul 10, 2018 at 08:20:53AM +, Tsunakawa, Takayuki wrote: > > > Yes, that's one unfortunate future, which I don't want to happen > > > of course. I believe PostgreSQL

Re: Missing pg_control crashes postmaster

Hi, On 2018-07-25 10:52:08 -0400, David Steele wrote: > On 7/25/18 10:37 AM, Andres Freund wrote: > > On July 25, 2018 7:18:30 AM PDT, David Steele wrote: > > > > > > It seems like an easy win if we can find a safe way to do it, though I > > > admit that this is only a benefit in corner cases. >

Re: Early WIP/PoC for inlining CTEs

> "David" == David Fetter writes: David> Please find attached a version rebased atop 167075be3ab1547e18 David> with what I believe are appropriate changes to regression test David> output. The other changes to the regression tests output are David> somewhat puzzling, as they change the ac

Re: Missing pg_control crashes postmaster

On 7/25/18 11:09 AM, Andres Freund wrote: On 2018-07-25 10:52:08 -0400, David Steele wrote: I favor the contrived scenario that helps preserve the current cluster instead of a hypothetical newly init'd one. I also don't think that users deleting files out of a cluster is all that contrived.

Re: How can we submit code patches that implement our (pending) patents?

On Wed, Jul 25, 2018 at 03:06:22AM -0400, Chapman Flack wrote: > On 07/25/18 01:56, Nico Williams wrote: > > > Wrong. With patents the important thing is not to know about them when > > you implement -- if you come up with the same idea by accident (which, > > of course, is obviously entirely pos

Re: Missing pg_control crashes postmaster

David Steele writes: > On 7/25/18 10:37 AM, Andres Freund wrote: >> What would we win here? Which scenario that's not contrived would be less >> bad due to the proposed change. This seems complexity for it's own sake. > I favor the contrived scenario that helps preserve the current cluster > i

Re: How can we submit code patches that implement our (pending) patents?

On Wed, Jul 25, 2018 at 02:48:01PM +0700, Benjamin Scherrey wrote: > If you violate a patent, knowingly or otherwise, you are subject to > penalties (perhaps not treble but still penalties) and will have to remove > the offending code unless a deal is reached with the patent holder. Unless you do

Re: Missing pg_control crashes postmaster

Hi, On 2018-07-25 11:19:49 -0400, David Steele wrote: > On 7/25/18 11:09 AM, Andres Freund wrote: > > On 2018-07-25 10:52:08 -0400, David Steele wrote: > > The problem is that that'll just hide the issue for a bit longer, while > > continuing (due to the O_CREAT we'll not PANIC anymore). Which ca

Re: Early WIP/PoC for inlining CTEs

On Wed, Jul 25, 2018 at 07:42:37AM +0200, David Fetter wrote: > Please find attached a version rebased atop 167075be3ab1547e18 with > what I believe are appropriate changes to regression test output. The > other changes to the regression tests output are somewhat puzzling, as > they change the act

Re: Missing pg_control crashes postmaster

David Steele writes: > On 7/25/18 11:09 AM, Andres Freund wrote: >> The problem is that that'll just hide the issue for a bit longer, while >> continuing (due to the O_CREAT we'll not PANIC anymore). Which can lead >> to a lot of followup issues, like checkpoints removing old WAL that'd >> have b

Re: Missing pg_control crashes postmaster

On 7/25/18 11:26 AM, Andres Freund wrote: On 2018-07-25 11:19:49 -0400, David Steele wrote: If one wanted to improve recoverability in scenarios like this, there'd be actually useful things like adding the option to extract control files, FPIs, clog contents from the WAL with pg_waldump. I thi

Re: Missing pg_control crashes postmaster

On 7/25/18 11:33 AM, Tom Lane wrote: David Steele writes: On 7/25/18 11:09 AM, Andres Freund wrote: The problem is that that'll just hide the issue for a bit longer, while continuing (due to the O_CREAT we'll not PANIC anymore). Which can lead to a lot of followup issues, like checkpoints rem

Re: LLVM jit and matview

On 2018-07-25 14:59:20 +0200, Dmitry Dolgov wrote: > > On Wed, 25 Jul 2018 at 07:49, Michael Paquier wrote: > > > > On Tue, Jul 24, 2018 at 07:49:56PM -0700, Andres Freund wrote: > > > FWIW, this doesn't crash for me, using a trunk checkout for LLVM. I'll > > > try older ones, as soon as they fini

Re: How can we submit code patches that implement our (pending) patents?

On 07/25/2018 11:25 AM, Nico Williams wrote: > I don't understand why it's not obvious that one can unknowingly and > accidentally re-invent someone else's idea. It's perfectly obvious. It's the chief reason the whole topic of software patents has been deeply controversial for so long. You seem

Re: How can we submit code patches that implement our (pending) patents?

On 2018-07-25 11:45:58 -0400, Chapman Flack wrote: > On 07/25/2018 11:25 AM, Nico Williams wrote: > > > I don't understand why it's not obvious that one can unknowingly and > > accidentally re-invent someone else's idea. > > It's perfectly obvious. It's the chief reason the whole topic > of softw

Re: Early WIP/PoC for inlining CTEs

> "Nico" == Nico Williams writes: Nico> It is possible to add a keyword for this purpose in the WITH syntax: Nico> WITH VIEW (...) AS a_view The existing (and standard) syntax is WITH ctename AS (query). Syntaxes that have been suggested for explicitly controlling the materializati

"WIP: Data at rest encryption" patch and, 2 phase commit.

Hi. I applied the patch "WIP: Data at rest encryption" to PostgreSQL 11 - beta 2 and I'm working on it. When this patch is applied, the following problem occurs. * An error occurs when CHECKPOINT is executed during two-phase commit. * After an error occurs, if you stop PostgreSQL, it will never

Re: How can we submit code patches that implement our (pending) patents?

On 2018-Jul-07, David Fetter composed: > If they have no plans to practice any exclusive rights, our standard thing > process where individuals submit things and consent to have us name them > with the PGDG copyright and distribute them under TPL would be the > most straightforward approach

Re: Using test_ddl_deparse as an extension

On 2018-Jul-25, Jeremy Finzel wrote: > I am interested in using the exact functionality in test_ddl_deparse which > provides the sub command types for alter table statements. I would prefer > to leverage this code which has already been vetted by the community, and > also not just duplicate this

Re: no partition pruning when partitioning using array type

On 2018-Jul-12, Amit Langote wrote: > On 2018/07/12 2:33, Alvaro Herrera wrote: > > Yeah, any domain constraints added before won't be a problem. Another > > angle on this problem is to verify partition bounds against the domain > > constraint being added; if they all pass, there's no reason to

Re: Optimizer misses big in 10.4 with BRIN index

Hi, On 07/25/2018 03:58 PM, Arcadiy Ivanov wrote: ->  Bitmap Index Scan on tradedate_idx (cost=0.00..231.96 rows=3377106 width=0) (actual time=4.500..4.500 rows=23040 loops=1)    Index Cond: data_table.data ->> 'tradeDate'::text))::numeric >=

Re: Allow COPY's 'text' format to output a header

On 4 July 2018 at 22:44, Simon Muller  wrote:I noticed through the patch tester link at http://commitfest.cputube.org/ that my patch caused a file_fdw test to fail (since I previously tested only with "make check" and not with "make check-world").This v2 patch should fix that.T

Re: Allow COPY's 'text' format to output a header

On Wed, Jul 25, 2018 at 1:24 PM, Cynthia Shang wrote: > With regards to #2, the copy.source tests are for things requiring > replacement when running the tests. Given that these copy tests do not, I > have moved the current last set of copy tests to the copy2.sql file and have > provided an attac

Re: How can we submit code patches that implement our (pending) patents?

On Wed, Jul 25, 2018 at 11:45:58AM -0400, Chapman Flack wrote: > On 07/25/2018 11:25 AM, Nico Williams wrote: > > > I don't understand why it's not obvious that one can unknowingly and > > accidentally re-invent someone else's idea. > > It's perfectly obvious. It's the chief reason the whole topi

Re: Early WIP/PoC for inlining CTEs

On Wed, Jul 25, 2018 at 05:08:43PM +0100, Andrew Gierth wrote: > Nico> It is possible to add a keyword for this purpose in the WITH syntax: > > Nico> WITH VIEW (...) AS a_view > > The existing (and standard) syntax is WITH ctename AS (query). Oy, I flubbed that up. > Syntaxes that have

Re: Early WIP/PoC for inlining CTEs

On Tue, Jul 24, 2018 at 07:57:49PM -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-07-24 19:49:19 -0400, Tom Lane wrote: > >> However, a singly-referenced SELECT CTE could reasonably be treated as > >> equivalent to a sub-select-in-FROM, and then you would have the same > >> mechanisms

Re: JIT breaks PostGIS

Re: Darafei "Komяpa" Praliaskouski 2018-07-23 > > It looks to me like it's a LLVM issue, specifically > > https://bugs.llvm.org/show_bug.cgi?id=34424 > > fixed in LLVM 5+. > > > > Thank you for your investigation. Thanks! > > It'll only be an issue for extensions that throw c++ style exception

Re: JIT breaks PostGIS

Hi, On 2018-07-25 21:05:33 +0200, Christoph Berg wrote: > > > It'll only be an issue for extensions that throw c++ style exceptions. I > > > don't think that rises to the level of disallowing any LLVM version < > > > 5.0. I suggest postgis adds an error check to its buildprocess that > > > refuses

Re: Early WIP/PoC for inlining CTEs

On Wed, Jul 25, 2018 at 04:18:42PM +0100, Andrew Gierth wrote: > > "David" == David Fetter writes: > > David> Please find attached a version rebased atop 167075be3ab1547e18 > David> with what I believe are appropriate changes to regression test > David> output. The other changes to the reg

Re: JIT breaks PostGIS

Re: Andres Freund 2018-07-25 <20180725191143.sietxlbfehv24...@alap3.anarazel.de> > I haven't investigated the details here. It certainly would be possible > to have the _PG_init() of postgis's so force JIT to be off, and emit a > warning. Isn't that too late, if postgis.so gets loaded by a query

Re: JIT breaks PostGIS

Hi, On 2018-07-25 21:39:26 +0200, Christoph Berg wrote: > Re: Andres Freund 2018-07-25 > <20180725191143.sietxlbfehv24...@alap3.anarazel.de> > > I haven't investigated the details here. It certainly would be possible > > to have the _PG_init() of postgis's so force JIT to be off, and emit a > >

Re: JIT breaks PostGIS

Re: Andres Freund 2018-07-25 <20180725195037.jmykfzfporf6a...@alap3.anarazel.de> > > Different question, the other way round, is there a way to know that > > all files needed to inline a query/extension are there? How does the > > JIT machinery determine it can (try to) compile things? (That's > >

Re: JIT breaks PostGIS

Hi, On 2018-07-25 21:59:32 +0200, Christoph Berg wrote: > Re: Andres Freund 2018-07-25 > <20180725195037.jmykfzfporf6a...@alap3.anarazel.de> > > The way inlining works is that, when referencing a function, the bitcode > > summary file corresponding to it (either postgres.index.bc if builtin or >

PartitionDispatch's partdesc field

I noticed today that in the PartitionDispatch structure, the partdesc field is set but not used. So we could remove it. See attached pd-partdesc-remove.patch. If we want to go this route, I suggest doing a slightly more thorough removal and getting rid of the key field as well. See attached pd-

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

On Tue, Jul 24, 2018 at 7:51 AM, Etsuro Fujita wrote: >> Isn't that assumption fundamental to your whole approach? > > I don't think so. What I mean here is: currently the subplan would be a > scan/join node, but in future we might have eg, a Sort node atop the > scan/join node, so it would be be

BLOB / CLOB support in PostgreSQL

Hi, According to Pgjdbc GitHub statistics, the most popular page is https://github.com/pgjdbc/pgjdbc/issues/1102 which is "org.postgresql.jdbc.PgConnection.createClob() is not yet implemented" issue (1600 visits from 1400 unique visitors per a fortnight). There are workarounds to silence the err

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

Robert Haas writes: > On Tue, Jul 24, 2018 at 7:51 AM, Etsuro Fujita > wrote: >> I'm not sure that's a good idea, because I think we have a trade-off >> relation; the more we make create_plan simple, the more we need to make >> earlier states of the planner complicated. >> >> And it looks to me

Re: Loaded footgun open_datasync on Windows

On Thu, Jun 21, 2018 at 2:06 AM, Laurenz Albe wrote: > How about checking what the buildfarm thinks about the attached? Hi Laurenz, It looks like initdb is failing with this patch: https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.6732 Unfortunately cfbot is not clever enou

Re: LLVM jit and matview

Hi, On 2018-07-25 08:41:29 -0700, Andres Freund wrote: > Oh, interesting. It only crashes when compiling LLVM without LLVM's > asserts enabled, even when using exactly the same LLVM checkout for both > builds. No idea what that's about, yet. Oh, well, this took me longer than it should have. The

Re: Allow COPY's 'text' format to output a header

On 25 July 2018 at 19:24, Cynthia Shang wrote: > > I've reviewed this patch and feel this patch addresses the original ask. I > tested it manually trying to break it and, as mentioned previously, it's > behavior is the same as the CSV copy with regards to it's shortcomings. > However, I feel > 1)

Re: LLVM jit and matview

On 2018-Jul-25, Andres Freund wrote: > The fix is easy, releasing the JIT context should just happen in > FreeExecutorState(). Only thing is that that function has the following > comment in the header: > * Note: this is not responsible for releasing non-memory resources, > * such as open relati

Re: LLVM jit and matview

On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote: > On 2018-Jul-25, Andres Freund wrote: > > > The fix is easy, releasing the JIT context should just happen in > > FreeExecutorState(). Only thing is that that function has the following > > comment in the header: > > * Note: this is not responsi

Re: LLVM jit and matview

On 2018-Jul-25, Andres Freund wrote: > On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote: > > On 2018-Jul-25, Andres Freund wrote: > > But what would be the advantage of avoiding the context release inside > > FreeExecutorState? It seems pretty appropriate to me to do it there. > > You could ar

Re: Scariest patch tournament, PostgreSQL 11 edition

On Mon, Jun 25, 2018 at 3:52 PM, Alvaro Herrera wrote: > One month of beta testing has flown by, and enough bugs have already > been reported that your view of what patches are scariest might have > matured. You still have a few days before we close the contest at the > end of the month. Let us

Re: LLVM jit and matview

Andres Freund writes: > On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote: >> But what would be the advantage of avoiding the context release inside >> FreeExecutorState? It seems pretty appropriate to me to do it there. >> You could argue that the JIT context is definitely part of the estate >>

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

Hi, On 2018-07-20 13:24:50 -0700, Andres Freund wrote: > On 2018-07-20 16:15:14 -0400, Tom Lane wrote: > > We've seen several occurrences of $subject in the buildfarm in the past > > month or so. Scraping the logs, I find > > > > coypu| 2018-06-14 21:17:49 | HEAD | Check | 2018-06-

Re: LLVM jit and matview

On 2018-07-25 18:59:51 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-07-25 18:11:13 -0400, Alvaro Herrera wrote: > >> But what would be the advantage of avoiding the context release inside > >> FreeExecutorState? It seems pretty appropriate to me to do it there. > >> You could argue

Re: Alter index rename concurrently to

> > You appear to be saying that you think that renaming an index > concurrently is not safe. In that case, this patch should be rejected. > However, I don't think it necessarily is unsafe. What we need is some > reasoning about the impact, not a bunch of different options that we > don't underst

Re: [Proposal] Add accumulated statistics for wait event

On Tue, Jul 24, 2018 at 04:23:03PM +, Phil Florent wrote: > It loses non meaningful details and it's in fact a good point. In this > example, sampling will definitely find the cause and won't cost > resources. The higher the sampling frequency, the more details you get, with the most load on t

Re: no partition pruning when partitioning using array type

On 2018/07/26 1:41, Alvaro Herrera wrote: > On 2018-Jul-12, Amit Langote wrote: >> On 2018/07/12 2:33, Alvaro Herrera wrote: >>> Yeah, any domain constraints added before won't be a problem. Another >>> angle on this problem is to verify partition bounds against the domain >>> constraint being add

Re: Making "COPY partitioned_table FROM" faster

Hi Melanie, Many thanks for looking over this again. On 25 July 2018 at 03:32, Melanie Plageman wrote: > One small additional typo I noticed: > > In the patched code on line 2555, there appears to be a typo: > /* ... > * inserting into and act differently if the tuples that have already > * b

Re: Explain buffers wrong counter with parallel plans

On Wed, Jul 25, 2018 at 7:42 PM, Jonathan S. Katz wrote: > > On Jul 7, 2018, at 12:03 AM, Amit Kapila wrote: > > I tried running the below on both 11beta2 and HEAD with the patch > applied: > > CREATE UNLOGGED TABLE t1 (c1 int); > INSERT INTO t1 SELECT generate_series(1,1); > /** restart

Re: Making "COPY partitioned_table FROM" faster

On 25 July 2018 at 04:37, Simon Riggs wrote: > I don't see any need here for another GUC, nor even a command option. > The user has already indicated their use case to us: I agree. > We know that the common case for RANGE partitioned tables is to load > into the one current partition. We also kn

Re: PartitionDispatch's partdesc field

On 2018/07/26 5:23, Robert Haas wrote: > I noticed today that in the PartitionDispatch structure, the partdesc > field is set but not used. So we could remove it. See attached > pd-partdesc-remove.patch. If we want to go this route, I suggest > doing a slightly more thorough removal and getting

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

On Tue, Jul 24, 2018 at 06:27:16PM +0900, Kyotaro HORIGUCHI wrote: > I may be misunderstanding something because (really ?) it's still > extremely hot in Japan, today. It is better since yesterday, in exchange of a typhoon heading straight to Tokyo :) -- Michael signature.asc Description: PGP s

Re: print_path is missing GatherMerge and CustomScan support

(2018/07/19 14:11), Ashutosh Bapat wrote: On Thu, Jul 19, 2018 at 5:37 AM, Michael Paquier wrote: On Wed, Jul 18, 2018 at 12:15:25PM +0530, Ashutosh Bapat wrote: Yes that's right. Thanks for taking care of it. Okay, I have pushed a fix for this one as that's wrong and back-patched to v11. T

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

Hi, So, I have spent the last couple of days trying to figure out a nice solution for VACUUM, TRUNCATE and REINDEX, and attached is a set of three patches to address the issues of this thread: 1) 0001 does the work for TRUNCATE, but using RangeVarGetRelidExtended with a custom callback based on th

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

On Thu, Jul 26, 2018 at 2:12 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 24, 2018 at 7:51 AM, Etsuro Fujita >> wrote: >>> I'm not sure that's a good idea, because I think we have a trade-off >>> relation; the more we make create_plan simple, the more we need to make >>> earlier stat

Re: Optimizer misses big in 10.4 with BRIN index

On 26 July 2018 at 04:50, Tomas Vondra wrote: > My guess is this is the root cause - the estimated number of rows is much > higher than in practice (3377106 vs. 23040), so at the end the seqscan is > considered to be slightly cheaper and wins. But the actual row count is > ~150x lower, making the

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello. At Wed, 25 Jul 2018 23:08:33 +0900, Michael Paquier wrote in <20180725140833.gc6...@paquier.xyz> > On Wed, Jul 18, 2018 at 05:58:16PM +0300, Heikki Linnakangas wrote: > > I'd suggest that we continue based on the patch that Kyotaro posted at > > https://www.postgresql.org/message-id/20180

RE: [bug fix] Produce a crash dump before main() on Windows

From: Michael Paquier [mailto:mich...@paquier.xyz] > No, I really mean a library dependency failure. For example, imagine that > Postgres is compiled on Windows dynamically, and that it depends on > libxml2.dll, which is itself compiled dynamically. Then imagine, in a > custom build echosystem, t

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

On Mon, Jan 29, 2018 at 10:42 AM, Yuto Hayamizu wrote: > On Fri, Jan 19, 2018 at 5:07 PM, Yuto Hayamizu wrote: >> My idea of improving this patch is that give a threshold N_limit, >> and for q_1 ... q_N_limit, do the same weighted cost estimation in the >> current version of this patch. >> For q_