Thread: Possible bug in postgresql-7.1.3-1PGDG
I've tried upgrading the installation on our RH 6.2 network from 7.1.0 to
7.1.3 by rebuilding the source rpm. All this goes well, but when I try to
start the postmaster (as user 'postgres') I see this error:
[postgres@salmo rshepard]$ postgres -D /var/lib/pgsql/data/
FATAL 2: open("/var/lib/pgsql/data//global/pg_control") failed: No such
file or directory
I don't understand the double forward slash, however, pg_control _is_ in
/var/lib/pgsql/data.
What might you suggest I do to to get past this problem of getting the
postmaster running again so postgres is usable here?
I did see a reference -- somewhere -- saying that this was a known upgrade
bug and the web sites had a solution. But, I can't find that solution when I
go looking for it.
Many thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
Rich Shepard <rshepard@appl-ecosys.com> writes:
> [postgres@salmo rshepard]$ postgres -D /var/lib/pgsql/data/
> FATAL 2: open("/var/lib/pgsql/data//global/pg_control") failed: No such
> file or directory
> I don't understand the double forward slash, however, pg_control _is_ in
> /var/lib/pgsql/data.
Well, I can explain that: it's because you have an unnecessary ending
slash in your -D parameter. The code just concatenates "/global/pg_control"
to whatever you typed.
However, I doubt that saying
postgres -D /var/lib/pgsql/data
will help --- every Unix I've ever dealt with treats two consecutive
slashes the same as one, just because it makes it a lot easier to be
sloppy about building pathnames ...
> I did see a reference -- somewhere -- saying that this was a known upgrade
> bug and the web sites had a solution.
Doesn't ring a bell with me offhand. Can you find that reference again?
regards, tom lane
On Thu, 18 Oct 2001, Rich Shepard wrote:
> I've tried upgrading the installation on our RH 6.2 network from 7.1.0 to
> 7.1.3 by rebuilding the source rpm. All this goes well, but when I try to
> start the postmaster (as user 'postgres') I see this error:
>
> [postgres@salmo rshepard]$ postgres -D /var/lib/pgsql/data/
> FATAL 2: open("/var/lib/pgsql/data//global/pg_control") failed: No such
> file or directory
Are you really trying to run the postgres executable here, or postmaster?
You shouldn't try to run postgres directly, unless you only want a single
instance of the server backend running. Better to let postmaster handle
it. I think you want:
postmaster -D /var/lib/pgsql/data
Alternatively, you can set the environment variable PGDATA to the location
of your datastore, and you don't to set the -D option.
> I don't understand the double forward slash, however, pg_control _is_ in
> /var/lib/pgsql/data.
I think it prepends the slash by default, and you had specified the data
directory with a trailing slash.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
Peace be to this house, and all that dwell in it.
On Thu, 18 Oct 2001, Tom Lane wrote:
> Well, I can explain that: it's because you have an unnecessary ending
> slash in your -D parameter. The code just concatenates "/global/pg_control"
> to whatever you typed.
Tom,
OK, a slip of the fingers. But, ... there's no global/ in my installation.
the file is in /var/lib/pgsql/data, not /var/lib/pgsql/data/global. I think
_that's_ where the problem be.
> > I did see a reference -- somewhere -- saying that this was a known upgrade
> > bug and the web sites had a solution.
>
> Doesn't ring a bell with me offhand. Can you find that reference again?
Mumble, mumble, mumble ... OK. I'll look Friday if I can make the time.
Oh, ... it was in the README.rpm (or some README file of similar name) that
still had a reference in it to 7.1.2.
HTH,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
On Thu, 18 Oct 2001, Brett W. McCoy wrote:
> Better to let postmaster handle it. I think you want:
>
> postmaster -D /var/lib/pgsql/data
Brett,
Just in case I mis-typed at the command line, I just tried the above. Same
error: cannot find database system (in /var/lib/pgsql/data, where it is)
and failed looking for /var/lib/pgsql/data/global/pg_control.
The problem is that the file, pg_control is in /var/lib/pgsql/data. There
is no global/ directory.
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
Rich Shepard <rshepard@appl-ecosys.com> writes:
> The problem is that the file, pg_control is in /var/lib/pgsql/data. There
> is no global/ directory.
Hm, you sure this was a 7.1 release system you are upgrading from?
That sounds more like 7.0.
If it was 7.0, you'll have to reinstall the 7.0 code long enough to
do a pg_dumpall. You can't update from 7.0 to 7.1 without
dump/initdb/reload, I'm afraid.
regards, tom lane
On Thu, 18 Oct 2001, Rich Shepard wrote:
> Just in case I mis-typed at the command line, I just tried the above. Same
> error: cannot find database system (in /var/lib/pgsql/data, where it is)
> and failed looking for /var/lib/pgsql/data/global/pg_control.
>
> The problem is that the file, pg_control is in /var/lib/pgsql/data. There
> is no global/ directory.
There should be! Are you sure you are using 7.1.3? It sounds like the
data directory didn't get upgraded properly.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
The Beatles:
Paul McCartney's old back-up band.
On Fri, 19 Oct 2001, Brett W. McCoy wrote:
> There should be! Are you sure you are using 7.1.3? It sounds like the
> data directory didn't get upgraded properly.
Brett,
I am no longer sure what's installed. When I look at
/var/lib/pgsql/data/base/PG_VERSION I see '7.1.2'. But, I ran 'rpm -Uvh ...'
for the 7.1.3 upgrade (rather than a freshen).
No data worth saving now, I've been consumed with too many other projects.
But, I have both business and scientific databases I need to build so I want
to get 7.1.3 correctly installed and working; I'll keep current after that.
Should I move configuration files (such as pg_hba.conf) to a safe area,
then manually delete all references to postgres that locate and find reveal,
before starting from scratch?
Right now I'm looking to get a working installation of 7.1.3 so I can
start developing these applications.
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
On Fri, 19 Oct 2001, Rich Shepard wrote:
> Should I move configuration files (such as pg_hba.conf) to a safe area,
> then manually delete all references to postgres that locate and find reveal,
> before starting from scratch?
A good idea. I usually back up all of my databases (if required) and
configuration data before running an installation (I build PostgreSQL from
source only), then replace after I am done upgrading.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
Why does a ship carry cargo and a truck carry shipments?
On Fri, 19 Oct 2001, Brett W. McCoy wrote:
> A good idea. I usually back up all of my databases (if required) and
> configuration data before running an installation (I build PostgreSQL from
> source only), then replace after I am done upgrading.
Brett,
Thanks. Other than pg_hdb.conf, what files do I save?
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
On Fri, 19 Oct 2001, Rich Shepard wrote:
> Thanks. Other than pg_hdb.conf, what files do I save?
Save all of your conf files, and probably pg_control & pgpasswd also. If
you have data, you should also do a database dump so you can restore it.
Take a look at the administrator's manual also. It has more details on
what config stuff is there and in what files.
-- Brett
http://www.chapelperilous.net/
------------------------------------------------------------------------
All is well that ends well.
-- John Heywood
On Fri, 19 Oct 2001, Brett W. McCoy wrote:
> Save all of your conf files, and probably pg_control & pgpasswd also. If
> you have data, you should also do a database dump so you can restore it.
OK. Makes sense.
> Take a look at the administrator's manual also. It has more details on
> what config stuff is there and in what files.
Excellent reminder! I forgot about that.
Thanks,
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
> On Fri, 19 Oct 2001, Brett W. McCoy wrote: > > > A good idea. I usually back up all of my databases (if required) and > > configuration data before running an installation (I build PostgreSQL from > > source only), then replace after I am done upgrading. > > Brett, > > Thanks. Other than pg_hdb.conf, what files do I save? Postgresql.conf? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
I don't think you have to start from scratch. Fair warning "I'm a newbie". Since you don't care about the old data I'd just create a new location setup. "initdb -D /usr/pgsql/data" I believe this create a new setup for your data. Of course you will have to change the start up location in the start up scripts. If you are using 7.1 RH I think the start up script is in "/etc/rc.d/init.d" I hope this helps. John "Rich Shepard" <rshepard@appl-ecosys.com> wrote in message news:Pine.LNX.4.33.0110190702590.13239-100000@salmo.appl-ecosys.com... > On Fri, 19 Oct 2001, Brett W. McCoy wrote: > > > There should be! Are you sure you are using 7.1.3? It sounds like the > > data directory didn't get upgraded properly. > > Brett, > > I am no longer sure what's installed. When I look at > /var/lib/pgsql/data/base/PG_VERSION I see '7.1.2'. But, I ran 'rpm -Uvh ...' > for the 7.1.3 upgrade (rather than a freshen). > > No data worth saving now, I've been consumed with too many other projects. > But, I have both business and scientific databases I need to build so I want > to get 7.1.3 correctly installed and working; I'll keep current after that. > > Should I move configuration files (such as pg_hba.conf) to a safe area, > then manually delete all references to postgres that locate and find reveal, > before starting from scratch? > > Right now I'm looking to get a working installation of 7.1.3 so I can > start developing these applications. > > Thanks, > > Rich > > Dr. Richard B. Shepard, President > > Applied Ecosystem Services, Inc. (TM) > 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. > + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com > http://www.appl-ecosys.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
On Fri, 19 Oct 2001, Bruce Momjian wrote:
> > Thanks. Other than pg_hdb.conf, what files do I save?
>
> Postgresql.conf?
Thanks, all! I removed everything below /var/lib/pgsql/data/ and (as
'postgres') ran initdb. Then, as root, I started postgresql. Now everything
_seems_ back to normal. But, I guess I have to download the latest
administrator's docs and read them.
The various PG_VERSION files report 7.1 and not the sub-minor number so
that's a change. Also, in /var/lib/pgsql/data/base/ I now have 2
directories, 1/ and 18719/ (the latter looks like a pid). Each of these has
a bunch of files with numbers for names. I don't recall ever seeing anything
like this so I have to figure out what's going on. Then, of course, I need
to set up some PGDATA environmental variables for the different databases.
For example, the accounting database will be in a completely different
directory from the scientific databases, and each of the latter I want in
the specific project data directory.
Whew! Glad I got my mess cleaned up. All my fault, of course.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
http://www.appl-ecosys.com
We have a number of tables which have unique id's generated from a sequence i.e. create table blat (id serial, ....) A number of these sequences seem to have been "set back" by 4 . In other words we have records for Id's 500, 501, 502, 503, and now the sequence is set to 500. The version of postgres is 7.0.3 running on RH 7.0. We have recently restarted the databases, and upgraded our glibc. Has anyone seen anything like this before? TIA, Dave
On Friday 19 October 2001 11:30 am, Rich Shepard wrote: > > Take a look at the administrator's manual also. It has more details on > > what config stuff is there and in what files. > Excellent reminder! I forgot about that. Sorry for the delay in replying, Rich. I've been out of town. If there's nothing worth saving, I would do the following to ensure a clean tree: (as root) 1.) Make sure no postmaster is running by using /etc/rc.d/init.d/postgresql stop 2.) Remove all postgresql rpms with rpm -e --force. The --force is to prevent other packages that depend upon postgresql from preventing the uninstall. 3.) rm -rf /var/lib/pgsql 4.) Reinstall with rpm -i all the postgresql rpms you rebuilt. 5.) Start postmaster with /etc/rc.d/init.d/postgresql start (which does an initdb for you, giving you a clean slate in /var/lib/pgsql.). Hope that helps! -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Friday 19 October 2001 11:38 am, John Fabiani wrote: > I don't think you have to start from scratch. Fair warning "I'm a newbie". > Since you don't care about the old data I'd just create a new location > setup. "initdb -D /usr/pgsql/data" I believe this create a new setup for > your data. Of course you will have to change the start up location in the > start up scripts. If you are using 7.1 RH I think the start up script is > in "/etc/rc.d/init.d" What you describe is more work than starting from scratch, at least on an RPM-based system. The RPM system handles getting everything created properly and in the 'right' place for future ease-of-use and upgrading. And Rich has replied that he now is Ok. Although the list delay means that you posted this before he posted his success message... :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Fri, 19 Oct 2001 13:15:38 -0400
"Dave Cramer" wrote:
> We have a number of tables which have unique id's generated from a
> sequence
>
> i.e. create table blat (id serial, ....)
>
> A number of these sequences seem to have been "set back" by 4 . In other
> words we have records for
>
> Id's 500, 501, 502, 503, and now the sequence is set to 500.
>
Hi,
How about using a CREATE SEQUENCE with a CYCLE option.
e.g.
create sequence seq_blat minvalue 500 maxvalue 503 cycle;
create table blat (id int4 default nextval('seq_blat'),
a varchar(10),
b varchar(10),
......
);
insert into blat (a, b, ...) values('aaa1', 'bbb1', .... );
insert into blat (a, b, ...) values('aaa2', 'bbb2', .... );
insert into blat (a, b, ...) values('aaa3', 'bbb3', .... );
...
By the way, a mail server has been downed ?
Regards,
Masaru Sugawara
How does this fix my problem?
It appears like the sequence was generated properly, but possible not
written to disk at shutdown time.
There is some additional information here. We did an upgrade of glibc
just before the restart
Dave
-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Masaru Sugawara
Sent: October 22, 2001 11:34 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Sequence problems during restart
On Fri, 19 Oct 2001 13:15:38 -0400
"Dave Cramer" wrote:
> We have a number of tables which have unique id's generated from a
> sequence
>
> i.e. create table blat (id serial, ....)
>
> A number of these sequences seem to have been "set back" by 4 . In
> other words we have records for
>
> Id's 500, 501, 502, 503, and now the sequence is set to 500.
>
Hi,
How about using a CREATE SEQUENCE with a CYCLE option.
e.g.
create sequence seq_blat minvalue 500 maxvalue 503 cycle; create table
blat (id int4 default nextval('seq_blat'),
a varchar(10),
b varchar(10),
......
);
insert into blat (a, b, ...) values('aaa1', 'bbb1', .... ); insert
into blat (a, b, ...) values('aaa2', 'bbb2', .... ); insert into blat
(a, b, ...) values('aaa3', 'bbb3', .... ); ...
By the way, a mail server has been downed ?
Regards,
Masaru Sugawara
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
On Mon, 22 Oct 2001 14:58:59 -0400 "Dave Cramer" <Dave@micro-automation.net> wrote: > How does this fix my problem? > > It appears like the sequence was generated properly, but possible not > written to disk at shutdown time. > > There is some additional information here. We did an upgrade of glibc > just before the restart > Hi, I took your words in the wrong sense, and gave an answer to your question of a method controlling the id like a cyclic sequence. If your problem seems to have been strongly caused by the upgrade of glibc, a re-install of the PG will lead to a desirable result. Sorry I couldn't help you. Regards, Masaru Sugawara