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?

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