On Tue, Mar 7, 2017 at 4:15 PM, Amit Langote
wrote:
> Sorry about the absence on this thread.
No problems! Thanks for showing up with an updated patch.
> On 2017/02/14 15:30, Michael Paquier wrote:
>> On Tue, Feb 14, 2017 at 3:18 PM, Amit Langote wrote:
>>>
>>> Added more tests in pgstattuple an
On Wed, Mar 8, 2017 at 11:29 AM, Peter Eisentraut
wrote:
> On 3/6/17 21:11, Michael Paquier wrote:
>> I think that the documentation of initdb should mention that
>> pg_hba.conf entries are configured for replication connections as
>> well, something like a sentence in the Description paragraph:
>
On Wed, Mar 8, 2017 at 12:27 AM, Robert Haas wrote:
> Amit, Rafia,
>
> nodeIndexscan.c, unlike nodeSeqscan.c, thinks that a parallel-aware
> scan will always be executed in parallel mode. But that's not true:
> an Execute message with a non-zero row count could cause us to abandon
> planned paral
On 19 February 2017 at 14:59, Robert Haas wrote:
> On Fri, Feb 17, 2017 at 2:56 PM, Amit Khandekar
> wrote:
>> The log2(num_children)+1 formula which you proposed does not take into
>> account the number of workers for each of the subplans, that's why I
>> am a bit more inclined to look for some
Hello,
dblink fails to close the unnamed connection as follows when a new unnamed
connection is requested. The attached patch fixes this.
postgres=# select count(*) from pg_stat_activity;
count
---
1
(1 row)
postgres=# select dblink_connect('dbname=postgres');
dblink_connect
-
On Wed, Mar 8, 2017 at 2:32 PM, Rushabh Lathia wrote:
> One quick comments:
>
> +| PASSWORD '(' Sconst USING Sconst ')'
> +{
> +$$ = makeDefElem("methodPassword",
> + (Node *)list_make2(makeString($3),
> +
On Tue, Mar 7, 2017 at 10:10 PM, Dilip Kumar wrote:
>> It's not about speed. It's about not forgetting to prefetch. Suppose
>> that worker 1 becomes the prefetch worker but then doesn't return to
>> the Bitmap Heap Scan node for a long time because it's busy in some
>> other part of the plan tre
On Tue, Mar 7, 2017 at 9:23 PM, Stephen Frost wrote:
> Ashutosh,
>
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> Here are patches for follwing
>> 1. pg_explain_plan_time_v3 adds SUMMARY option which behaves as:
>> SUMMARY when ON prints planning time. With ANALYZE ON, it also prin
Hi Ashutosh,
On 2017/03/06 18:19, Ashutosh Bapat wrote:
> On Mon, Mar 6, 2017 at 11:12 AM, Ashutosh Bapat wrote:
>> On Mon, Mar 6, 2017 at 11:05 AM, Simon Riggs wrote:
>>> "has partitions" is not part of the DDL, whereas "FOR VALUES FROM (0)
>>> TO (100)" is. So ISTM sensible to differentiate bet
On Wed, Mar 8, 2017 at 9:59 AM, Tom Lane wrote:
> Michael Paquier writes:
> > here is a separate thread dedicated to the following extension for
> > CREATE/ALTER ROLE: PASSWORD ('value' USING 'method').
>
> The parentheses seem weird ... do we really need those?
>
+1
I had quick glance to patc
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tsunakawa,
> Takayuki
> How about applying the attached small patch for another refactoring? This
> merely changes makeStringInfo() to initStringInfo() at two sites just other
> places in the same f
From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut
> Here is a patch to refactor some macro hell in dblink.
>
> This patch was discussed in the background sessions thread as a prerequisite
> for some work there, but I figure I'll ma
On Wed, Mar 8, 2017 at 1:29 PM, Tom Lane wrote:
> Michael Paquier writes:
>> here is a separate thread dedicated to the following extension for
>> CREATE/ALTER ROLE: PASSWORD ('value' USING 'method').
>
> The parentheses seem weird ... do we really need those?
A grammar without parenthesis works
Michael Paquier writes:
> here is a separate thread dedicated to the following extension for
> CREATE/ALTER ROLE: PASSWORD ('value' USING 'method').
The parentheses seem weird ... do we really need those?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-
On 2017-03-07 20:58:35 +0800, Simon Riggs wrote:
> On 7 March 2017 at 20:36, Alvaro Herrera wrote:
>
> > FWIW, +1 on improving matters here.
>
> +1 also.
>
> I don't see what's wrong with relying on buildfarm though; testing is
> exactly what its there for.
>
> If we had a two-stage process, w
On Wed, Mar 8, 2017 at 7:36 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 7:14 AM, Ashutosh Bapat
> wrote:
>> Hi Amit,
>> Thanks for adding testcases. Overall the testcases look good.
>>
>> The testcase is using ALTER TABLE to modify foreign table schema.
>> Though this works, I think a better
On 3/7/17 11:38 AM, Andres Freund wrote:
<...>
We have a plenty of time and we dedicate one full-time developer for
this project.
How about having that, and perhaps others, developer participate in
reviewing patches and getting to the bottom of the commitfest? Should
we end up being done ear
On 2017/03/08 2:55, Tom Lane wrote:
> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
> It looks rather out of place considering that seven of the eight
> pre-existing relkind codes are lower case. (And no, I don't especially
> approve of RELKIND_SEQUENCE being 'S' either, but
On Tue, Mar 7, 2017 at 7:24 AM, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> wrote:
>
>
> On 03/07/2017 07:58 AM, Simon Riggs wrote:
> > On 7 March 2017 at 20:36, Alvaro Herrera
> wrote:
> >
> >> FWIW, +1 on improving matters here.
> > +1 also.
> >
> > I don't see what's wrong with relying on
On 3/7/17 11:56, Masahiko Sawada wrote:
> This issue happen even ALTER SUBSCRIPTION. I guess the main cause is
> that acl_kind of pg_publication and pg_subscription of ObjectProperty
> array are not correct. These values should be set ACL_KIND_PUBLICATION
> and ACL_KIND_SUBSCRIPTION instead of -1.
On Wed, Feb 1, 2017 at 3:13 PM, Michael Paquier
wrote:
> On Fri, Jan 27, 2017 at 10:26 AM, Haribabu Kommi
> wrote:
> > Thanks for the review.
> > Let's wait for the committer's opinion.
>
> I have moved this patch to CF 2017-03 to wait for this to happen.
>
Attached a rebased patch to resolve t
On Tue, Mar 7, 2017 at 4:36 AM, Heikki Linnakangas wrote:
> On 03/02/2017 08:50 AM, Michael Paquier wrote:
>
>> Attached is a new patch set. I have combined SASLprep with the rest
>> and fixed some conflicts. At the same time when going through NFKC
>> this morning I have noticed that the impleme
On Wed, Mar 1, 2017 at 12:59 PM, Haribabu Kommi
wrote:
>
> Patch attached. Still some more docs needs to be added.
>
Updated patch attached to resolve the conflicts with following commit.
commit 9a83d56b38c870ce47b7651385ff2add583bf136
Author: Simon Riggs
Date: Tue Mar 7 22:00:54 2017 +0800
On 3/3/17 4:54 PM, David Steele wrote:
On 2/1/17 1:25 AM, Kyotaro HORIGUCHI wrote:
Hello, thank you for moving this to the next CF.
At Wed, 1 Feb 2017 13:09:51 +0900, Michael Paquier wrote
in
On Tue, Jan 24, 2017 at 4:58 PM, Kyotaro HORIGUCHI
wrote:
Six new syscaches in 665d1fa was confl
On 2017-03-07 21:48:23 -0500, Robert Haas wrote:
> On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson wrote:
> > And I would argue that his feature is useful for quite many, based on my
> > experience running a semi-large database. Index bloat happens and without
> > REINDEX CONCURRENTLY it can be r
On 2017-03-07 21:38:40 -0500, Robert Haas wrote:
> > I wonder however, if careful snapshot managment couldn't solve this as
> > well. I have *not* thought a lot about this, but afaics we can easily
> > prevent all-visible from being set in cases it'd bother us by having an
> > "appropriate" xmin /
Hi all,
Here is another thread for an issue related to SCRAM
(https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74...@iki.fi),
that can be discussed independently: SASLprep.
RFC5802 (https://tools.ietf.org/html/rfc5802) regarding the
implementation of SCRAM, needs to have passw
On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila wrote:
> If we have lesser index pages and more heap pages, then we limit the
> parallelism based on index pages.
Kinda. In most cases, we figure out the degree of parallelism based
on heap pages and then we figure out the degree of parallelism based
o
On Tue, Mar 7, 2017 at 9:32 PM, Amit Kapila wrote:
> On Tue, Mar 7, 2017 at 9:16 PM, Robert Haas wrote:
>> On Mon, Mar 6, 2017 at 9:09 PM, Amit Kapila wrote:
>>> Sure, if you think both Writes and Reads at OS level can have some
>>> chance of blocking in obscure cases, then we should add a wait
On Wed, Mar 8, 2017 at 8:08 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 9:12 PM, Andres Freund wrote:
>
> >
> > I wonder however, if careful snapshot managment couldn't solve this as
> > well. I have *not* thought a lot about this, but afaics we can easily
> > prevent all-visible from being
On Sun, Mar 5, 2017 at 7:13 PM, Andreas Karlsson wrote:
> And I would argue that his feature is useful for quite many, based on my
> experience running a semi-large database. Index bloat happens and without
> REINDEX CONCURRENTLY it can be really annoying to solve, especially for
> primary keys. C
On Wed, Mar 8, 2017 at 7:33 AM, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> > Right, that's what I thought he was getting at and my general thinking
> > was that we would need a way to discover if a CIC is ongoing on the
> > relation and therefore heap_page_prune(
On Tue, Mar 7, 2017 at 9:12 PM, Andres Freund wrote:
> On 2017-03-07 21:03:53 -0500, Robert Haas wrote:
>> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
>> > Right, that's what I thought he was getting at and my general thinking
>> > was that we would need a way to discover if a CIC is ong
On Tue, Mar 7, 2017 at 3:56 PM, Sven R. Kunze wrote:
>> 2) As far as I can tell from reading the code to_date currently ignores
>> the M suffix which indicates that you want localized month/day names, so i
>> guess that to_date is currently immutable. Maybe it is stable due to the
>> idea that we
On Tue, Mar 7, 2017 at 9:16 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 9:09 PM, Amit Kapila wrote:
>> Sure, if you think both Writes and Reads at OS level can have some
>> chance of blocking in obscure cases, then we should add a wait event
>> for them.
>
> I think writes have a chance of bl
On 3/6/17 21:11, Michael Paquier wrote:
> I think that the documentation of initdb should mention that
> pg_hba.conf entries are configured for replication connections as
> well, something like a sentence in the Description paragraph:
> initdb sets pg_hba.conf entries using the specified authentica
On Tue, Mar 7, 2017 at 10:12 PM, Robert Haas wrote:
> On Mon, Mar 6, 2017 at 10:28 PM, Amit Kapila wrote:
>> I also think that commit didn't intend to change the behavior,
>> however, the point is how sensible is it to keep such behavior after
>> Parallel Append. I am not sure if this is the rig
On 28 February 2017 at 01:02, Andres Freund wrote:
> Hi,
>
> On 2017-02-27 03:17:32 -0800, Andres Freund wrote:
>> I'll work on getting slab committed first, and then review / edit /
>> commit generation.c later. One first note there is that I'm wondering
>> if generation.c is a too generic filen
On 2017-03-07 21:03:53 -0500, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> > Right, that's what I thought he was getting at and my general thinking
> > was that we would need a way to discover if a CIC is ongoing on the
> > relation and therefore heap_page_prune(), o
On Wed, Mar 8, 2017 at 3:38 AM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 4:18 AM, Robert Haas wrote:
>> On Tue, Feb 28, 2017 at 7:31 PM, Amit Kapila wrote:
>>> Yeah, actually those were added later in Enable-WAL-for-Hash* patch,
>>> but I think as this patch is standalone, so we should not re
Hi all,
As discussed on the thread dedicated to SCRAM
(https://www.postgresql.org/message-id/243d8c11-6149-a4bb-0909-136992f74...@iki.fi),
here is a separate thread dedicated to the following extension for
CREATE/ALTER ROLE: PASSWORD ('value' USING 'method').
Now that password_encryption has been
On Tue, Mar 7, 2017 at 7:14 AM, Ashutosh Bapat
wrote:
> Hi Amit,
> Thanks for adding testcases. Overall the testcases look good.
>
> The testcase is using ALTER TABLE to modify foreign table schema.
> Though this works, I think a better option is to use ALTER FOREIGN
> TABLE.
>
> Something not rel
On Wed, Mar 8, 2017 at 3:52 AM, Daniel Verite
wrote:
> Vaishnavi Prabakaran wrote:
>
> > Yes, I have created a new patch entry into the commitfest 2017-03 and
> > attached the latest patch with this e-mail.
>
> Please find attached a companion patch implementing the batch API in
> pgbench
On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost wrote:
> Right, that's what I thought he was getting at and my general thinking
> was that we would need a way to discover if a CIC is ongoing on the
> relation and therefore heap_page_prune(), or anything else, would know
> that it can't twiddle the b
On 8 March 2017 at 01:13, Simon Riggs wrote:
> Don't understand this. I'm talking about setting a flag on
> commit/abort WAL records, like the attached.
There's nothing setting a flag in the attached. I only see the
checking of the flag.
> We just need to track info so we can set the flag at EOX
On 8 March 2017 at 00:52, Daniel Verite wrote:
> Vaishnavi Prabakaran wrote:
>
>> Yes, I have created a new patch entry into the commitfest 2017-03 and
>> attached the latest patch with this e-mail.
>
> Please find attached a companion patch implementing the batch API in
> pgbench, exposed
On 2017/03/08 1:34, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 1:43 AM, Amit Langote wrote:
>> On 2017/03/07 14:04, Tom Lane wrote:
>>> Therefore, there should definitely be a partitioned table, hopefully with
>>> a less generic name than "p1", in the final regression DB state. Whether
>>> this p
On 2017/03/08 7:10, Eric Ridge wrote:
> Hi all!
>
> Does anyone know of a simple, example Custom Scan Provider implementation
> for 9.6+?
>
> I found pg_strom by searching GitHub. Its gpuscan.c looks like maybe it
> implements a pattern similar to what I want to do, but there's a lot of
> extran
Thomas Munro writes:
> I have been wondering about a couple of different worst case execution
> strategies that would be better than throwing our hands up and
> potentially exploding memory once we detect that further partitioning
> is not going to help, if we still manage to reach that case despi
On Mon, Feb 20, 2017 at 7:44 PM, Thomas Munro
wrote:
> Was it intentional that this test doesn't include any statements that
> reach the case where the trigger does RAISE EXCEPTION 'RI error'?
> From the output generated there doesn't seem to be any evidence that
> the triggers run at all, though
Andres Freund writes:
> +++ b/src/include/storage/barrier.h
> +#include "postgres.h"
> Huh, that normally shouldn't be in a header. I see you introduced that
> in a bunch of other places too - that really doesn't look right to me.
That is absolutely not project style and is not acceptable.
The
Hi,
On 2017-03-07 18:46:31 -0500, Peter Eisentraut wrote:
> I looked over
> 0001-Add-expression-dependencies-on-composite-type-whole-.patch. That
> seems useful independent of the things you have following.
>
> Even though it is presented more as a preparatory change, it appears to
> have notice
There was a mistake in my driver definition,
this works fine with autosave=always (but not with autoSave ...)
Thanks Again
De : Vladimir Sitnikov [via PostgreSQL]
Envoyé : mardi 7 mars 2017 22:32:27
À : legrand legrand
Objet : Re: Statement-level rollback
Ple
Robert Haas writes:
> On Tue, Mar 7, 2017 at 6:03 PM, Tom Lane wrote:
>> Hm, one would hope that the vast majority of code references are neither
>> of those, but rather "RELKIND_PARTITIONED_TABLE".
> For reasons which must've seemed good to whoever instituted the
> policy, pg_dump refers to rel
Hi,
0001: Do hash join work_mem accounting in chunks.
Don't think there's much left to say.
0002: Check hash join work_mem usage at the point of chunk allocation.
Modify the existing hash join code to detect work_mem exhaustion at
the point where chunks are allocated, instead of checking after
I see it is already addressed in master. Thanks.
Regards,
Neha
I looked over
0001-Add-expression-dependencies-on-composite-type-whole-.patch. That
seems useful independent of the things you have following.
Even though it is presented more as a preparatory change, it appears to
have noticeable user-facing impact, which we should analyze. For
example, in the
On Tue, Mar 7, 2017 at 6:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Mar 7, 2017 at 12:55 PM, Tom Lane wrote:
>>> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
>
>> I can't muster a lot of outrage about this one way or another. One
>> possible advantage of 'P'
On Tue, Mar 7, 2017 at 5:08 PM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 4:18 AM, Robert Haas wrote:
>> On Tue, Feb 28, 2017 at 7:31 PM, Amit Kapila wrote:
>>> Yeah, actually those were added later in Enable-WAL-for-Hash* patch,
>>> but I think as this patch is standalone, so we should not re
Mark Dilger writes:
> You appear to be using a #define macro to wrap a function of the same name
> with the code:
> #define copyObject(obj) ((typeof(obj)) copyObject(obj))
> I don't necessarily have a problem with that, but it struck me as a bit odd,
> and
> grep'ing through the sources, I don'
On 3/7/17 12:55, Tom Lane wrote:
> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
I was confused about this too. If there is no argument against it, I
would favor changing it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On 03/02/2017 07:13 AM, David Steele wrote:
> Hi Simon,
>
> On 2/25/17 2:43 PM, Simon Riggs wrote:
>> On 25 February 2017 at 13:58, Michael Paquier
>> wrote:
>>
>>> - trigger_file is removed.
>>> FWIW, my only complain is about the removal of trigger_file, this is
>>> useful to detect a trigger
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
Hi Peter,
I like the patch so far, and it passes all the regression test
On Tue, Mar 7, 2017 at 4:30 PM, Tom Lane wrote:
> Neha Khatri writes:
> > I was going through the grammer rule for Character types in gram.y and
> > found an optional sub rule in is "opt_charset"
>
> This question seems quite off-topic for pgsql-novice, so I've redirected
> it to pgsql-hackers.
Robert Haas writes:
> On Tue, Mar 7, 2017 at 12:55 PM, Tom Lane wrote:
>> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
> I can't muster a lot of outrage about this one way or another. One
> possible advantage of 'P' is that there are fewer places where 'P' is
> mentioned
Please disregard my previous message.
pgjdbc is already doing upcase conversion, so I would like to see a test
case that reproduces the error.
Alternatively, could you please capture and share TRACE log? (
https://jdbc.postgresql.org/documentation/head/logging.html#configuration )
Vladimir
ср, 8
On 2017-03-06 11:27, Petr Jelinek wrote:
0001-Reserve-global-xmin-for-create-slot-snasphot-export.patch +
0002-Don-t-use-on-disk-snapshots-for-snapshot-export-in-l.patch+
0003-Prevent-snapshot-builder-xmin-from-going-backwards.patch +
0004-Fix-xl_running_xacts-usage-in-snapshot-builder.patch
legrand>when usingversion 42.0.0 with
legrand> jdbc:postgresql://localhost:5432/postgres?autosave=always
The pitfall there is the value should be written with upper case like
autosave=ALWAYS.
I've filed https://github.com/pgjdbc/pgjdbc/issues/769 to improve that at
some point.
Vladimir
Thanks !
that's a very good new !
I'm still receiving the famous
"current transaction is aborted" error
when usingversion 42.0.0 with
jdbc:postgresql://localhost:5432/postgres?autosave=always
But I will see that with pgjdbc team ;o)
Regards
PAscal
--
View this message in conte
You have to turn it on using the autosave parameter. it's not on by
default, and apparently not documented
Dave Cramer
da...@postgresintl.com
www.postgresintl.com
On 7 March 2017 at 17:15, legrand legrand
wrote:
> Thanks !
>
> that's a very good new !
>
>
> I'm still receiving the famous
>
>
Hi all!
Does anyone know of a simple, example Custom Scan Provider implementation
for 9.6+?
I found pg_strom by searching GitHub. Its gpuscan.c looks like maybe it
implements a pattern similar to what I want to do, but there's a lot of
extraneous (to me) stuff to parse through.
I'm kinda surpri
On Wed, Mar 1, 2017 at 4:18 AM, Robert Haas wrote:
> On Tue, Feb 28, 2017 at 7:31 PM, Amit Kapila wrote:
>> Yeah, actually those were added later in Enable-WAL-for-Hash* patch,
>> but I think as this patch is standalone, so we should not remove it
>> from their existing usage, I have added those
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
On linux/gcc the patch generates a warning in nodeAgg.c that is fairly ea
> On Mar 7, 2017, at 1:43 PM, Mark Dilger wrote:
>
> On my MacBook, `make check-world` gives differences in the contrib modules:
I get the same (or similar -- didn't check) regression failure on CentOS, so
this
doesn't appear to be MacBook / hardware specific.
Mark Dilger
--
Sent via pgsql-
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
On my MacBook, `make check-world` gives differences in the contrib module
Hi,
about the datetime issue: as far as I know, JSON does not define a
serialization format for dates and timestamps.
On the other hand, YAML (as a superset of JSON) already supports a
language-independent date(time) serialization format
(http://yaml.org/type/timestamp.html).
I haven't had
Hi,
On 2017-03-07 02:57:30 +1300, Thomas Munro wrote:
> I'm not sure why nodeHashjoin.c is doing raw batchfile read/write
> operations anyway; why not use tuplestore.c for that (as
> tuplestore.c's comments incorrectly say is the case)?
Another reason presumably is that using tuplestores would ma
On 7 March 2017 at 16:18, Michael Banck wrote:
> On Tue, Mar 07, 2017 at 01:49:29PM -0700, legrand legrand wrote:
> > JDBC has nothing and developers has to play with savepoint as described
> > http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html
>
> JDBC has it since 9.4.1210
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Mar 3, 2017 at 6:06 PM, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> >> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
> >> > Since VM bits are only set during VACUUM which conflicts with CIC on the
> >>
On 8 March 2017 at 09:32, Robert Haas wrote:
> Committed.
Thanks!
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On Tue, Mar 07, 2017 at 01:49:29PM -0700, legrand legrand wrote:
> JDBC has nothing and developers has to play with savepoint as described
> http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html
JDBC has it since 9.4.1210 (2016-09-07), unless I am mistaken:
https://github.com/
On 2/7/17 03:11, Okano, Naoki wrote:
> I tried to cretae a patch for CREATE OR REPLACE TRIGGER.
I have a feeling that this was proposed a few times in the ancient past
but did not go through because of locking issues. I can't find any
emails about it through. Does anyone remember? Have you thou
On 07.03.2017 03:21, Andreas Karlsson wrote:
1) I do not think we currently allow setting the locale like this
anywhere, so this will introduce a new concept to PostgreSQL. And you
will probably need to add support for caching per locale.
Good to know. Could you explain what you mean by "cachi
Hello,
EDB Oracle compatibility proposes edb_stmt_level_tx parameter,
psql uses ON_ERROR_ROLLBACK = 'on',
ODBC has a parameter for this
JDBC has nothing and developers has to play with savepoint as described
http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html
This feature (a
On Fri, Mar 3, 2017 at 6:06 PM, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
>> On 2017-02-28 19:12:03 +0530, Pavan Deolasee wrote:
>> > Since VM bits are only set during VACUUM which conflicts with CIC on the
>> > relation lock, I don't see any risk of incorrectly skipping p
On 1/30/17 20:34, Michael Paquier wrote:
> On Fri, Jan 27, 2017 at 10:17 PM, Michael Paquier
> wrote:
>> Two things I forgot in this patch:
>> - documentation for the new wait event
>> - the string for the wait event or this would show up as "???" in
>> pg_stat_activity.
>> There are no default cl
On Tue, Mar 7, 2017 at 7:42 AM, Amit Kapila wrote:
> On Tue, Mar 7, 2017 at 8:02 AM, David Rowley
> wrote:
>> On 7 March 2017 at 15:21, Amit Kapila wrote:
>>> +1. How about changing the description of
>>> max_parallel_workers_per_gather to "taken from max_worker_processes,
>>> limited by max_pa
On Wed, Mar 1, 2017 at 1:25 PM, Andres Freund wrote:
> On 2017-03-01 10:20:41 -0800, David Fetter wrote:
>> On Wed, Mar 01, 2017 at 09:45:40AM -0500, Peter Eisentraut wrote:
>> > On 2/28/17 04:24, vinayak wrote:
>> > > The view provides the information of analyze command progress details as
>> > >
On Tue, Mar 7, 2017 at 9:07 AM, Rafia Sabih
wrote:
> I have split the patch into two, one is to allow optimiser to select a
> parallel plan for queries in PL functions
> (pl_parallel_opt_support_v1.patch), wherein CURSOR_OPT_PARALLEL_OK is passed
> at required places.
>
> Next, the patch for allow
Hi,
On 2017-03-07 12:21:59 +0300, Oleg Bartunov wrote:
> On 2017-03-03 15:49:38 -0500, David Steele wrote:
> > I propose we move this patch to the 2017-07 CF so further development
> > and review can be done without haste and as the standard becomes more
> > accessible.
+1
> I wanted to have on
Hi
I am sending a review of this interesting feature.
I found following issues, questions:
1. unclosed tags in documentation
2. bad name "changeTargetEntry" - should be makeTargetEntry?
3. Why you removed lot of asserts in prepunion.c? These asserts should be
valid still
4. make_coresponding_ta
On Tue, Mar 7, 2017 at 12:55 PM, Tom Lane wrote:
> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
> It looks rather out of place considering that seven of the eight
> pre-existing relkind codes are lower case. (And no, I don't especially
> approve of RELKIND_SEQUENCE being '
Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'?
It looks rather out of place considering that seven of the eight
pre-existing relkind codes are lower case. (And no, I don't especially
approve of RELKIND_SEQUENCE being 'S' either, but it's far too late to
change that.) Also, i
On Wed, Mar 8, 2017 at 1:58 AM, Masahiko Sawada wrote:
> On Tue, Mar 7, 2017 at 8:48 PM, Ivan Kartyshov
> wrote:
>> Rebase done.
>
> Thank you for updating the patch.
>
>>
>> Meanwhile I made some more changes.
>>
>> Changes
>> ===
>> 1) WAITLSN is now implemented as an extension called "pg_w
Amit, Rafia,
nodeIndexscan.c, unlike nodeSeqscan.c, thinks that a parallel-aware
scan will always be executed in parallel mode. But that's not true:
an Execute message with a non-zero row count could cause us to abandon
planned parallelism and execute the plan serially. I believe this
would cau
On 2017-03-07 13:06:39 -0500, Tom Lane wrote:
> Andres Freund writes:
> >>> On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
> Concretely, something like the attached. This passes regression tests
> but I've not pushed on it any harder than that.
>
> > I think we should go forward with so
Andres Freund writes:
>>> On 2017-02-24 18:04:18 -0500, Tom Lane wrote:
Concretely, something like the attached. This passes regression tests
but I've not pushed on it any harder than that.
> I think we should go forward with something like this patch in all
> branches, and only use To
On Tue, Mar 7, 2017 at 12:11 AM, Ashutosh Bapat
wrote:
> I see that all the changes by Amit and myself to what was earlier 0003
> patch are now part of 0002 patch. The patch looks ready for committer.
Reviewing 0002:
This patch seems to have falsified the header comments for
expand_inherited_rte
Hi,
On 2017-03-08 00:15:05 +1300, David Rowley wrote:
> -static List *RecoveryLockList;
> +/*
> + * RecoveryLockTable is a poor man's hash table that allows us to partition
> + * the stored locks. Which partition a lock is stored in is determined by the
> + * xid which the lock belongs to. The has
On Tue, Mar 7, 2017 at 10:28 PM, Robert Haas wrote:
>> Apart from this, there was one problem in match_unsorted_outer (in
>> v10), Basically, if inner_cheapest_total was not parallel_safe then I
>> was always getting parallel safe inner. But, we should not do anything
>> if jointype was JOIN_UNIQU
1 - 100 of 155 matches
Mail list logo
