Hi, Bruce!
2017-04-25 6:31 GMT+05:00 Bruce Momjian :
> The only unusual thing is that this release has ~180 items while most
> recent release have had ~220. The pattern I see that there are more
> large features in this release than previous ones.
I'm not sure, but, probably, it worth mentioning
> On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada
> wrote:
> > Thank you for updating the patch. Also maybe we can update line in
> > PostgresNode.pm where hot_standby is set to on explicitly.
>
> I would refrain from doing that, having some parameters listed in the
> tests makes the intention
On Thu, Apr 27, 2017 at 9:57 AM, Michael Paquier
wrote:
> On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi
> wrote:
> > - Do we need to provide the method here?
> > We have connection object itself, it can decide from the type of
> connection,
> > which method to be used.
>
> Providing the method i
On Thu, Apr 27, 2017 at 1:25 PM, Ashesh Vashi
wrote:
> - Do we need to provide the method here?
> We have connection object itself, it can decide from the type of connection,
> which method to be used.
Providing the method is not mandatory. If you look upthread... If the
caller of this routine sp
On Tue, Apr 25, 2017 at 8:56 PM, Heikki Linnakangas wrote:
> On 04/22/2017 01:20 AM, Michael Paquier wrote:
>
>> On Sat, Apr 22, 2017 at 5:04 AM, Heikki Linnakangas
>> wrote:
>>
>>> I'll continue reviewing the rest of the patch on Monday, but one glaring
>>> issue is that we cannot add an argume
On Thu, Apr 27, 2017 at 11:48 AM, Masahiko Sawada wrote:
> Thank you for updating the patch. Also maybe we can update line in
> PostgresNode.pm where hot_standby is set to on explicitly.
I would refrain from doing that, having some parameters listed in the
tests makes the intention behind those p
On Wed, Apr 26, 2017 at 7:22 PM, Heikki Linnakangas wrote:
> We talked about the alternative where PQencryptPasswordConn() would not look
> at password_encryption, but would always use the strongest possible
> algorithm supported by the server. That would avoid querying the server. But
> then I st
Noticed that a crash occurs if a column is specified twice when creating a
partition:
create table p (a int) partition by list (a);
-- crashes
create table p1 partition of parent (
a not null,
a default 1
) for values in (1);
The logic in MergeAttributes() that merged partition column option
I griped before that the src/test/recovery/ tests take an unreasonably
long time. My interest in that was piqued further when I noticed that
the tests consume not very much CPU time, and aren't exactly saturating
my disks either. That suggests that the problem isn't so much that the
tests do too
Peter Eisentraut writes:
>>> If that's a predictable deadlock, I think a minimum expectation is that
>>> the system should notice it and throw an error, not just hang.
> We had some discussions early on about detecting connections to the same
> server, but it's not entirely clear how to do that a
On Thu, Apr 27, 2017 at 9:54 AM, Huong Dangminh
wrote:
> Thanks all for your comments.
>
>> Magnus Hagander writes:
>> > +1. I definitely think we should do it, and 10 would be the time to do
>> it.
>>
>> Agreed. It's mainly a historical accident that the default is what it
>> is,
>> I think.
>>
On Tue, Apr 25, 2017 at 8:59 AM, Bruce Momjian wrote:
> On Mon, Apr 24, 2017 at 11:05:41PM -0400, Bruce Momjian wrote:
>> > I think the above commit needs a separate mention, as this is a really
>> > huge step forward to control the size of hash indexes.
>>
>> Yes, it is unfotunate that the item i
On 4/23/17 17:09, Andrew Dunstan wrote:
>
> Here's a patch that will allow calling vcregress.pl to run a single TAP
> test set. It would work like this:
>
>
> vcregress.pl src/test/recover true
>
>
> The second argument if true (in the perl sense, of course) would trigger
> a temp install
On Wed, Apr 26, 2017 at 8:46 PM, Bruce Momjian wrote:
> On Wed, Apr 26, 2017 at 07:38:05PM +0530, Amit Kapila wrote:
>> >> I have already mentioned the commit id (5e6d8d2b). Text can be "Allow
>> >> queries containing subplans to execute in parallel". We should also
>> >> mention in some way tha
On Thu, Apr 27, 2017 at 2:25 AM, Tom Lane wrote:
> Simon Riggs writes:
>> I've added code following Michael and Tom's comments to the previous
>> patch. New patch attached.
>
> Couple of minor suggestions:
>
> * Rather than deleting the comment for SubTransSetParent entirely,
> maybe make it say
On 4/23/17 16:58, Robert Haas wrote:
> I agree that ADD is a little odd here, but it doesn't seem terrible.
> But why do we need it? Instead of:
>
> ADD GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY
> SET GENERATED { ALWAYS | BY DEFAULT }
> DROP IDENTITY [ IF EXISTS ]
>
> Why not just:
>
> SET
Robert Haas writes:
> On Wed, Apr 26, 2017 at 8:37 PM, Andres Freund wrote:
>>> 3. Go ahead with converting the postmaster to use WaitEventSet, a la
>>> the draft patch I posted earlier. I'd be happy to do this if we were
>>> at the start of a devel cycle, but right now seems a bit late --- not
On 2017/04/27 1:52, Robert Haas wrote:
> On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
> wrote:
>> FWIW, I too prefer the latter, that is, fire only the parent's triggers.
>> In that case, applying only the patch 0001 will do.
>
> Do we need to update the documentation?
Yes, I think we should.
On 4/26/17 19:18, Michael Paquier wrote:
>> If that's a predictable deadlock, I think a minimum expectation is that
>> the system should notice it and throw an error, not just hang. (Then
>> the error could give a hint about how to work around it.) But the case
>> Bruce has in mind doesn't seem l
On Wed, Apr 26, 2017 at 6:02 PM, Tom Lane wrote:
> Petr Jelinek writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs. My server logs say:
>
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worke
On 4/26/17 12:43, Masahiko Sawada wrote:
> Attached patch for $subject.
>
> s/strigs/strings/
done, thanks
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 2017-04-26 17:05:39 -0400, Tom Lane wrote:
> Here's an updated version of that, which makes use of our previous
> conclusion that F_SETFD/FD_CLOEXEC are available everywhere except
> Windows, and fixes some sloppy thinking about the EXEC_BACKEND case.
>
> I went ahead and changed the call to ep
On Wed, Apr 26, 2017 at 8:37 PM, Andres Freund wrote:
>> 3. Go ahead with converting the postmaster to use WaitEventSet, a la
>> the draft patch I posted earlier. I'd be happy to do this if we were
>> at the start of a devel cycle, but right now seems a bit late --- not
>> to mention that we real
Thanks all for your comments.
> Magnus Hagander writes:
> > +1. I definitely think we should do it, and 10 would be the time to do
> it.
>
> Agreed. It's mainly a historical accident that the default is what it
> is,
> I think.
>
> > I wonder if we should also consider changing the standby err
On Wed, Apr 26, 2017 at 9:52 PM, Magnus Hagander
wrote:
>
> I wonder if we should also consider changing the standby error message to
> be a WARNING instead of an ERROR. So that if you try to start up a standby
> with hot_standby=on but master with wal_level=replica it would turn into a
> cold st
On 2017-04-26 11:42:38 -0400, Tom Lane wrote:
> 1. Let HEAD stand as it is. We have a problem with slow response to
> bgworker start requests that arrive while ServerLoop is active, but that's
> a pretty tight window usually (although I believe I've seen it hit at
> least once in testing).
>
> 2.
On 2017/04/24 13:16, Amit Langote wrote:
> On 2017/04/22 3:40, buschm...@nidsa.net wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 14629
>> Logged by: Hans Buschmann
>> Email address: buschm...@nidsa.net
>> PostgreSQL version: 9.6.2
>> Operating s
On 27 April 2017 at 06:41, Peter Eisentraut
wrote:
> On 4/19/17 08:42, Ashutosh Bapat wrote:
>> I reviewed the patch. It compiles clean, make check-world passes. I do
>> not see any issue with it.
>
> Looks reasonable. Let's keep it for the next commit fest.
Thank you to both of you for looking.
On Thu, Apr 27, 2017 at 7:02 AM, Tom Lane wrote:
> Petr Jelinek writes:
>> On 26/04/17 18:59, Bruce Momjian wrote:
>>> ... it just hangs. My server logs say:
>
>> Yes that's result of how logical replication slots work, the transaction
>> that needs to finish is your transaction. It can be worke
On 27 April 2017 at 01:31, Peter Eisentraut
wrote:
> committed
Great. 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 you
On Thu, Apr 27, 2017 at 5:13 AM, Oleg Golovanov wrote:
> Can you actualize your patch set? The error got from
> 0010-hj-parallel-v12.patch.
I really should get around to setting up a cron job to tell me about
that. Here's a rebased version.
The things currently on my list for this patch are:
1
Petr Jelinek writes:
> On 26/04/17 18:59, Bruce Momjian wrote:
>> ... it just hangs. My server logs say:
> Yes that's result of how logical replication slots work, the transaction
> that needs to finish is your transaction. It can be worked around by
> creating the slot manually via the SQL inte
On Wed, Apr 26, 2017 at 11:41:51PM +0200, Petr Jelinek wrote:
> On 26/04/17 18:59, Bruce Momjian wrote:
> > I tried setting up logical replication on the same server between two
> > different databases, and got, from database test:
> >
> > test=> CREATE TABLE test (x INT PRIMARY KEY);
> >
On 26/04/17 18:59, Bruce Momjian wrote:
> I tried setting up logical replication on the same server between two
> different databases, and got, from database test:
>
> test=> CREATE TABLE test (x INT PRIMARY KEY);
> CREATE TABLE
> test=>
> test=> INSERT INTO test VALUES (1)
Andres Freund writes:
> I'd still like to get something like your CLOEXEC patch applied
> independently however.
Here's an updated version of that, which makes use of our previous
conclusion that F_SETFD/FD_CLOEXEC are available everywhere except
Windows, and fixes some sloppy thinking about the
On Thu, Apr 20, 2017 at 4:27 PM, Robert Haas wrote:
> So, I think we really need something like the syntax in Amul's patch
> in order for this to work at all. Of course, the details can be
> changed according to what seems best but I think the overall picture
> is about right.
I spent some time
On 04/26/2017 08:08 PM, Doug Doole wrote:
A naive option would be to invalidate anything that depends on table or
view *.FOOBAR. You could probably make it a bit smarter by also requiring that
schema A appear in the path.
This has been rumbling around in my head. I wonder if you could so
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> It'd be better to invent inverse pg_get_comment and pg_set_comment
>> functions, then you could do bulk-update things like
>> select pg_set_comment('table', pg_get_comment('table') || ' more')
>> from pg_class where ...
> Of course
On 4/19/17 08:42, Ashutosh Bapat wrote:
> I reviewed the patch. It compiles clean, make check-world passes. I do
> not see any issue with it.
Looks reasonable. Let's keep it for the next commit fest.
>
> On Wed, Apr 19, 2017 at 9:13 AM, David Rowley
> wrote:
>> The attached cleans up a few sma
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Having COMMENT ON accept a general query whose result is then cast to
> > text and stored as the comment would allow this to be done, eg:
>
> > COMMENT ON table IS (pg_get_comment('table') || ' new text');
>
> Putting general sub
Jeff Janes writes:
> This gives me compiler warning:
> launcher.c: In function 'logicalrep_worker_launch':
> launcher.c:257: warning: 'slot' may be used uninitialized in this function
Yeah, me too. Fix pushed.
regards, tom lane
--
Sent via pgsql-hackers mailing list (
On 04/26/2017 10:31 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
I wouldn't fight hard to change it but really if we think about it, what
makes more sense from usability perspective?
CREATE TABLE foo() COMMENT IS
I think it's likely to be impossible to shoehorn such a thing into every
typ
Stephen Frost writes:
> Having COMMENT ON accept a general query whose result is then cast to
> text and stored as the comment would allow this to be done, eg:
> COMMENT ON table IS (pg_get_comment('table') || ' new text');
Putting general subexpressions into utility statements has some
implemen
On Wed, Apr 26, 2017 at 8:20 PM, Peter Geoghegan wrote:
> On Wed, Apr 26, 2017 at 10:10 AM, Alexander Korotkov
> wrote:
> > OK, I get it. Our qsort is so fast not only on 100% presorted case.
> > However, that doesn't change many things in context of incremental sort.
>
> The important point is
On Wed, Apr 26, 2017 at 1:03 PM, Joshua D. Drake
wrote:
> Problem we are trying to solve:
>
> Having documentation for changes to GUC parameters that are modified via
> ALTER SYSTEM.
>
> Why?
>
> Because documentation is good and required for a proper production system.
>
> How?
>
+1 for comment
"Joshua D. Drake" writes:
> I wouldn't fight hard to change it but really if we think about it, what
> makes more sense from usability perspective?
> CREATE TABLE foo() COMMENT IS
I think it's likely to be impossible to shoehorn such a thing into every
type of CREATE command without making COMM
Simon Riggs writes:
> I've added code following Michael and Tom's comments to the previous
> patch. New patch attached.
Couple of minor suggestions:
* Rather than deleting the comment for SubTransSetParent entirely,
maybe make it say "It's possible that the parent was already recorded.
However,
On 04/26/2017 10:14 AM, Stephen Frost wrote:
JD,
Having COMMENT ON accept a general query whose result is then cast to
text and stored as the comment would allow this to be done, eg:
COMMENT ON table IS (pg_get_comment('table') || ' new text');
Dig it, although we probably want the equivale
On 26 April 2017 at 18:03, Joshua D. Drake wrote:
> -hackers,
>
> We have had ALTER SYSTEM for some time now. It is awesome to be able to make
> changes that can be system wide without ever having to hit a shell but it
> does lack a feature that seems like an oversight, the ability to comment.
>
>
On Wed, Apr 26, 2017 at 10:10 AM, Alexander Korotkov
wrote:
> OK, I get it. Our qsort is so fast not only on 100% presorted case.
> However, that doesn't change many things in context of incremental sort.
The important point is to make any presorted test case only ~99%
presorted, so as to not gi
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> Does not use existing comment functionality. Alternate solution
> which would decrease functionality is:
>
> COMMENT ON SETTING setting IS 'comment';
That seems like a pretty reasonable idea, at least from where I sit.
> Looking forward, w
Hi.
Thanks for rebased patch set v12. Currently I try to use this patch on my new
test site and get following:
Hmm... The next patch looks like a unified diff to me...
The text leading up to this was:
--
|diff --git a/src/include/access/parallel.h b/src/include/access/pa
On Wed, Apr 26, 2017 at 7:56 PM, Peter Geoghegan wrote:
> On Wed, Apr 26, 2017 at 8:39 AM, Alexander Korotkov
> wrote:
> > That appears to be wrong. I intended to make cost_sort prefer plain sort
> > over incremental sort for this dataset size. But, that appears to be not
> > always right solu
>
> A naive option would be to invalidate anything that depends on table or
> view *.FOOBAR. You could probably make it a bit smarter by also requiring
> that schema A appear in the path.
>
This has been rumbling around in my head. I wonder if you could solve this
problem by registering dependenci
-hackers,
We have had ALTER SYSTEM for some time now. It is awesome to be able to
make changes that can be system wide without ever having to hit a shell
but it does lack a feature that seems like an oversight, the ability to
comment.
Problem we are trying to solve:
Having documentation for
On Wed, Apr 26, 2017 at 12:57 PM, Tom Lane wrote:
> Would it be worth making password_encryption be GUC_REPORT so that
> it could be guaranteed available, without a server transaction,
> from any valid connection? I'm generally resistant to adding
> GUC_REPORT flags, but maybe this is a time for
On 26 April 2017 at 15:28, Tom Lane wrote:
> Nikhil Sontakke writes:
>> A SELECT query on the newly promoted master on any of the tables involved
>> in the 2PC hangs. The hang is due to a loop in
>> SubTransGetTopmostTransaction(). Due to incorrect linkages, we get a
>> circular reference in pare
I tried setting up logical replication on the same server between two
different databases, and got, from database test:
test=> CREATE TABLE test (x INT PRIMARY KEY);
CREATE TABLE
test=>
test=> INSERT INTO test VALUES (1);
INSERT 0 1
test=> CREATE PUB
Robert Haas writes:
> On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote:
>> * If algorithm is not given explicitly, PQencryptPasswordConn() queries
>> "SHOW password_encryption", and uses that. That is documented, and it is
>> also documented that it will *not* issue queries, and hence wi
On Wed, Apr 26, 2017 at 6:28 AM, Antonin Houska wrote:
> Attached is a diff that contains both patches merged. This is just to prove my
> assumption, details to be elaborated later. The scripts attached produce the
> following plan in my environment:
>
>QUERY PLAN
> ---
On Wed, Apr 26, 2017 at 8:39 AM, Alexander Korotkov
wrote:
> That appears to be wrong. I intended to make cost_sort prefer plain sort
> over incremental sort for this dataset size. But, that appears to be not
> always right solution. Quick sort is so fast only on presorted data.
As you may kno
On Tue, Apr 25, 2017 at 10:34 PM, Amit Langote
wrote:
> FWIW, I too prefer the latter, that is, fire only the parent's triggers.
> In that case, applying only the patch 0001 will do.
Do we need to update the documentation?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
HI,
Attached patch for $subject.
s/strigs/strings/
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_typo_in_worker_c.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Wed, Apr 26, 2017 at 12:41 PM, Tom Lane wrote:
> Robert Haas writes:
>> So this is about a cross-type join,
>> not multiple types within a single partitioning hierarchy, as you
>> might also gather from the subject line of this thread.
>
> OK, but I still don't understand why any type conversi
Robert Haas writes:
> So this is about a cross-type join,
> not multiple types within a single partitioning hierarchy, as you
> might also gather from the subject line of this thread.
OK, but I still don't understand why any type conversion is needed
in such a case. The existing join estimators
On Wed, Apr 26, 2017 at 6:22 AM, Heikki Linnakangas wrote:
> On 04/25/2017 06:26 PM, Heikki Linnakangas wrote:
>> Thoughts? Unless someone has better ideas or objections, I'll go
>> implement that.
> This is what I came up with in the end. Some highlights and differences vs
> the plan I posted ear
On Thu, Apr 27, 2017 at 1:28 AM, Fujii Masao wrote:
> On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
> wrote:
>> At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada
>> wrote in
>>
>>> On Wed, Apr 26, 2017 at 12:35 PM, Petr Jelinek
>>> wrote:
>>> > On 26/04/17 01:01, Fujii Masao wrote:
>>
On Wed, Apr 26, 2017 at 12:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote
>> wrote:
>>> Your patch seems to be a much better solution to the problem, thanks.
>
>> Does anyone wish to object to this patch as untimely?
>
>> If not, I'll commit it.
>
On Wed, Apr 26, 2017 at 12:19 PM, Tom Lane wrote:
> What I'm going to ask one more time, though, is why we are even discussing
> this. Surely the partition bounds of a partitioned table must all be of
> the same type already. If there is a case where they are not, that is
> a bug we had better c
On Wed, Apr 26, 2017 at 3:47 PM, Kyotaro HORIGUCHI
wrote:
> At Wed, 26 Apr 2017 14:31:12 +0900, Masahiko Sawada
> wrote in
>
>> On Wed, Apr 26, 2017 at 12:35 PM, Petr Jelinek
>> wrote:
>> > On 26/04/17 01:01, Fujii Masao wrote:
>> However this is overkill for small gain and false wakeup
Robert Haas writes:
> On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote
> wrote:
>> Your patch seems to be a much better solution to the problem, thanks.
> Does anyone wish to object to this patch as untimely?
> If not, I'll commit it.
It's certainly not untimely to address such problems. What I
On 4/26/17 12:15, Robert Haas wrote:
> On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote
> wrote:
>>> The attached patch try to replace 'heap_open' with 'LockRelationOid' when
>>> locking parent table.
>>> It improved dropping a table with 7000 partitions.
>>
>> Your patch seems to be a much better s
Robert Haas writes:
> I'm going to say this one more time: I really, really, really think
> you need to avoid trying to convert the partition bounds to a common
> type. I said before that the infrastructure to do that is not present
> in our type system, and I'm pretty sure that statement is 100%
On Tue, Apr 25, 2017 at 10:05 PM, Amit Langote
wrote:
>> The attached patch try to replace 'heap_open' with 'LockRelationOid' when
>> locking parent table.
>> It improved dropping a table with 7000 partitions.
>
> Your patch seems to be a much better solution to the problem, thanks.
Does anyone w
This is a kindly reminder, that this problem (message about "constraint"
violation, while there is no such a constraint defined, just an index) is
still unresolved.
Let's fix that naming?
Patch is attached in the previous message (posted to -bugs list)
On Thu, Mar 16, 2017 at 9:15 PM, Nikolay Sa
On 4/18/17 12:17, Euler Taveira wrote:
> While inspecting the logical replication code, I found a bug that could
> pick the wrong remote relation if they have the same name but different
> schemas. Also, I did some spelling/cosmetic changes and fixed an
> oversight in the ALTER SUBSCRIPTION documen
On Mon, Apr 24, 2017 at 7:06 AM, Ashutosh Bapat
wrote:
> This assumes that datums in partition bounds have one to one mapping
> with the partitions, which isn't true for list partitions. For list
> partitions we have multiple datums corresponding to the items listed
> associated with a given parti
On Wed, Apr 26, 2017 at 4:03 PM, Kyotaro HORIGUCHI
wrote:
> At Tue, 25 Apr 2017 14:45:03 -0400, Peter Eisentraut
> wrote in
> <3d6a1bd0-08ce-301d-3336-ec9f623a3...@2ndquadrant.com>
>> On 4/6/17 08:24, Kyotaro HORIGUCHI wrote:
>> > The attached patch wakes up launcher when a subscription is
>> >
I wrote:
> =?utf-8?Q?R=C3=A9mi_Zara?= writes:
>> coypu was not stuck (no buildfarm related process running), but failed to
>> clean-up shared memory and semaphores.
>> I’ve done the clean-up.
> Huh, that's even more interesting.
I installed NetBSD 5.1.5 on an old Mac G4; I believe this is a rea
On Wed, Apr 26, 2017 at 8:00 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 4/25/17 15:42, Petr Jelinek wrote:
> >> Here is the patch doing just that.
> >
> > And one more revision which also checks in_use when attaching shared
> > memory. This is mainly to improve the user v
On Wed, Apr 26, 2017 at 07:38:05PM +0530, Amit Kapila wrote:
> >> I have already mentioned the commit id (5e6d8d2b). Text can be "Allow
> >> queries containing subplans to execute in parallel". We should also
> >> mention in some way that this applies only when the query contains
> >> uncorrelate
On Wed, Apr 26, 2017 at 3:07 PM, Masahiko Sawada wrote:
> Hi,
>
> Attached patch for $subject.
>
> s/accomodate/accommodate/
Pushed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
On 4/25/17 15:42, Petr Jelinek wrote:
>> Here is the patch doing just that.
>
> And one more revision which also checks in_use when attaching shared
> memory. This is mainly to improve the user visible behavior in
> theoretical corner case when the worker is supposed to be cleaned up but
> actuall
Amit,
* Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
> On 2017/04/26 0:42, Stephen Frost wrote:
> > I'm not sure what you mean here. We're always going to call both
> > getInherits() and getPartitions() and run the queries in each, with the
> > way the code is written today. In my experie
Nikhil Sontakke writes:
> A SELECT query on the newly promoted master on any of the tables involved
> in the 2PC hangs. The hang is due to a loop in
> SubTransGetTopmostTransaction(). Due to incorrect linkages, we get a
> circular reference in parentxid <-> subxid inducing the infinite loop.
I'm
Magnus Hagander writes:
> +1. I definitely think we should do it, and 10 would be the time to do it.
Agreed. It's mainly a historical accident that the default is what it is,
I think.
> I wonder if we should also consider changing the standby error message to
> be a WARNING instead of an ERROR.
On Tue, Apr 25, 2017 at 7:19 PM, Bruce Momjian wrote:
> On Tue, Apr 25, 2017 at 09:00:45AM +0530, Amit Kapila wrote:
>> On Tue, Apr 25, 2017 at 8:35 AM, Bruce Momjian wrote:
>> > On Tue, Apr 25, 2017 at 08:30:50AM +0530, Amit Kapila wrote:
>> >> On Tue, Apr 25, 2017 at 7:01 AM, Bruce Momjian wro
> I'm suggesting we take the approach that if there is a problem we can
> recreate it as a way of exploring what conditions are required and
> therefore work out the impact. Nikhil Sontakke appears to have
> re-created something, but not quite what I had expected. I think he
> will post here tomorr
Hello Jeevan,
Thank you for comments.
I will include your comments in the updated patch.
>7.The output of describe needs to be improved.
The syntax for DEFAULT partitioning is still under discussion. This comment
wont be
applicable if the syntax is changed.
>6.
>I am wondering, isn't it possib
On 4/26/17 04:32, David Rowley wrote:
>> For backpatching to 9.6, I came up with the attached reduced version.
>> Since we don't have add_foreign_grouping_paths() in 9.6, we can omit the
>> refactoring and keep the changes much simpler. Does that make sense?
>
> That makes sense to me. It fixes t
On Wed, Apr 26, 2017 at 1:25 PM, Bruce Momjian wrote:
> On Wed, Apr 26, 2017 at 07:33:27AM +, Tsunakawa, Takayuki wrote:
> > From: pgsql-hackers-ow...@postgresql.org
> > > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Masahiko
> Sawada
> > > The idea of changing the default value s
On Wed, Apr 26, 2017 at 07:33:27AM +, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
> > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Masahiko Sawada
> > The idea of changing the default value seems good to me but I'm not sure
> > it's good idea to change the
2017-04-26 12:30 GMT+02:00 Konstantin Knizhnik :
>
>
> On 26.04.2017 10:49, Konstantin Knizhnik wrote:
>
>
>
> On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: Are you considering some
> upper limit on the number of prepared statements?
> In this case we need some kind of LRU for maintaining cach
On Wed, Apr 26, 2017 at 09:34:02AM +0530, Amit Kapila wrote:
> >> Just wondering if the mention of commit
> >> 0414b26bac09379a4cbf1fbd847d1cee2293c5e4 is missed? Not sure if this
> >> requires a separate entry or could be merged with -- Support parallel
> >> btree index scans.
> >
> > This item wa
On Tue, Apr 25, 2017 at 09:56:58PM -0400, Bruce Momjian wrote:
> > SCRAM-SHA-256 improves deficiencies of MD5 password hashing by
> > preventing any kind of pass-the-hash vulnerabilities, where a user
> > would be able to connect to a PostgreSQL instance by just knowing the
> > hash of a password a
On 26.04.2017 10:49, Konstantin Knizhnik wrote:
On 26.04.2017 04:00, Tsunakawa, Takayuki wrote: Are you considering
some upper limit on the number of prepared statements?
In this case we need some kind of LRU for maintaining cache of
autoprepared statements.
I think that it is good idea t
On 04/25/2017 06:26 PM, Heikki Linnakangas wrote:
Thoughts? Unless someone has better ideas or objections, I'll go
implement that.
This is what I came up with in the end. Some highlights and differences
vs the plan I posted earlier:
* If algorithm is not given explicitly, PQencryptPasswordCo
On 26 April 2017 at 00:28, Robert Haas wrote:
> So what I'd prefer -- on
> the totally unprincipled basis that it would let us improve
> performance in the future -- if you operate on a partition directly,
> you fire the partition's triggers, but if you operate on the parent,
> only the parent's t
Hi Stephen,
On 2017/04/26 0:42, Stephen Frost wrote:
> Amit,
>
> * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote:
>> I think why getPartitions() is separate from getInherits() and then
>> flagPartitions() separate from flagInhTables() is because I thought
>> originally that mixing the two wo
At Tue, 25 Apr 2017 21:21:29 +0900, Masahiko Sawada
wrote in
> On Tue, Apr 25, 2017 at 8:07 PM, Amit Kapila wrote:
> > On Tue, Apr 25, 2017 at 2:09 PM, Kyotaro HORIGUCHI
> > wrote:
> >>
> >> I'm not good at composition, so I cannot insist on my
> >> proposal. For the convenience of others, her
1 - 100 of 109 matches
Mail list logo
