Crash in partition-wise join involving dummy partitioned relation

Hi, I noticed a crash in partition-wise involving dummy partitioned tables. Here's simple testcase CREATE TABLE prt1 (a int, b int, c varchar) PARTITION BY RANGE(a); CREATE TABLE prt1_p1 PARTITION OF prt1 FOR VALUES FROM (0) TO (250); CREATE TABLE prt1_p3 PARTITION OF prt1 FOR VALUES FROM (500)

Add PGDLLIMPORT to enable_hashagg

Hey all, There was already a discussion and commit for adding PGDLLIMPORT to some variables which enables extensions to use them on Windows builds. For reference, the previous thread:"Add PGDLLIMPORT lines to some variables". I would like to add PGDLLIMPORT to enable_hashagg for the same reason.

Re: non-bulk inserts and tuple routing

(2018/02/05 14:34), Amit Langote wrote: On 2018/02/02 19:56, Etsuro Fujita wrote: * ExecInitPartitionResultRelInfo is called from ExecFindPartition, but we could call that another way; in ExecInsert/CopyFrom we call that after ExecFindPartition if the partition chosen by ExecFindPartition has

Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types

On Sun, Jan 14, 2018 at 9:44 PM, Michael Paquier wrote: > On Sun, Jan 14, 2018 at 02:19:26PM +1100, Haribabu Kommi wrote: > > While working on [1], we find out the inconsistency in PQHost() behavior > > if the connecting string that is passed to connect to the server

Re: WIP Patch: Precalculate stable functions, infrastructure v1

Hello! Thank you for reporting! I'll try to get it on our buildfarm.. On 05-02-2018 0:10, Thomas Munro wrote: On Thu, Feb 1, 2018 at 6:01 PM, Marina Polyakova wrote: This is the 8-th version of the patch for the precalculation of stable or immutable functions,

Re: Query running for very long time (server hanged) with parallel append

On 2 February 2018 at 20:46, Robert Haas wrote: > On Fri, Feb 2, 2018 at 1:43 AM, Amit Khandekar wrote: >> The query is actually hanging because one of the workers is in a small >> loop where it iterates over the subplans searching for unfinished >>

Re: JIT compiling with LLVM v9.1

On Sunday, February 4, 2018 12:45:50 AM CET Andreas Karlsson wrote: > On 02/02/2018 10:48 AM, Pierre Ducroquet wrote: > > I have successfully built the JIT branch against LLVM 4.0.1 on Debian > > testing. This is not enough for Debian stable (LLVM 3.9 is the latest > > available there), but it's a

Re: [HACKERS] Pluggable storage

On Tue, Jan 9, 2018 at 11:42 PM, Haribabu Kommi wrote: > > Updated patches are attached. > To integrate the columnar store with the pluggable storage API, I found that there are couple of other things also that needs to be supported. 1. Choosing the right table access

Re: csv format for psql

2018-01-31 13:58 GMT+01:00 Daniel Verite : > Pavel Stehule wrote: > > > This format is too important, so some special short or long option can be > > practical (it will be printed in help) > > > > some like --csv > > I guess -C/--csv could be used, like there

Re: JIT compiling with LLVM v9.1

On Sunday, February 4, 2018 12:45:50 AM CET Andreas Karlsson wrote: > On 02/02/2018 10:48 AM, Pierre Ducroquet wrote: > > I have successfully built the JIT branch against LLVM 4.0.1 on Debian > > testing. This is not enough for Debian stable (LLVM 3.9 is the latest > > available there), but it's a

Re: Boolean partitions syntax

Hello, At Fri, 02 Feb 2018 18:04:44 -0500, Tom Lane wrote in <14732.1517612...@sss.pgh.pa.us> > Robert Haas writes: > > On Fri, Feb 2, 2018 at 4:40 PM, Peter Eisentraut > > wrote: > >> There might be other options,

Better Upgrades

