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 already is -H/--html.
>
I pre
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
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, but one way to solve this would be to
> >> treat partition bounds as a general
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) TO
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, stable or immutable operators an
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
>> plans, and it never comes out of the loop (it's
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
(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 no
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.
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 method for a particular ta
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 contains
> > multiple hosts w
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
message in here f
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 cancelled
>> autovacuum doesn't update the last-vacu
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 to git pull, it's fixed i
On Mon, Feb 5, 2018 at 9:43 AM, Robert Haas wrote:
> # LogicalTapeFreeze() may write out its first block when it is dirty but
> # not full, and then immediately read the first block back in from its
> # BufFile as a BLCKSZ-width block. This can only occur in rare cases
> # where next to no tuples
The patch looks good to me now other than some smaller issues, mostly in
the documentation. If you fix these I will set it as ready for
committer, and let a committer chime in on the casting logic which we
both find a bit ugly.
== Comments
The only a bit bigger issue I see is the error messag
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 be
> 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
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 man
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. Both branches of "if (node->iss_
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 will actually
use. It *migh
On 02/05/2018 09:27 PM, Mark Dilger wrote:
>
>> 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 depre
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 "C"
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, which Valgrind care
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 which they're
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
> --- a/src/backend/lib/llvmjit_inl
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 here is the *sense* in which they're ga
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 be a security problem - if r
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 same partitioning scheme
- * without
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
> * should be yanked (long) be
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
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
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 don't have logical d
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 bytes, because that's what pg_typ
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 event, no matter how cl
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
> subque
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 instan
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 partit
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
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 ini
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 c8e1585951859b1248f02c
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 tha
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. Another session B acquir
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 it. That being said, the
>
> 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 a
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 according to the
> p
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 rechecks the conditions with t
> 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.
B
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 think you get to make a
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 the DML
> against a v
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:
>
> /*
> * Is given relation partitioned?
> *
> - * A join betwee
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 thing, but so far all the
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);
s
At Mon, 5 Feb 2018 15:29:27 +0530, Amit Khandekar
wrote in
> 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
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
> > On 2 February 2018 at 20:46, Robert Haas wrote:
> > > On Fri, Feb 2, 2018 at 1:43
Thanks for the patch Amit.
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 relations. So this issue m
(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 name
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 HORIGUCHI
>> wrote:
>> > Hmmm. Okay, we must make stats collector more effeicient if we
>> > want to have additional counters with
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 pa
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 rel
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 is agreement that those features can b
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 sets them but warp
>> around can happen at most once per cal
> But what does that have to do with locking?
Well, if the view is not updatable, I think there will be less point
to allow to lock the base tables in the view because locking is
typically used in a case when updates are required.
Of course we could add special triggers to allow to update views t
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 Corporation
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
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 Freire
> > wrote:
> >> I had the tests running in a loop all day long, and I cannot reproduce
> >> that variance.
> >>
> >>
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
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 it wakes up it will
>>> retry vacuuming the cancelled relation. That's b
68 matches
Mail list logo