Thread: Postgres Instability
I've remarked that postgresql-7.0 have two important bugs no, no... I'll define its Problems. The first is that it is very subsceptible to ipc: it's true that sometimes U need to do an ipcclean to remake it start The second is the very VERY important instability problem. I explain me better: I've tried Postgres on different systems (redhat6.0,6.1, mandrake7.0) and every time after that I make start the postmaster 20 or 30 times in a week or 2, it begin to have a problem with shared memory, but i do an ipcclean and go..., after when postmaster run without problems if I do a createuser (from sqladmin) or a createdb (from user) it give me the same problem like: ------------------------------------------------ FATAL 1: cannot create init file mydatabasedirectory//base/mydb/pg_internal.init ------------------------------------------------ it happens after few times of correct running... and persist also if I recompile again postgresql ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
On Wed, 24 May 2000, planx plnetx wrote: > I've remarked that postgresql-7.0 have two important bugs no, no... > I'll define its Problems. > > The first is that it is very subsceptible to ipc: it's true that sometimes > U need to do an ipcclean to remake it start This sounds like a Linux problem to me ... I've got v7.0 running on a server over here that is dealign with the Search engine for the PostgreSQL site (over 10million tuples in one table, indexing over 90k URLs) and the server has been running flawlessly for the past ~14days now, and what is only because that was the last time we rebooted it ... > > The second is the very VERY important instability problem. > I explain me better: I've tried Postgres on different systems > (redhat6.0,6.1, mandrake7.0) and every time after that I make start the > postmaster 20 or 30 times in a week or 2, it begin to have a problem > with shared memory, but i do an ipcclean and go..., after when > postmaster run without problems if I do a createuser (from sqladmin) or > a createdb (from user) it give me the same problem like: > > ------------------------------------------------ > FATAL 1: cannot create init file > mydatabasedirectory//base/mydb/pg_internal.init > ------------------------------------------------ > > it happens after few times of correct running... and persist also if I > recompile again postgresql > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Wed, 24 May 2000, The Hermit Hacker wrote: > On Wed, 24 May 2000, planx plnetx wrote: > > > I've remarked that postgresql-7.0 have two important bugs no, no... > > I'll define its Problems. > > > > The first is that it is very subsceptible to ipc: it's true that sometimes > > U need to do an ipcclean to remake it start > > This sounds like a Linux problem to me ... I've got v7.0 running on a > server over here that is dealign with the Search engine for the PostgreSQL > site (over 10million tuples in one table, indexing over 90k URLs) and the > server has been running flawlessly for the past ~14days now, and what is > only because that was the last time we rebooted it ... Ditto, except the uptime here (PostgreSQL running all the time taking care of user's mailboxes, web server, etc.): 265 days, 20:43 running FreeBSD-3.2-Rel. Vince. > > > > > > > The second is the very VERY important instability problem. > > I explain me better: I've tried Postgres on different systems > > (redhat6.0,6.1, mandrake7.0) and every time after that I make start the > > postmaster 20 or 30 times in a week or 2, it begin to have a problem > > with shared memory, but i do an ipcclean and go..., after when > > postmaster run without problems if I do a createuser (from sqladmin) or > > a createdb (from user) it give me the same problem like: > > > > ------------------------------------------------ > > FATAL 1: cannot create init file > > mydatabasedirectory//base/mydb/pg_internal.init > > ------------------------------------------------ > > > > it happens after few times of correct running... and persist also if I > > recompile again postgresql > > ________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
"planx plnetx" <planetx2100@hotmail.com> writes:
> FATAL 1: cannot create init file
> mydatabasedirectory//base/mydb/pg_internal.init
If you're getting that, there is something *seriously* broken ---
the only way that can come out is if Postgres is unable to create
that file when it wants to. I wonder if you are running the postmaster
as the wrong user (eg, one without write permission on the database
directories)? Another possibility is that you're running with an
incorrect database path (postmaster -D switch or PGDATA environment
setting). If that's an accurate transcription of the error message
then it looks like your path may be messed up...
regards, tom lane
The Hermit Hacker wrote: > > On Wed, 24 May 2000, planx plnetx wrote: > > > I've remarked that postgresql-7.0 have two important bugs no, no... > > I'll define its Problems. > > > > The first is that it is very subsceptible to ipc: it's true that sometimes > > U need to do an ipcclean to remake it start > > This sounds like a Linux problem to me ... I've got v7.0 running on a > server over here that is dealign with the Search engine for the PostgreSQL > site (over 10million tuples in one table, indexing over 90k URLs) and the > server has been running flawlessly for the past ~14days now, and what is > only because that was the last time we rebooted it ... We've been running 7.0 on a linux server since RC3 on a database with over 40 million tuples without this problem (all 40 million tuples are indexed on 3 fields). So I'm not sure I see how it can be concluded that this is a linux problem. > > The second is the very VERY important instability problem. > > I explain me better: I've tried Postgres on different systems > > (redhat6.0,6.1, mandrake7.0) and every time after that I make start the > > postmaster 20 or 30 times in a week or 2, it begin to have a problem > > with shared memory, but i do an ipcclean and go..., after when > > postmaster run without problems if I do a createuser (from sqladmin) or > > a createdb (from user) it give me the same problem like: > > > > ------------------------------------------------ > > FATAL 1: cannot create init file > > mydatabasedirectory//base/mydb/pg_internal.init > > ------------------------------------------------ > > > > it happens after few times of correct running... and persist also if I > > recompile again postgresql I just restarted a different server 50 consecutive times and I cannot reproduce this error either. (Both these are Redhat 6.2. We also have postgreSQL 7.0 running on a few Redhat 6.1 servers). Karl DeBisschop
The Hermit Hacker wrote: > > On Wed, 24 May 2000, Karl DeBisschop wrote: > > > The Hermit Hacker wrote: > > > > > > On Wed, 24 May 2000, planx plnetx wrote: > > > > > > > I've remarked that postgresql-7.0 have two important bugs no, no... > > > > I'll define its Problems. > > > > > > > > The first is that it is very subsceptible to ipc: it's true that sometimes > > > > U need to do an ipcclean to remake it start > > > > > > This sounds like a Linux problem to me ... I've got v7.0 running on a > > > server over here that is dealign with the Search engine for the PostgreSQL > > > site (over 10million tuples in one table, indexing over 90k URLs) and the > > > server has been running flawlessly for the past ~14days now, and what is > > > only because that was the last time we rebooted it ... > > > > We've been running 7.0 on a linux server since RC3 on a database with > > over 40 million tuples without this problem (all 40 million tuples are > > indexed on 3 fields). So I'm not sure I see how it can be concluded > > that this is a linux problem. > > Could his Linux server be mis-configured? Could be. But he said he installed separately on several installs - redhat 6.1, 6.2, and mandrake I believe. I don't think he indicated whether he used the RPMS or compiled himself. Assuming this is some sort of configuration issue, which seems sort of likely, it's at least as likely that it's related to a misunderstanding about how to cofigure postgreSQL. Since I can't reproduce the error, and since I'm only beginning to get familiar with little bits of the DBMS internals, I can't really help. But I did want to put my counter-example out there so that Linux users wouldn't get the sense that your fine product is somehow unreliable on Linux. IIRC, Linux is a large part of your installed base - no real point in scaring them off. Even if there are other legitimate arguments for other OS's. Karl DeBisschop
On Wed, 24 May 2000, Karl DeBisschop wrote: > The Hermit Hacker wrote: > > > > On Wed, 24 May 2000, Karl DeBisschop wrote: > > > > > The Hermit Hacker wrote: > > > > > > > > On Wed, 24 May 2000, planx plnetx wrote: > > > > > > > > > I've remarked that postgresql-7.0 have two important bugs no, no... > > > > > I'll define its Problems. > > > > > > > > > > The first is that it is very subsceptible to ipc: it's true that sometimes > > > > > U need to do an ipcclean to remake it start > > > > > > > > This sounds like a Linux problem to me ... I've got v7.0 running on a > > > > server over here that is dealign with the Search engine for the PostgreSQL > > > > site (over 10million tuples in one table, indexing over 90k URLs) and the > > > > server has been running flawlessly for the past ~14days now, and what is > > > > only because that was the last time we rebooted it ... > > > > > > We've been running 7.0 on a linux server since RC3 on a database with > > > over 40 million tuples without this problem (all 40 million tuples are > > > indexed on 3 fields). So I'm not sure I see how it can be concluded > > > that this is a linux problem. > > > > Could his Linux server be mis-configured? > > Could be. But he said he installed separately on several installs - > redhat 6.1, 6.2, and mandrake I believe. > > I don't think he indicated whether he used the RPMS or compiled himself. > Assuming this is some sort of configuration issue, which seems sort of > likely, it's at least as likely that it's related to a misunderstanding > about how to cofigure postgreSQL. > > Since I can't reproduce the error, and since I'm only beginning to get > familiar with little bits of the DBMS internals, I can't really help. > But I did want to put my counter-example out there so that Linux users > wouldn't get the sense that your fine product is somehow unreliable on > Linux. IIRC, Linux is a large part of your installed base - no real > point in scaring them off. Even if there are other legitimate arguments > for other OS's. no probs, I just wanted to point out the possibility that it was a server config issue, and not a postgresql one ... as I mentioned in another part of this thread, FreeBSD doesn't enable SharedMemory by default, so without a kernel build, you can't use PostgreSQL :(
Karl DeBisschop <kdebisschop@h00a0cc3b7988.ne.mediaone.net> writes:
> But I did want to put my counter-example out there so that Linux users
> wouldn't get the sense that your fine product is somehow unreliable on
> Linux. IIRC, Linux is a large part of your installed base - no real
> point in scaring them off. Even if there are other legitimate arguments
> for other OS's.
Marc is a bit of a FreeBSD partisan ;-). Don't worry about it.
I agree with your theory that there's some fundamental configuration
or installation error here --- but I don't see what it is, yet.
I suspect that "planx plnetx"'s native language is not English, and
so he might be missing some critical bit of information from the
documentation. If he'd tell us which language(s) he's more
comfortable in, perhaps there are speakers here who could help him.
regards, tom lane
On Wed, 24 May 2000, The Hermit Hacker wrote: > On Wed, 24 May 2000, planx plnetx wrote: > This sounds like a Linux problem to me ... I've got v7.0 running on a > server over here that is dealign with the Search engine for the PostgreSQL > site (over 10million tuples in one table, indexing over 90k URLs) and the > server has been running flawlessly for the past ~14days now, and what is > only because that was the last time we rebooted it ... And, likewise, I have experienced zero instability on RedHat Linux recently. (Well, since version 6.3.2, that is -- 6.2.1 was, well, not up to 7.0 standards -- but, that wasn't RedHat 4.1's fault (even though that particular RH Linux release STILL gives me the creeps....)). Check the hardware, too, as flakey cache SRAM chips can cause weird problems, as can flakey disk drive cabling (been there, done that with my development box...:-(.). Incidentally, I'm still overwhelmed with some of the questions and applications I get e-mailed to me about the RPMset. I guess the one that blew me over the most were the guys running Linux/390 who were having trouble installing the RPMset (that's Linux for IBM System 390 mainframes -- I _want_ to see THAT box benchmarked!). I told them that I hadn't a clue about that big iron -- but that I was very interested in the results! (which I haven't heard back from them -- maybe I should touch base...) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11