Folks, While chatting with Bruce about how to make something better than pg_upgrade, we (and by "we," I mean mostly Bruce) came up with the following. What needs improvement: - pg_upgrade forces a down time event, no matter how cleverly it's done. - pg_upgrade is very much a blocker for on-disk

Re: WIP: BRIN multi-range indexes

On 02/06/2018 12:40 AM, Tom Lane wrote: > Tomas Vondra writes: >> Yeah, that's what I've been wondering about too. There's also this >> comment in nabstime.h: > >> /* >> * Although time_t generally is a long int on 64 bit systems, these two >> * types must be 4

Re: Better Upgrades

On 6 February 2018 at 08:09, David Fetter wrote: > Folks, > > While chatting with Bruce about how to make something better than > pg_upgrade, we (and by "we," I mean mostly Bruce) came up with the > following. > > What needs improvement: > > - pg_upgrade forces a down time

Re: WIP: BRIN multi-range indexes

Tomas Vondra writes: > Yeah, that's what I've been wondering about too. There's also this > comment in nabstime.h: > /* > * Although time_t generally is a long int on 64 bit systems, these two > * types must be 4 bytes, because that's what pg_type.h assumes. They

psql tab completion vs transactions

Hi folks, While working on tab completion for SELECT I found a few existing problems with how psql's tab completion queries interact with transactions. - If a tab completion query fails, it will abort the user's transaction. For example, typing, "ALTER PUBLICATION " when connected to an older

Re: Better Upgrades

On Mon, Feb 5, 2018 at 5:09 PM, David Fetter wrote: > > The proposal has blockers: > > - We don't actually have logical decoding for DDL, although I'm given > to understand that Álvaro Herrera has done some yeoman follow-up > work on Dimitri Fontaine's PoC patches. > - We

Re: [HACKERS] [PATCH] Lockable views

Robert, > I just reread those discussions but I don't see that they really make > any argument for the behavior the patch implements. I see no > explanation on the thread for why locking a table inside of a subquery > is more or less likely to cause deadlock than locking one outside of a >

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Mon, Feb 5, 2018 at 2:55 PM, Claudio Freire wrote: > With that in mind, I'm noticing WorkItems have a avw_database that > isn't checked by do_autovacuum. Is that right? Shouldn't only work > items that belong to the database being autovacuumed be processed? NVM. I had

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada wrote: > On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire > wrote: >> After autovacuum gets cancelled, the next time it wakes up it will >> retry vacuuming the cancelled relation. That's because a

Re: [HACKERS] [PATCH] Lockable views

> True. But the same exact analysis also applies to this definition, > which contains no subquery: > > CREATE VIEW v1 AS SELECT t1.* FROM t1, t2 WHERE t1.i = t2.i; That's not an updatable view, thus cannot be locked according to the proposed implementation. Anyway do you want to allow to lock

Re: [HACKERS] [PATCH] Lockable views

On Mon, Feb 5, 2018 at 10:26 PM, Tatsuo Ishii wrote: >> True. But the same exact analysis also applies to this definition, >> which contains no subquery: >> >> CREATE VIEW v1 AS SELECT t1.* FROM t1, t2 WHERE t1.i = t2.i; > > That's not an updatable view, thus cannot be locked

Re: [HACKERS] [PATCH] Lockable views

> Hmm, true. Why exactly are we imposing the restriction to updateable > views, anyway? In my understanding, because of ambiguity to determine which rows in which base tables needs to be modified by just looking at the DML against a view. There could be multiple ways to modify the base tables.

Re: [HACKERS] MERGE SQL Statement for PG11

On Sun, Feb 4, 2018 at 3:41 AM, Simon Riggs wrote: >> It is not clear to me what is exactly your concern if we try to follow >> #2? To me, #2 seems like a natural choice. > > At first, but it gives an anomaly so is not a good choice. The patch > does behavior #5, it

Re: [HACKERS] MERGE SQL Statement for PG11

On Sun, Feb 4, 2018 at 5:15 AM, Simon Riggs wrote: > Changes to support sub-selects don't invalidate what is there now in > the current patch with regard to query representation or optimization. > So support of those extra features can be added later if we choose. I don't

