On 2013-06-03 06:55, Michael Paquier wrote:
Just by having a look at the release notes of Perl, there are still
nothing describing changes between 1.6.3 and 1.8.0:
http://perldoc.perl.org/index-history.html
That page is not updated, it seems. In this list
https://metacpan.org/module/RJBS/perl
Tom Lane wrote:
> It looks quite a bit like somebody's fixed a line-counting bug inside
> Perl, which may mean that we'll have to maintain two expected-output
> files or else remove these particular test cases. Which would be
> annoying.
Maybe we can set a $SIG{__WARN__} routine instead, which w
On Mon, Jun 3, 2013 at 11:29 AM, Tom Lane wrote:
> Can anyone else replicate this change of behavior?
>
Yes. I could reproduce that on an Archlinux box after updating to perl
1.8.0. hamster might also fail with the same error, I just updated its perl
from 1.6.3 to 1.8.0.
> Is there anything abo
Buildfarm member anchovy has been failing the pl/perl regression tests
for the last 11 days. Since configure is helpful enough to print the
version number of the Perl it finds, we can see that anchovy's Perl
version was 5.16.3 in its last successful run, but it's been using
5.18.0 in all the faile
On Sun, Jun 2, 2013 at 2:44 PM, Jeff Janes wrote:
> Do we know why anti-wraparound uses so many resources in the first place?
> The default settings seem to be quite conservative to me, even for a system
> that has only a single 5400 rpm hdd (and even more so for any real
> production system that
Tom Lane writes:
>> Actually, I believe the answer is just that getSchemaData() is doing
>> things in the wrong order:
Each time I have to look at the pg_dump parts I discover new things.
I've been misleading Joe in telling him I though the problem must have
been in extension dependency tracking
On Saturday, June 1, 2013, Robert Haas wrote:
>
> I agree with all that. I don't have any data either, but I agree that
> AFAICT it seems to mostly be a problem for large (terabyte-scale)
> databases, or ones that are dreadfully short of I/O bandwidth. AWS,
> I'm looking at you.
>
> It would be
Sorry for the delay in responding to you.
On Mon, Feb 11, 2013 at 6:03 AM, Phil Sorber wrote:
> On Fri, Feb 8, 2013 at 1:07 PM, Phil Sorber wrote:
>> On Fri, Feb 8, 2013 at 12:46 PM, Fujii Masao wrote:
>>> No maybe. But I think that all the client commands should follow the
>>> same rule. Other
Le mardi 28 mai 2013 15:15:55, Cédric Villemain a écrit :
> Le samedi 25 mai 2013 16:41:24, Cédric Villemain a écrit :
> > > > If it seems to be on the right way, I'll keep fixing EXTENSION
> > > > building with VPATH.
> > >
> > > I haven't tried the patch, but let me just say that Debian (and
> >
Le mardi 28 mai 2013 14:10:14, Cédric Villemain a écrit :
> > I just took time to inspect our contribs, USE_PGXS is not supported by
> > all of them atm because of SHLIB_PREREQS (it used submake) I have a
> > patch pending here to fix that.
>
> Attached patch fix SHLIB_PREREQS when building with U
On 1 June 2013 09:22, Simon Riggs wrote:
> A much better idea is to hold the xmin epoch on the tuple, in addition
> to the xid, if there was a good place to hold this.
This idea is an almost exact duplicate of Heikki Linnakangas' idea for
exactly the same problem.
Given Robert Haas' idea to use
On 1 June 2013 21:27, Noah Misch wrote:
> On Sat, Jun 01, 2013 at 09:41:13AM +0100, Simon Riggs wrote:
>> FK checks can be expensive, especially when loading large volumes of
>> data into an existing table or partition. A couple of ideas for
>> improving performance are discussed here:
>>
>> 1. Us
On Sat, Jun 1, 2013 at 3:57 PM, Andres Freund wrote:
> On 2013-06-01 13:04:55 +0200, Martijn van Oosterhout wrote:
> > On Sat, Jun 01, 2013 at 03:27:40PM +0430, Soroosh Sardari wrote:
> > > Yes, I have some files which is not in pg_class.relfilenode of any
> table or
> > > index.
> > > I want to k
13 matches
Mail list logo
