On 1 March 2017 at 10:47, Thomas Munro wrote:
>>> I added a fourth case 'overwhelm.png' which you might find
>>> interesting. It's essentially like one 'burst' followed by a 100% ide
>>> primary. The primary stops sending new WAL around 50 seconds in and
>>> then there is no autovacuum, nothing
On 5 March 2017 at 18:00, Simon Riggs wrote:
> I'm looking to commit the patch version I posted, so I would like your
> comments that it does continue to solve the problems you raised.
>
Thanks Simon, for confirming.
Yes, the updated patch does solve the problem.
-
robins
On 1 March 2017 at 10:47, Thomas Munro wrote:
> On Fri, Feb 24, 2017 at 9:05 AM, Simon Riggs wrote:
>> On 21 February 2017 at 21:38, Thomas Munro
>> wrote:
>>> However, I think a call like LagTrackerWrite(SendRqstPtr,
>>> GetCurrentTimestamp()) needs to go into XLogSendLogical, to mirror
>>> wha
On 27 February 2017 at 02:38, Amit Langote
wrote:
> On 2017/02/26 5:30, Simon Riggs wrote:
>> On 23 February 2017 at 16:33, Simon Riggs wrote:
>>
>>> I'll be happy to review
>>
>> Patch looks OK so far, but fails on a partition that has partitions,
>> probably because of the way we test relkind
On Sun, Mar 5, 2017 at 12:14 PM, David Steele wrote:
> On 3/4/17 9:08 PM, Masahiko Sawada wrote:
>> On Sat, Mar 4, 2017 at 5:47 PM, Robert Haas wrote:
>>> On Fri, Mar 3, 2017 at 9:50 PM, Masahiko Sawada
>>> wrote:
Yes, it's taking a time to update logic and measurement but it's
coming
On 28 February 2017 at 17:49, Simon Riggs wrote:
> I've edited the stated reason for the patch on the CF app, so its
> clearer as to why this might be acceptable.
Robins,
I'm looking to commit the patch version I posted, so I would like your
comments that it does continue to solve the problems
On 3/4/17 9:08 PM, Masahiko Sawada wrote:
> On Sat, Mar 4, 2017 at 5:47 PM, Robert Haas wrote:
>> On Fri, Mar 3, 2017 at 9:50 PM, Masahiko Sawada
>> wrote:
>>> Yes, it's taking a time to update logic and measurement but it's
>>> coming along. Also I'm working on changing deadlock detection. Will
On Sat, Mar 4, 2017 at 1:46 PM, Peter Eisentraut
wrote:
> On 3/3/17 13:58, Petr Jelinek wrote:
>> On 23/02/17 08:24, Masahiko Sawada wrote:
>>> Attached updated version patches. Please review these.
>>>
>>
>> This version looks good to me, I'd only change the
>>
>>> +PreventTransaction
On Sat, Mar 4, 2017 at 5:47 PM, Robert Haas wrote:
> On Fri, Mar 3, 2017 at 9:50 PM, Masahiko Sawada wrote:
>> Yes, it's taking a time to update logic and measurement but it's
>> coming along. Also I'm working on changing deadlock detection. Will
>> post new patch and measurement result.
>
> I th
On Wed, Mar 1, 2017 at 8:39 PM, Michael Paquier
wrote:
> On Thu, Mar 2, 2017 at 7:20 AM, Jim Mlodgenski wrote:
> >
> >
> > On Sun, Feb 26, 2017 at 11:49 AM, Robert Haas
> wrote:
> >>
> >> On Wed, Feb 22, 2017 at 11:13 AM, Jim Nasby
> >> wrote:
> >> > Certainly easier, but I don't think it'd be
On Sat, Mar 4, 2017 at 6:00 AM, Stephen Frost wrote:
>> It is, but I was using that with index size, not table size. I can
>> change it to be table size, based on what you said. But the workMem
>> related cap, which probably won't end up being applied all that often
>> in practice, *should* still
I wrote:
> Andrew Dunstan writes:
>> On 03/03/2017 02:24 PM, Andrew Dunstan wrote:
>>> I have been setting up a buildfarm member with -DRELCACHE_FORCE_RELEASE
>>> -DCLOBBER_FREED_MEMORY, settings which Alvaro suggested to me.I got core
>>> dumps with these stack traces. The platform is Amazon Linu
Andrew Dunstan writes:
> On 03/03/2017 02:24 PM, Andrew Dunstan wrote:
>> I have been setting up a buildfarm member with -DRELCACHE_FORCE_RELEASE
>> -DCLOBBER_FREED_MEMORY, settings which Alvaro suggested to me.I got core
>> dumps with these stack traces. The platform is Amazon Linux.
> I have re
Hi,
On 2017-03-04 11:02:14 -0500, Tom Lane wrote:
> But speaking of ambiguity: isn't it possible for $n symbols to appear in
> pg_stat_statements already?
Indeed.
> I think it is, both from extended-protocol
> client queries and from SPI commands, which would mean that the proposal
> as it stand
On Sat, Mar 4, 2017 at 8:02 AM, Tom Lane wrote:
>> Perhaps there could be a choice of behaviors. Even if we all agreed
>> that parameter notation was better in theory, there's something to be
>> said for maintaining backward compatibility, or having an option to do
>> so.
>
> Meh ... we've genera
On 3/4/17 12:39, Tomas Vondra wrote:
>> Can we have a test case for page_checksum(), or is that too difficult to
>> get running deterministicly?
>
> I'm not sure it can be made deterministic. Certainly not on heap pages,
> because then it'd be susceptible to xmin/xmax changes, but we have other
On 3/1/17 08:36, Peter Eisentraut wrote:
> On 2/22/17 18:24, Jim Nasby wrote:
>>> Yes, by that logic matview refresh should always be last.
>>
>> Patches for head attached.
>>
>> RLS was the first item added after DO_REFRESH_MATVIEW, which was added
>> in 9.5. So if we want to treat this as a bug,
On 03/04/2017 02:08 PM, Peter Eisentraut wrote:
On 3/3/17 09:03, Tomas Vondra wrote:
Damn. In my defense, the patch was originally created for an older
PostgreSQL version (to investigate issue on a production system), which
used that approach to building values. Should have notice it, though.
A
On March 4, 2017 1:16:56 AM PST, Robert Haas wrote:
>Maybe. But it looks to me like this patch is going to have
>considerably more than its share of user-visible warts, and I'm not
>very excited about that. I feel like what we ought to be doing is
>keeping the index OID the same and changing t
Hi All,
>From following git commit onwards, parallel seq scan is never getting
selected for inheritance or partitioned tables.
commit 51ee6f3160d2e1515ed6197594bda67eb99dc2cc
Author: Robert Haas
Date: Wed Feb 15 13:37:24 2017 -0500
Replace min_parallel_relation_size with two new GUCs.
Robert Haas writes:
> On Thu, Mar 2, 2017 at 3:45 AM, Jim Nasby wrote:
>> On 2/27/17 4:52 PM, Thomas Munro wrote:
>>> By the way, that page claims that PostgreSQL runs on Irix and Tru64,
>>> which hasn't been true for a few years.
>> There could be a GSoC project to add support for those back in
Robert Haas writes:
> On Wed, Mar 1, 2017 at 8:21 PM, Peter Eisentraut
> wrote:
>> On 2/28/17 20:01, Lukas Fittl wrote:
>>> I'd like to propose changing the replacement character from ? to instead
>>> be a parameter (like $1).
>> Hmm, I think this could confuse people into thinking that the quer
"Karl O. Pinc" writes:
> On Sat, 4 Mar 2017 14:26:54 +0530
> Robert Haas wrote:
>> On Fri, Mar 3, 2017 at 7:21 PM, Karl O. Pinc wrote:
>>> But if the code does not exit the loop then
>>> before calling elog(ERROR), shouldn't it
>>> also call FreeFile(fd)?
>> Hmm. Normally error recovery clea
On Sat, 4 Mar 2017 14:26:54 +0530
Robert Haas wrote:
> On Fri, Mar 3, 2017 at 7:21 PM, Karl O. Pinc wrote:
> > But if the code does not exit the loop then
> > before calling elog(ERROR), shouldn't it
> > also call FreeFile(fd)?
>
> Hmm. Normally error recovery cleans up opened files, but sin
On Mon, Feb 20, 2017 at 4:04 PM, Rushabh Lathia
wrote:
>
> My colleague Rahila reported compilation issue with
> the patch. Issue was only coming with we do the clean
> build on the branch.
>
> Fixed the same into latest version of patch.
>
Few assorted comments:
1.
+
+ WriteBuff
On 03/03/2017 02:24 PM, Andrew Dunstan wrote:
> I have been setting up a buildfarm member with -DRELCACHE_FORCE_RELEASE
> -DCLOBBER_FREED_MEMORY, settings which Alvaro suggested to me.I got core
> dumps with these stack traces. The platform is Amazon Linux.
>
I have replicated this on a couple
Hi Robert,
On 3/4/17 1:58 AM, Robert Haas wrote:
> On Wed, Mar 1, 2017 at 9:07 AM, David Steele wrote:
>> On 2/28/17 10:22 PM, Robert Haas wrote:
>>> On Tue, Feb 28, 2017 at 6:22 AM, David Steele wrote:
>> I'm not sure that's the case. It seems like it should lock just as
>> multiple ba
Peter,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Sat, Mar 4, 2017 at 12:50 AM, Robert Haas wrote:
> > If the result of
> > compute_parallel_workers() based on min_parallel_table_scan_size is
> > smaller, then use that value instead. I must be confused, because I
> > actually though that was t
Alright, for the next version of this patch I'll look into standard
deviation (an implementation of Welfords' algorithm already exists in
pg_stat_statements).
On 3/4/17 14:18, Peter Eisentraut wrote:
The other problem is that this measures execution time, which can vary
for reasons other than
Hi Julian,
On 3/4/17 8:41 AM, Julian Markwort wrote:
>> Any improvements would be greatly welcome by the admin
>> community, I'm sure.
> That's good to hear - on the other hand, I really appreciate the opinion
> of admins on this idea!
>> However, this is a rather large change which could be desta
On 3/3/17 09:03, Tomas Vondra wrote:
> Damn. In my defense, the patch was originally created for an older
> PostgreSQL version (to investigate issue on a production system), which
> used that approach to building values. Should have notice it, though.
>
> Attached is v2, fixing both issues.
Can
Any improvements would be greatly welcome by the admin
community, I'm sure.
That's good to hear - on the other hand, I really appreciate the opinion
of admins on this idea!
However, this is a rather large change which could be destabilizing to
the many users of this extension.
I'm fully aware of
On 3/4/17 8:33 AM, Peter Eisentraut wrote:
> On 3/3/17 16:16, David Steele wrote:
>> While this looks like it could be a really significant performance
>> improvement, I think the above demonstrates that it needs a lot of work.
>> I know this is not new to the 2017-03 CF but it doesn't seem enough
On 3/3/17 16:16, David Steele wrote:
> While this looks like it could be a really significant performance
> improvement, I think the above demonstrates that it needs a lot of work.
> I know this is not new to the 2017-03 CF but it doesn't seem enough
> progress has been made since posting to allow
On 1/25/17 12:43, Simon Riggs wrote:
> On 25 January 2017 at 17:34, Julian Markwort
> wrote:
>
>> Analogous to this, a bad_plan is saved, when the time has been exceeded by a
>> factor greater than 1.1 .
> ...and the plan differs?
>
> Probably best to use some stat math to calculate deviation, r
On Sat, Mar 4, 2017 at 3:08 PM, Robert Haas wrote:
> On Thu, Mar 2, 2017 at 5:02 AM, Michael Paquier
> wrote:
>> On Thu, Mar 2, 2017 at 2:26 AM, David Steele wrote:
>>> This patch is in need of a committer. Any takers?
>>> I didn't see a lot of enthusiasm from committers on the thread
>>
>> Ste
On Sat, Mar 4, 2017 at 2:29 PM, Robert Haas wrote:
> On Fri, Mar 3, 2017 at 9:44 AM, Amit Kapila wrote:
>> On Tue, Feb 28, 2017 at 11:06 AM, Kuntal Ghosh
>> wrote:
>>> Hello everyone,
>>>
>>> I've attached a patch which implements WAL consistency checking for
>>> hash indexes. This feature is go
On Sat, Mar 4, 2017 at 8:55 AM, Peter Geoghegan wrote:
> On Fri, Mar 3, 2017 at 6:58 PM, Amit Kapila wrote:
>> You are right that we don't want the number of unclaimed-by-FSM
>> recyclable pages to grow forever, but I think that won't happen with
>> this patch. As soon as there are more deletion
On Thu, Mar 2, 2017 at 6:48 PM, Ashutosh Bapat
wrote:
> On Thu, Mar 2, 2017 at 6:06 PM, Rushabh Lathia
> wrote:
>> While reading through the cost_agg() I found that startup cost for the
>> group aggregate is not correctly assigned. Due to this explain plan is
>> not printing the correct startup
On Thu, Mar 2, 2017 at 11:48 AM, Andres Freund wrote:
> On 2017-03-01 19:25:23 -0600, Jim Nasby wrote:
>> On 2/28/17 11:21 AM, Andreas Karlsson wrote:
>> > The only downside I can see to this approach is that we no logner will
>> > able to reindex catalog tables concurrently, but in return it shou
On Fri, Mar 3, 2017 at 9:44 AM, Amit Kapila wrote:
> On Tue, Feb 28, 2017 at 11:06 AM, Kuntal Ghosh
> wrote:
>> Hello everyone,
>>
>> I've attached a patch which implements WAL consistency checking for
>> hash indexes. This feature is going to be useful for developing and
>> testing of WAL loggin
On Sat, Mar 4, 2017 at 12:50 AM, Robert Haas wrote:
> If you think parallelism isn't worthwhile unless the sort was going to
> be external anyway,
I don't -- that's just when it starts to look like a safe bet that
parallelism is worthwhile. There are quite a few cases where an
external sort is fa
On Fri, Mar 3, 2017 at 7:21 PM, Karl O. Pinc wrote:
> But if the code does not exit the loop then
> before calling elog(ERROR), shouldn't it
> also call FreeFile(fd)?
Hmm. Normally error recovery cleans up opened files, but since
logfile_open() directly calls fopen(), that's not going to work he
On Fri, Mar 3, 2017 at 11:54 AM, Michael Paquier
wrote:
> On Fri, Mar 3, 2017 at 3:18 PM, Robert Haas wrote:
>> Hopefully I haven't broken anything; please let me know if you
>> encounter any issues.
>
> Reading what has just been committed...
>
> + /*
> +* No space found, f
On Sat, Mar 4, 2017 at 2:17 PM, Peter Geoghegan wrote:
> On Sat, Mar 4, 2017 at 12:43 AM, Robert Haas wrote:
>> Oh. But then I don't see why you need min_parallel_anything. That's
>> just based on an estimate of the amount of data per worker vs.
>> maintenance_work_mem, isn't it?
>
> Yes -- and
On Fri, Mar 3, 2017 at 9:50 PM, Masahiko Sawada wrote:
> Yes, it's taking a time to update logic and measurement but it's
> coming along. Also I'm working on changing deadlock detection. Will
> post new patch and measurement result.
I think that we should push this patch out to v11. I think ther
On Sat, Mar 4, 2017 at 12:43 AM, Robert Haas wrote:
> Oh. But then I don't see why you need min_parallel_anything. That's
> just based on an estimate of the amount of data per worker vs.
> maintenance_work_mem, isn't it?
Yes -- and it's generally a pretty good estimate.
I don't really know wha
On Sat, Mar 4, 2017 at 2:01 PM, Peter Geoghegan wrote:
> On Sat, Mar 4, 2017 at 12:23 AM, Robert Haas wrote:
>>> I guess that the workMem scaling threshold thing could be
>>> min_parallel_index_scan_size, rather than min_parallel_relation_size
>>> (which we now call min_parallel_table_scan_size)?
On Sat, Mar 4, 2017 at 12:23 AM, Robert Haas wrote:
>> I guess that the workMem scaling threshold thing could be
>> min_parallel_index_scan_size, rather than min_parallel_relation_size
>> (which we now call min_parallel_table_scan_size)?
>
> No, it should be based on min_parallel_table_scan_size,
On Thu, Mar 2, 2017 at 11:29 PM, Tom Lane wrote:
> After thinking about that for awhile, it seemed like the most useful thing
> to do is to set up an errcontext callback that will be active throughout
> execution of the start_proc. That will cover both setup failures like
> the above, and errors
On Thu, Mar 2, 2017 at 10:38 PM, Peter Geoghegan wrote:
> I'm glad. This justifies the lack of much of any "veto" on the
> logarithmic scaling. The only thing that can do that is
> max_parallel_workers_maintenance, the storage parameter
> parallel_workers (maybe this isn't a storage parameter in V
51 matches
Mail list logo