Re: [HACKERS] initdb problem
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] initdb problem |
Дата | |
Msg-id | 199808231817.OAA20952@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] initdb problem (Michael Meskes <meskes@online-club.de>) |
Ответы |
Re: [HACKERS] initdb problem
Re: [HACKERS] initdb problem Re: [HACKERS] initdb problem |
Список | pgsql-hackers |
> On Thu, Aug 20, 1998 at 07:06:43PM -0400, Bruce Momjian wrote: > > Just a quick question. Are people doing a make clean when updating via > > cvs. My patch changed lots of system tables. > > Yes, I do. OK, it appears people are still having initdb problems after my patch. I have received several reports of problems. Someone reported a regression test problem with contraints.sql. I could reproduce it here, and fixed it. The other problems with initdb itself are more difficult. People seem to have a variety of initdb failures, and I am at a loss to find a cause. I realize this is a major problem, and I want to fix it as soon as I can. I am running BSDI under Intel, and everything works fine, so I am really confused. First, people have to do a 'make clean', 'make', and 'initdb' after my patch, but people are already doing that. Keith Parks <emkxp01@mtcc.demon.co.uk> reported problems right away, and I tried to recommend solutions. His most recent change was to blow away his entire cvs tree and re-download it, on the assumption that it was not matching the main cvs tree somehow. Keith, did that fix the problem? I have just done the same, to make sure I am in sync, and everything still works as it should. What platform are people using. What failures? Are they consistent? Can someone give me telnet access to a machine that does not work? Marc, does postgresql.org machine do initdb properly? Please report problems to me directly, and I will keep trying to find the cause. -- 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)
В списке pgsql-hackers по дате отправления: