On Monday, May 20, 2013 6:54 PM Robert Haas wrote:
> On Thu, May 16, 2013 at 10:18 AM, Amit Kapila
> wrote:
> > Further Performance Data:
> >
> > Below data is for average 3 runs of 20 minutes
> >
> > Scale Factor - 1200
> > Shared Buffers - 7G
>
> These results are good but I don't get similar
On 21 May 2013 07:46, Heikki Linnakangas wrote:
> On 21.05.2013 00:00, Simon Riggs wrote:
>>
>> When we set the new timeline we should be updating all values that
>> might be used elsewhere. If we do that, then no matter when or how we
>> run GetXLogReplayRecPtr, it can't ever get it wrong in any
On Tuesday, May 21, 2013 12:36 PM Amit Kapila wrote:
> On Monday, May 20, 2013 6:54 PM Robert Haas wrote:
> > On Thu, May 16, 2013 at 10:18 AM, Amit Kapila
>
> > wrote:
> > > Further Performance Data:
> > >
> > > Below data is for average 3 runs of 20 minutes
> > >
> > > Scale Factor - 1200
> >
> Presumably we would want to repeat all of the ordinary commands, in the
> file, but not any of the backslash set commands that precede any ordinary
> commands. But what if backslash set commands are sprinkled between
> ordinary commands?
See, this is why I had no intention of retrying. Since
On Tue, May 21, 2013 at 4:44 AM, Simon Riggs wrote:
> On 20 May 2013 20:06, Heikki Linnakangas wrote:
>
>>> It would be possible to redesign this with a special new reason, or we
>>> could just use "time" as the reason, or we could just leave it.
>>>
>>> Do nothing is easy, though so are the othe
On 21 May 2013 15:29, Fujii Masao wrote:
> Or, what about using CHECKPOINT_FORCE and just printing "force"?
> Currently that checkpoint always starts because of existence of the
> end-of-recovery record, but I think we should ensure that the checkpoint
> always starts by using that flag.
This wo
We are seeing these errors on a regular basis on the testing box now. We
have even changed the backup script to
shutdown the hot standby, take lvm snapshot, restart the hot standby, rsync
the lvm snapshot. It still happens.
We have never seen this before we introduced the hot standby. So we wil
Hi,
We cannot run parallel pg_dump on the standby server because
pg_export_snapshot() always fails on the standby. Is this the oversight
of parallel pg_dump or pg_export_snapshot()?
pg_export_snapshot() fails in the standby because it always assigns
new XID and which is not allowed in the standby
On 21 May 2013 09:26, Simon Riggs wrote:
> I'm OK with that principle...
Well, after fighting some more with that, I've gone with the, er,
principle of slightly less ugliness.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Service
I worked up a small patch to support Terabyte setting for memory.
Which is OK, but it only works for 1TB, not for 2TB or above.
Which highlights that since we measure things in kB, we have an
inherent limit of 2047GB for our memory settings. It isn't beyond
belief we'll want to go that high, or at
On 22/05/13 09:13, Simon Riggs wrote:
I worked up a small patch to support Terabyte setting for memory.
Which is OK, but it only works for 1TB, not for 2TB or above.
Which highlights that since we measure things in kB, we have an
inherent limit of 2047GB for our memory settings. It isn't beyond
Re: Andrew Dunstan 2013-05-17 <51964770.6070...@dunslane.net>
> I have reproduced this. It happens with both the distro perl and a
> home-built perl 5.14. AFAICT this is a Perl bug. Any reference at
> all to ERRSV at the point this occurs causes a core dump, even just
> assigning it to a local SV *
We've had a number of discussions about the evils of SnapshotNow. As
far as I can tell, nobody likes it and everybody wants it gone, but
there is concern about the performance impact. I decided to do some
testing to measure the impact. I was pleasantly surprised by the
results.
The attached pat
13 matches
Mail list logo
