needless cleanup scans.
So this leaves us in the situation that
1. Masahiko's patch has unresolved problems
2. Yura's patch works and is useful
Unless there is disagreement on the above, it seems we should apply
Yura's patch (an edited version, perhaps).
--
Simon Riggs
the
> code directly into SnapBuildWaitSnapshot().
This will still fail an Assert in TransactionIdIsInProgress() when
snapshots are overflowed.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
me cases. Note that it will
> only check conflicts for the individual leaf partitions using whatever
> constraint-enforcing indexes they might have.
So we should have 2 patches. One for now that does DO NOTHING and
another that adds the change that depends upon Alvaro's work.
--
Sim
round and change all mentions of "function"
> like that. That might just confuse people.
Agreed
\dfn shows functions only
so we might want to consider having
\df say "List of functions and procedures"
\dfn say "List of functions"
and a new option to list procedures
0 in both cases, so why bother optimising for 1000 connections
at all? In which case we should read the benefit at the 100
connections line, where it shows the lower 28% gain, closer to the
gain your colleague reported.
So I think we don't yet have enough to make a decision.
--
Simon Riggs
l in that case?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 11 December 2017 at 17:38, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 December 2017 at 16:27, Tom Lane wrote:
>>> For a *very* large majority of the callers of AllocSetContextCreate,
>>> the context name is a simple C string constant, so we could just store
>
x27;s not enough.
Not sure what that means.
I think we would need to fire invalidations at COMMIT PREPARED, yet
logically decode them at PREPARE.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4 December 2017 at 15:35, Konstantin Knizhnik
wrote:
> On 30.11.2017 05:02, Michael Paquier wrote:
>>
>> On Wed, Sep 27, 2017 at 4:07 PM, Simon Riggs
>> wrote:
>>>
>>> On 15 September 2017 at 16:34, Konstantin Knizhnik
>>> wrote:
>>>
&
prepared
> transactions, or drop stale replication slots.")));
>
> I am not convinced that you need this bit. autovacuum_freeze_max_age can
> be set to lower to even lower values than the default.
>
> Still, those are minor comments, so I am marking this patc
On 1 December 2017 at 02:50, Michael Paquier wrote:
> On Fri, Nov 24, 2017 at 11:38 PM, Simon Riggs wrote:
>> On 23 November 2017 at 11:11, Michael Paquier
>> wrote:
>>
>>> This is older than the bug report of this thread. All those
>>> indications
run a multi-CPU workload with
heavy WAL inserts to show benefits.
[1] pg_rewind is the only exception which uses xl_prev to find the
previous checkpoint record. But we can always start from the beginning
of the WAL segment and read forward until we find the checkpoint
record. The patch does just the
e a column.
Alternatively, include only the heap block number. That would make it
non-unique, but never more than 240 duplicates. So it would allow suffix
truncation, and yet still avoid the multi-page split effect.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquad
l tested, or even testable.
>
I've never seen an out of memory on the lock table and that seems even less
likely since changes in 9.2.
So no problem removing that.
Are you looking for a patch to backpatch, or just a change for the future?
Changing the parameter in a backpatch seems mo
le.
>
> Wouldn't that take down the entire cluster with no restart?
>
Please explain why you think that would be with no restart.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ld hit limits and that would naturally prune the
workload before it hit the standby.
It's hard to see how any reasonable workload would affect the standby. And
if it did, you'd change the parameter and restart, just like you already
have to do if someone changes max_connections on master first.
So I don't see any problem or anything abnormal in what Tom suggests.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
701 - 716 of 716 matches
Mail list logo