Re: [HACKERS] [PATCH] Lockable views

On Mon, Feb 5, 2018 at 10:49 PM, Tatsuo Ishii wrote: >> Hmm, true. Why exactly are we imposing the restriction to updateable >> views, anyway? > > In my understanding, because of ambiguity to determine which rows in > which base tables needs to be modified by just looking at

Re: Crash in partition-wise join involving dummy partitioned relation

On Tue, Feb 6, 2018 at 4:04 AM, Robert Haas wrote: > On Mon, Feb 5, 2018 at 4:46 AM, Ashutosh Bapat > wrote: >> Here's patch taking that approach. > > I rewrote the comment in relation.h like this, which I think is more clear: > > /* > *

Re: [HACKERS] MERGE SQL Statement for PG11

On Mon, Feb 5, 2018 at 7:56 PM, Robert Haas wrote: > I don't think you get to make a unilateral decision to exclude > features that work everywhere else from the scope of this patch. If > there is agreement that those features can be left out of scope, then > that is one

Re: [COMMITTERS] pgsql: Rearm statement_timeout after each executed query.

On 9/18/17 22:41, Andres Freund wrote: > Rearm statement_timeout after each executed query. This appears to have broken statement_timeout behavior in master such that only every second query is affected by it. For example: create table t1 as select * from generate_series(0, 1) as _(a);

Re: Query running for very long time (server hanged) with parallel append

At Mon, 5 Feb 2018 15:29:27 +0530, Amit Khandekar wrote in

Re: Better Upgrades

On 2/5/18 19:09, David Fetter wrote: > - Add a new script--possibly Perl or Bash, which would: > - Initdb a new cluster with the new version of PostgreSQL and a > different port. This will need integration with the packaging system. You'll want to carry over settings from the old

Re: Better Upgrades

On 02/05/2018 04:09 PM, David Fetter wrote: Does this seem worth coding up in its current form? No. The pg_upgrade utility is awesome and I have commended Bruce on multiple occasions about his work with it. That being said, the "solution" is to support in-place upgrades and our work should be

Re: update tuple routing and triggers

On 2018/02/06 10:48, Amit Langote wrote: > When working on this, I wondered if the es_leaf_result_relations should > actually be named something like es_tuple_routing_result_rels, to denote > the fact that they're created by tuple routing code. The current name > might lead to someone thinking

Re: Better Upgrades

On 6 February 2018 at 09:51, Joshua D. Drake wrote: > On 02/05/2018 04:09 PM, David Fetter wrote: > >> Does this seem worth coding up in its current form? >> > > No. The pg_upgrade utility is awesome and I have commended Bruce on > multiple occasions about his work with

update tuple routing and triggers

Hi. Fujita-san pointed out in a nearby thread [1] that EXPLAIN ANALYZE shows duplicate stats for partitions' triggers. Example: create table p (a int) partition by list (a); create table p1 partition of p for values in (1); create table p2 partition of p for values in (2); create table p3

Re: non-bulk inserts and tuple routing

