On Fri, Jan 10, 2014 at 04:06:11PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Jan 7, 2014 at 08:19:49AM -0500, Peter Eisentraut wrote:
> >> That was probably me. I'll look into it.
>
> > and in pg_log_v() I see:
>
> > switch (type)
> > ...
> > case PG_FAT
Bruce Momjian wrote:
> I know Peter is looking at this, but I looked at and I can't see the
> problem. Every call of exec_prog() that uses pg_resetxlog has
> throw_error = true, and the test there is:
>
> result = system(cmd);
>
> if (result != 0)
> ...
> pg_log(FATAL, ...)
Bruce Momjian writes:
> On Tue, Jan 7, 2014 at 08:19:49AM -0500, Peter Eisentraut wrote:
>> That was probably me. I'll look into it.
> and in pg_log_v() I see:
> switch (type)
> ...
> case PG_FATAL:
> printf("\n%s", _(message));
> printf("Failure,
On Tue, Jan 7, 2014 at 08:19:49AM -0500, Peter Eisentraut wrote:
> That was probably me. I'll look into it.
>
>
>
> > On Jan 6, 2014, at 11:40 PM, Tom Lane wrote:
> >
> > Bruce Momjian writes:
> >>> On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
> >>> 3. pg_upgrade ignores the fac
That was probably me. I'll look into it.
> On Jan 6, 2014, at 11:40 PM, Tom Lane wrote:
>
> Bruce Momjian writes:
>>> On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
>>> 3. pg_upgrade ignores the fact that pg_resetxlog failed, and keeps going.
>
>> Does pg_resetxlog return a non-ze
Bruce Momjian writes:
> On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
>> 3. pg_upgrade ignores the fact that pg_resetxlog failed, and keeps going.
> Does pg_resetxlog return a non-zero exit status? If so, pg_upgrade
> should have caught that and exited.
It certainly does:
if (e
On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
> There are three or four different bugs here, but the key points are:
>
> 1. pg_resetxlog is diligently trashing every single WAL file in pg_xlog/,
> and then failing (by virtue of some ancient OS X bug in readdir()), so
> that it doesn't
On 2013-12-29 02:48:21 -0500, Tom Lane wrote:
> 4. The server tries to start, and fails because it can't find a WAL file
> containing the last checkpoint record. This is pretty unsurprising given
> the facts above. The reason you don't see any "no such file" report is
> that XLogFileRead() will r
I wrote:
> Perhaps though we should override Autoconf's setting of
> _DARWIN_USE_64_BIT_INODE, if we can do that easily? It's clearly
> not nearly as problem-free on 10.5 as the Autoconf boys believe,
> and it's already enabled by default on the release series where it
> does work.
I looked into
Peter Eisentraut writes:
> On Fri, 2013-12-20 at 10:54 -0300, Alvaro Herrera wrote:
>> Evidently something is not going well in ReadRecord. It should have
>> reported the read failure, but didn't. That seems a separate bug that
>> needs fixed.
> This is enabling large-file support on OS X, so t
Andres Freund wrote:
> Hi,
>
> On 2013-12-24 12:58:04 -0300, Alvaro Herrera wrote:
> > > Shortly after this patch was committed, buildfarm member locust (running
> > > Mac OS X 10.5 apparently) started failing the pg_upgrade check:
> > >
> > > command:
> > > "/Users/pgbuildfarm/Documents/workdir
Hi,
On 2013-12-24 12:58:04 -0300, Alvaro Herrera wrote:
> > Shortly after this patch was committed, buildfarm member locust (running
> > Mac OS X 10.5 apparently) started failing the pg_upgrade check:
> >
> > command:
> > "/Users/pgbuildfarm/Documents/workdir/HEAD/pgsql.82393/contrib/pg_upgrade/
Alvaro Herrera wrote:
Heikki, Andres,
> Shortly after this patch was committed, buildfarm member locust (running
> Mac OS X 10.5 apparently) started failing the pg_upgrade check:
>
> command:
> "/Users/pgbuildfarm/Documents/workdir/HEAD/pgsql.82393/contrib/pg_upgrade/tmp_check/install//Users/pg
On 12/21/13, 9:39 AM, Peter Eisentraut wrote:
> This is enabling large-file support on OS X, so that seems kind of
> important. It's not failing with newer versions of OS X, so that leaves
> the following possibilities, I think:
>
> - Large files never worked on 10.5. That would be strange becau
On Fri, 2013-12-20 at 10:54 -0300, Alvaro Herrera wrote:
> I don't see how can the pg_upgrade check fail in this way but not the
> regular regression test. This patch includes the following hunk to
> pg_config.h.in:
>
> +/* Enable large inode numbers on Mac OS X 10.5. */
> +#ifndef _DARWIN_USE_6
15 matches
Mail list logo
