On Thu, Sep 2, 2010 at 8:13 AM, Michael Haggerty <mhagger(at)alum(dot)mit(dot)edu> wrote:
> Robert Haas wrote:
>> On Wed, Sep 1, 2010 at 6:39 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>>>> That definitely didn't fix it, although I'm not quite sure why. Can
>>>> you throw the modified CVS you ran this off of up somewhere I can
>>>> rsync it?
>>> no rsync server on that box, but I put up a tarball for you at
>> OK, color me baffled. I looked at gram.c and I believe you obsoleted
>> the right revs. The only difference I see between this and some other
>> random deleted file is that it has a couple of tags pointing to revs
>> that don't exist any more, but I can't see how that would cause the
>> observed weirdness.
> What weirdness, exactly, are you discussing now? I've lost track of
> which problem(s) are still unresolved.
Lots of commits that look like this:
Author: PostgreSQL Daemon <webmaster(at)postgresql(dot)org>
Date: Sat Dec 2 08:36:42 2006 +0000
This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'.
Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon
It seems there's something that cvs(2svn) doesn't like about the
history of those files. Magnus tried obsoleting the revisions that
show up as modifications of the dead revision, which seems to make
that history basically identical to the histories of other files that
are handled properly, but evidently there's still something wonky
The Enterprise Postgres Company
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-09-02 13:12:33|
|Subject: Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression |
|Previous:||From: Robert Haas||Date: 2010-09-02 12:59:28|
|Subject: Re: Synchronous replication - patch status inquiry|