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 t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
3.
Bruce Momjian br...@momjian.us 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));
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, ...)
and
On Fri, Jan 10, 2014 at 04:06:11PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
That was probably me. I'll look into it.
On Jan 6, 2014, at 11:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
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 get
Bruce Momjian br...@momjian.us 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
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 report
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 this
Peter Eisentraut pete...@gmx.net 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
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:
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:
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:
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 because
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
15 matches
Mail list logo
