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
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
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.
> >>
> >>
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
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
> 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 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
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 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
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 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
(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
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
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
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
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
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 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 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 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
> 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 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
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
> 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 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
>
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 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
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/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
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
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 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
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 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
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 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
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
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
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
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
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 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 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, 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 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
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 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
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
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 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
> 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
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
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
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
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 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 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 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 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
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.
(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
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
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
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
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,
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
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-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
68 matches
Mail list logo