On 2018/02/05 19:43, Etsuro Fujita wrote: > (2018/02/05 14:34), Amit Langote wrote: >> On 2018/02/02 19:56, Etsuro Fujita wrote: >>> * In ExecInitPartitionResultRelInfo: >>> +   /* >>> +    * Note that the entries in this list appear in no predetermined >>> +    * order as result of

Add more information_schema columns

Here is a patch that fills in a few more information schema columns, in particular those related to the trigger transition tables feature. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services From

Re: [HACKERS] [PATCH] Lockable views

On Mon, Feb 5, 2018 at 8:18 PM, Tatsuo Ishii wrote: > We have: CREATE VIEW v1 AS SELECT * FROM t1 WHERE i = (SELECT i FROM t2); > > 1. Session A tries to lock v1 (I suppose it tries to acquire lock in > the order of t1, then t2). A acquires lock on t1 but yet on t2. > > 2.

Re: Query running for very long time (server hanged) with parallel append

At Tue, 06 Feb 2018 13:34:19 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20180206.133419.02213593.horiguchi.kyot...@lab.ntt.co.jp> > At Mon, 5 Feb 2018 15:29:27 +0530, Amit Khandekar > wrote in

Re: update tuple routing and triggers

(2018/02/06 11:38), Amit Langote wrote: On 2018/02/06 10:48, Amit Langote wrote: When working on this, I wondered if the es_leaf_result_relations should actually be named something like es_tuple_routing_result_rels, to denote the fact that they're created by tuple routing code. The current

Re: [HACKERS] More stats about skipped vacuums

On Mon, Dec 11, 2017 at 8:15 PM, Kyotaro HORIGUCHI wrote: > At Mon, 27 Nov 2017 13:51:22 -0500, Robert Haas wrote > in >> On Mon, Nov 27, 2017 at 1:49 AM, Kyotaro

Re: update tuple routing and triggers

Thank you both for the review. I updated the comment in ExecSetupPartitionTupleRouting considering the point both of you raised. About renaming es_leaf_result_relations to es_tuple_routing_result_relations, I will defer that to committer. But on second though, maybe we don't need to make this

Re: update tuple routing and triggers

On 2018/02/06 13:56, Amit Khandekar wrote: > I was wondering whether the same duplicate result rels issue can arise > for es_root_result_relations and es_result_relations. But I think for > inserts, es_root_result_relations is NULL, and for updates, these two > lists always have distinct set of

Warning when building man pages

Hi, I get a warning when building the man pages on Debian testing. The warning is in the documentation for CREATE POLICY and as caused by the three footnotes in the sql-createpolicy-summary table. I do not understand our documentation pipeline well enough to know what the proper fix would

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Feb 5, 2018 at 1:39 PM, Tels wrote: > Are the uninitialized bytes that are written out "whatever was in the > memory previously" or just some "0x00 bytes from the allocation but not > yet overwritten from the PG code"? > > Because the first sounds like it could

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Feb 5, 2018 at 1:27 PM, Robert Haas wrote: > On Mon, Feb 5, 2018 at 1:03 PM, Peter Geoghegan wrote: >> It certainly is common. In the case of logtape.c, we almost always >> write out some garbage bytes, even with serial sorts. The only >> difference

Re: JIT compiling with LLVM v9.1

On Monday, February 5, 2018 10:20:27 PM CET Andreas Karlsson wrote: > OK that fixed the issue, but you have a typo in your patch set. > > diff --git a/src/backend/lib/llvmjit_inline.cpp > b/src/backend/lib/llvmjit_inline.cpp > index a785261bea..51f38e10d2 100644 > ---

Re: Crash in partition-wise join involving dummy partitioned relation

On Mon, Feb 5, 2018 at 4:46 AM, Ashutosh Bapat wrote: > Here's patch taking that approach. I rewrote the comment in relation.h like this, which I think is more clear: /* * Is given relation partitioned? * - * A join between two partitioned relations with

Re: [HACKERS] MERGE SQL Statement for PG11

On Tue, Feb 6, 2018 at 9:50 AM, Peter Geoghegan wrote: > On Mon, Feb 5, 2018 at 7:56 PM, Robert Haas wrote: > > I don't think you get to make a unilateral decision to exclude > > features that work everywhere else from the scope of this patch. If > > there

Re: Query running for very long time (server hanged) with parallel append

On Mon, Feb 5, 2018 at 3:29 PM, Amit Khandekar wrote: > > Attached is a patch that fixes this issue on the above lines. > Patch applied cleanly and work fine for me. mentioned issue is not reproducible now. Thanks & Regards, Rajkumar Raghuwanshi QMG, EnterpriseDB

Re: Query running for very long time (server hanged) with parallel append

On 6 February 2018 at 10:11, Kyotaro HORIGUCHI wrote: >> At Mon, 5 Feb 2018 15:29:27 +0530, Amit Khandekar >> wrote in >> > Attached is a patch that fixes this issue on the above lines. >> >> The patch adds two new variables and always

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

Hello, At Fri, 2 Feb 2018 19:52:02 -0300, Claudio Freire wrote in > On Thu, Jan 25, 2018 at 6:21 PM, Thomas Munro > wrote: > > On Fri, Jan 26, 2018 at 9:38 AM, Claudio

best way to check identical constraint between databases

Hi all, I'm trying to extend pg_tap/pg_tapgen in order to be able to check that two databases have the exact same constraints (for all available types of constraints). I am wondering if there is a better way to check that two constraints are equal than using pg_get_constraintdef, which is

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Tue, Feb 6, 2018 at 2:55 AM, Claudio Freire wrote: > On Mon, Feb 5, 2018 at 1:53 AM, Masahiko Sawada wrote: >> On Fri, Feb 2, 2018 at 11:13 PM, Claudio Freire >> wrote: >>> After autovacuum gets cancelled, the next time

Re: Add more information_schema columns

On Mon, Feb 05, 2018 at 08:59:31PM -0500, Peter Eisentraut wrote: > Here is a patch that fills in a few more information schema columns, in > particular those related to the trigger transition tables feature. It is unfortunate that this cannot be backpatched. Here are few comments, the logic and

Re: [WIP PATCH] Index scan offset optimisation using visibility map

Hi, Michail! Thanks for the patch! > 1 февр. 2018 г., в 1:17, Michail Nikolaev > написал(а): > > Hello. > > WIP-Patch for optimisation of OFFSET + IndexScan using visibility map. While the patch seems to me useful improvement, I see few problems with code: 1.

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Feb 5, 2018 at 1:03 PM, Peter Geoghegan wrote: > It certainly is common. In the case of logtape.c, we almost always > write out some garbage bytes, even with serial sorts. The only > difference here is the *sense* in which they're garbage: they're > uninitialized bytes,

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Feb 2, 2018 at 10:26 PM, Peter Geoghegan wrote: > My proposed commit message > has a full explanation of the Valgrind issue, which I won't repeat > here. Go read it before reading the rest of this e-mail. I'm going to paste the first two sentences of your proposed commit

Re: Warning when building man pages

On 2/5/18 14:50, Andreas Karlsson wrote: > Error message: > > Element sup in namespace '' encountered in a, but no template matches. > Element sup in namespace '' encountered in a, but no template matches. > Element sup in namespace '' encountered in a, but no template matches. > Note: Writing

Re: [HACKERS] A design for amcheck heapam verification

On Mon, Jan 22, 2018 at 6:07 PM, Michael Paquier wrote: > Yep. I have provided the feedback I wanted for 0001 (no API change in > the bloom facility by the way :( ), but I still wanted to look at 0002 > in depths. I don't see a point in adding complexity that no caller

Re: JIT compiling with LLVM v9.1

OK that fixed the issue, but you have a typo in your patch set. diff --git a/src/backend/lib/llvmjit_inline.cpp b/src/backend/lib/llvmjit_inline.cpp index a785261bea..51f38e10d2 100644 --- a/src/backend/lib/llvmjit_inline.cpp +++ b/src/backend/lib/llvmjit_inline.cpp @@ -37,7 +37,7 @@ extern

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, February 5, 2018 4:27 pm, Robert Haas wrote: > On Mon, Feb 5, 2018 at 1:03 PM, Peter Geoghegan wrote: >> It certainly is common. In the case of logtape.c, we almost always >> write out some garbage bytes, even with serial sorts. The only >> difference here is the *sense* in

Re: WIP: BRIN multi-range indexes

> BTW while working on the regression tests, I've noticed that brin.sql > fails to test a couple of minmax opclasses (e.g. abstime/reltime). Is > that intentional or is that something we should fix eventually? I believe abstime/reltime are deprecated. Perhaps nobody wanted to bother adding test