On 26.04.2017 00:47, Andres Freund wrote:
On 2017-04-25 21:11:08 +, Doug Doole wrote:
When I did this in DB2, I didn't use the parser - it was too expensive. I
just tokenized the statement and used some simple rules to bypass the
invalid cases. For example, if I saw the tokens "ORDER" and
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
> > enabled. This fails when a subscription is enabled immedaitely
> >
On Wed, Apr 26, 2017 at 9:36 AM, Craig Ringer wrote:
> On 26 April 2017 at 08:30, Huong Dangminh wrote:
>
>> Default for hot_standby parameter should be "on" from PostgreSQL 10?
>>
>> In PostgreSQL 10, -w option is default for [pg_ctl start].
>> So in order to start standby we have to setting hot
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 default value now under the circumstances where
> we're focus on stabilizatio
On 26.04.2017 01:34, Andres Freund wrote:
Hi,
(FWIW, on this list we don't do top-quotes)
On 2017-04-25 22:21:22 +, Doug Doole wrote:
Plan invalidation was no different than for any SQL statement. DB2 keeps a
list of the objects the statement depends on. If any of the objects changes
in
On 26.04.2017 04:00, Tsunakawa, Takayuki wrote:
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Konstantin
Knizhnik
Well, first of all I want to share results I already get: pgbench with default
parameters, scale 10 and one connection:
So aut
At Tue, 25 Apr 2017 15:43:59 +0530, Ashutosh Bapat
wrote in
> On Tue, Apr 25, 2017 at 1:31 PM, Kyotaro HORIGUCHI
> wrote:
> >>
> >> The logs above show that 34 seconds elapsed between starting to abort
> >> the transaction and knowing that the foreign server is unreachable. It
> >> looks like
At Tue, 25 Apr 2017 11:00:16 -0400, Robert Haas wrote
in
> On Mon, Apr 24, 2017 at 3:55 AM, Kyotaro HORIGUCHI
> wrote:
> > While I looked into dynahash.c, I found that the following
> > sentense became outdated by 5dfc198. The commit removed the only
> > usage of hash_freeze().
> >
> >> * NOTE:
On 26 April 2017 at 02:12, Peter Eisentraut
wrote:
> On 4/24/17 22:50, Peter Eisentraut wrote:
>> On 4/14/17 00:24, Ashutosh Bapat wrote:
>>> This looks better. Here are patches for master and 9.6.
>>> Since join pushdown was supported in 9.6 the patch should be
>>> backported to 9.6 as well. Atta
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
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
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
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.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 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 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
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 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
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 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
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
> 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
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
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.
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
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
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
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 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 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
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 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
>> >
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 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
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 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
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 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:
> 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 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
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 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 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 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
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 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
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 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
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 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
> ---
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
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
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
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
-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
>
> 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
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
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
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
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
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 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
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,
"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
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
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 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
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 (
* 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
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
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 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
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
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 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)
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);
> >
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 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
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 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 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 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 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 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
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 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
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 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 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 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.
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 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
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 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 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 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 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.
>>
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
1 - 100 of 109 matches
Mail list logo