Peter Eisentraut writes:
> On 6/28/13 6:06 PM, Bruce Momjian wrote:
>> On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote:
>>> pg_upgrade should somehow be able to find out by itself what the
>>> superuser of the old cluster was.
>> Uh, any idea how to do that?
> select rolname fro
On Sun, Oct 21, 2012 at 05:40:40PM -0400, Andrew Dunstan wrote:
>
> I'm not sure if this has come up before.
>
> A client was just finding difficulties because to_char() doesn't
> support formatting the timezone part of a timestamptz numerically
> (i.e. as +-hhmm) instead of using a timezone name
On Thu, 2013-06-27 at 15:59 +0200, Andres Freund wrote:
> Maybe the trick is to add a recovery.conf option to make postgres replay
> to the first restartpoint and then shutdown. At that point you can be
> sure there aren't any torn pages anymore (bugs aside).
> In fact that sounds like a rather use
On Mon, Jan 28, 2013 at 09:46:32AM -0500, Peter Eisentraut wrote:
> On 1/26/13 4:44 PM, Aaron W. Swenson wrote:
> > You are right. Had I read a little further down, it seems that the
> > exit status should actually be 7.
>
> 7 is OK for "not running", but what should we use when the server is not
Did we decide against specifying huge pages in Postgres?
---
On Tue, Oct 30, 2012 at 09:16:07PM +0100, Christian Kruse wrote:
> Hey,
>
> ok, I think I implemented all of the changes you requested. All but
> the ia64 depende
On 6/28/13 9:43 PM, Bruce Momjian wrote:
> On Fri, Jun 28, 2013 at 09:15:31PM -0400, Peter Eisentraut wrote:
>> On 6/28/13 6:06 PM, Bruce Momjian wrote:
>>> On Wed, May 29, 2013 at 09:44:00AM -0400, Peter Eisentraut wrote:
On 5/28/13 10:55 PM, Bruce Momjian wrote:
> Wow, I never realized o
How did you evaluate that coverage increased "greatly"? I am not
generally against these tests but I'd be surprised if the overall test
coverage improved noticeably by this. Which makes 10% runtime overhead
pretty hefty if the goal is to actually achieve a high coverage.
I was relying on Robin
Josh Berkus escribió:
> Hackers,
>
> Per discussion on these tests, I ran "make check" against 9.4 head,
> applied all of the regression tests other than DISCARD.
>
> Time for 3 "make check" runs without new tests: 65.9s
>
> Time for 3 "make check runs with new tests: 71.7s
>
> So that's an inc
Dear hackers,
Per various discussion about the potential impact of Robins non regression
tests, here is a poc patch to separate big tests from others.
"paralle_schedule" holds usual tests, "big_schedule" holds big tests.
The makefile derives serial_schedule, parallel_big_schedule and
serial
Hi,
On 2013-06-28 23:03:22 -0400, Bruce Momjian wrote:
> Did we decide against specifying huge pages in Postgres?
I don't think so. We need somebody to make some last modifications to
the patch though and Christian doesn't seem to have the time atm.
I think the bigger memory (size of the per pro
101 - 110 of 110 matches
Mail list logo
