Possible bug in postgresql-7.1.3-1PGDG

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

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

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

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