Обсуждение: CVS and the backend
I've just run CVS UPDATE again, in another attempt to get initdb to run. Anyhow, I noticed that there was a message saying that there were conflicts. Any ideas? -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
>
> I've just run CVS UPDATE again, in another attempt to get initdb to run.
> Anyhow, I noticed that there was a message saying that there were
> conflicts. Any ideas?
>
Conflicts between your cvs tree and the current tree, meaning you
committed stuff and it could not merge the changes into your tree?
I use this script to remove changed files in my distribution.
:
cd /pgcvs &&
pn pgcvs -qn update pgsql | grep '^M ' | cut -d' ' -f2 | xargs rm
pgupdate
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
Peter T Mount <peter@retep.org.uk> writes:
> I've just run CVS UPDATE again, in another attempt to get initdb to run.
> Anyhow, I noticed that there was a message saying that there were
> conflicts. Any ideas?
That means CVS got confused about how to update your local file.
Typically, it means that the file now on your disk is broken ---
it will have both versions of the conflicting text. CVS is expecting
you to sort it out, which would be the right thing if the difference
involved a change that you needed to commit to the source tree.
If the conflict is in a file that you have not got interesting private
changes in, the best thing is just to delete the local copy of that file
and do cvs update again to fetch a clean copy.
regards, tom lane
>I've just run CVS UPDATE again, in another attempt to get initdb to run. >Anyhow, I noticed that there was a message saying that there were >conflicts. Any ideas? initdb no more exists, instead initdb.sh added. Does this have any relation to the confilicts? -- Tatsuo Ishii t-ishii@sra.co.jp
On Wed, 5 Aug 1998, Bruce Momjian wrote: > > > > I've just run CVS UPDATE again, in another attempt to get initdb to run. > > Anyhow, I noticed that there was a message saying that there were > > conflicts. Any ideas? > > > > Conflicts between your cvs tree and the current tree, meaning you > committed stuff and it could not merge the changes into your tree? > > I use this script to remove changed files in my distribution. > > : > cd /pgcvs && > pn pgcvs -qn update pgsql | grep '^M ' | cut -d' ' -f2 | xargs rm > pgupdate I'll try this. It's strange, because I haven't actually made any changes recently, and the errors have occured since I got a fresh set from the server. As for the initdb problem, it's getting further now. It's now hanging while creating the pg_user view. -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
On Thu, 6 Aug 1998 t-ishii@sra.co.jp wrote: > >I've just run CVS UPDATE again, in another attempt to get initdb to run. > >Anyhow, I noticed that there was a message saying that there were > >conflicts. Any ideas? > > initdb no more exists, instead initdb.sh added. Does this have any > relation to the confilicts? Just to check, I removed initdb from the source, as well as the files that had the conflicts. Reran cvs update, and it checked out initdb, so it's still there. Anyhow, cvs doesn't report any conflicts now, so that's working. initdb seems to hang for a few minutes when creating pg_user: vacuuming template1 creating public pg_user view mv: /usr/local/dbase/data/base/template1/xpg_user: No such file or directory -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
On Thu, 6 August 1998, at 06:57:31, Peter T Mount wrote: > Anyhow, cvs doesn't report any conflicts now, so that's working. initdb > seems to hang for a few minutes when creating pg_user: > > vacuuming template1 > creating public pg_user view > mv: /usr/local/dbase/data/base/template1/xpg_user: No such file or > directory this is interesting. this is the same error I get when I use my SSL patch. if anyone knows what this is due to, I would love to remove this bug from my patch! i don't really know enough to have any idea why this would happen. my ssl changed should be *far* away from anything that would produce this.
At 6:34 AM 98.8.6 +0100, Peter T Mount wrote: >On Wed, 5 Aug 1998, Bruce Momjian wrote: >It's strange, because I haven't actually made any changes recently, and >the errors have occured since I got a fresh set from the server. > >As for the initdb problem, it's getting further now. It's now hanging >while creating the pg_user view. Peter, can I get a copy of the sources you are having trouble with? That might help to identify what is causing the trouble. I have experienced similar problem while I was developing the multi-byte patches. -- Tatsuo Ishii t-ishii@sra.co.jp
On Fri, 7 Aug 1998, Tatsuo Ishii wrote: > At 6:34 AM 98.8.6 +0100, Peter T Mount wrote: > >On Wed, 5 Aug 1998, Bruce Momjian wrote: > > >It's strange, because I haven't actually made any changes recently, and > >the errors have occured since I got a fresh set from the server. > > > >As for the initdb problem, it's getting further now. It's now hanging > >while creating the pg_user view. > > Peter, can I get a copy of the sources you are having trouble with? > That might help to identify what is causing the trouble. > I have experienced similar problem while I was developing the multi-byte > patches. Ok, I'll tar them up as soon as I get home. As an extra note: When it's creating the pg_user view, the cpu load slowly reaches about 1.3 then just sits there. -- Peter Mount (at work) peter@taer.maidstone.gov.uk or peter@maidstone.gov.uk If you mail me here, please cc my home address peter@retep.org.uk
> > >It's strange, because I haven't actually made any changes recently,
> > >and the errors have occured since I got a fresh set from the
> > >server.
> > >As for the initdb problem, it's getting further now. It's now
> > >hanging while creating the pg_user view.
My problems with a fresh CVSup'd source went away when I ran ldconfig.
The name of the shared library has changed. One of the symptoms is that
I got an "atoi" error partway through initdb.
Don't know if it is related, but you might want to reconfigure your
shared library database just to be safe...
- Tom
On Fri, 7 Aug 1998, Thomas G. Lockhart wrote: > > > >It's strange, because I haven't actually made any changes recently, > > > >and the errors have occured since I got a fresh set from the > > > >server. > > > >As for the initdb problem, it's getting further now. It's now > > > >hanging while creating the pg_user view. > > My problems with a fresh CVSup'd source went away when I ran ldconfig. > The name of the shared library has changed. One of the symptoms is that > I got an "atoi" error partway through initdb. I did get atoi errors for a while aswell, but apparently that was another problem in the source, not ldconfig. You see, before the atoi errors, I was getting some weird script errors in initdb itself, which were fixed by ldconfig. > Don't know if it is related, but you might want to reconfigure your > shared library database just to be safe... I'm checking that now, and will fetch another fresh source tree at the same time. > > - Tom > -- Peter T Mount peter@retep.org.uk or petermount@earthling.net Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
> > My problems with a fresh CVSup'd source went away when I ran
> > ldconfig. The name of the shared library has changed. One of the
> > symptoms is that I got an "atoi" error partway through initdb.
> I did get atoi errors for a while aswell, but apparently that was
> another problem in the source, not ldconfig. You see, before the atoi
> errors, I was getting some weird script errors in initdb itself, which
> were fixed by ldconfig.
Yes, I saw those too, and I think it was a missing result from pg_id
which did it. Wasn't graceful and we should fix it before the v6.4
release, otherwise many new installations will have the same trouble.
The script should check for a non-empty UID and barf or prompt for it
otherwise. Is anyone actively working on it? Don't remember who
submitted the original patches but it would be nice if they would stick
with it and toughen it up a bit. Otherwise perhaps we should revert to
the original version. Like the features though...
- Tom