Re: [ADMIN] A couple of errors encountered in 7.1.3=>7.2.1-2 data migration

[Ray Ontko]

Tom, et al,

> > ERROR:  cannot find attribute 1 of relation schedule_notification_log
> 
> This is more disturbing.  Can you provide the sequence of commands that
> led up to it?

Here are a few related datapoints.  

1) We think that schedule_notification_log is the only table that 
we loaded from the dump that had _no_ rows in it.

2) We encountered the same "cannot find attribute" error when doing 
something like this:

develop=# create table temp_event as select * from event ;
...
develop=# \d temp_event
 Table "temp_event"
 Attribute | Type | Modifier
---+--+--

develop=# select count(*) from temp_event ;
ERROR:  cannot find attribute 1 of relation temp_event
develop=# drop table temp_event ;
ERROR:  cannot find attribute 1 of relation temp_event

Note that "event" has plenty of rows.  It may be our only table
that includes the INTERVAL datatype.

BTW, How do I get rid of temp_event?

So: Is there something about a table that might cause it to NOT
load correctly?  Is there something about a table that might 
cause it to not copy correctly (using create as select * from )?

Ray
--
Ray Ontko   [EMAIL PROTECTED]   Phone 1.765.935.4283   Fax 1.765.962.9788
Ray Ontko & Co.   Software Consulting Services   http://www.ontko.com/

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Re: [ADMIN] VACUUM FULL

[Brian McCane]

On Sun, 12 May 2002, Dan Langille wrote:

>
> On 12 May 2002 at 12:49, Brian McCane wrote:
>
> > I am on FreeBSD 5.0.
>
> There is a reason why you must be on 5.0?  That is not recommended for
> "sane" people.
>
> 5.0 is -current and not the best place to be running important
> applications  At present 5.0 is -current, which is the version which
> changes daily.  It's really only for people who are developing FreeBSD.
> It frequently contains works in progress and experimental changes.
>
> see 
> --
> Dan Langille
> The FreeBSD Diary - http://freebsddiary.org/ - practical examples
>
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

Trust me, I am fully aware of this :)  I have been running BSD on my
machine Since Bill and his wife announed the release of 386BSD 0.1 in an
article in (I think) Dr. Dobbs.  I tend to pick and choose my times when I
upgrade my OS, and the version I am now running is several months old.
When I see a new feature I like/need, and have seen no major complaints in
a while, I back up a week and grab a copy.  Unfortunately, it has been a
while since I have been able to do this.

My experience has always been that the current is usually stable if you
are careful and don't get too exotic.  Also, it tends to have much better
performance, once you turn off all the debugging/monitoring code in the
kernel, then the older releases.  In addition, whenever they fix possible
DOS attacks, etc, they are implemented there first.  At one point I needed
these because of a DOS attack that was hitting my machines.

have fun,

- brian

Wm. Brian McCane| Life is full of doors that won't open
Search http://recall.maxbaud.net/   | when you knock, equally spaced amid those
Usenet http://freenews.maxbaud.net/ | that open when you don't want them to.
Auction http://www.sellit-here.com/ | - Roger Zelazny "Blood of Amber"


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

[ADMIN] help me out on installation!!!

[Tao Wan]

Hi, all,

I am installing postgresql-7.1.2  on Linux 2.4.12.  I did configure
with only one option --prefix= when I did make ( I am using
gnu make 3.78.1 and gcc 2.95.2), I got errors below:

...
gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations command.o
common.o help.o input.o stringutils.o mainloop.o copy.o startup.o
prompt.o variables.o large_obj.o print.o describe.o tab-complete.o
-L../../../src/interfaces/libpq -lpq
-Wl,-rpath,/home/grad4/tawan/pgsql/lib -lcrypt -lresolv -lnsl -ldl -lm
-lhistory  -o psql
/local/gcc-2.95.2/lib/libhistory.a(histfile.o): In function
`read_history_range':
/usr/include/sys/stat.h:161: undefined reference to `_fxstat'
/local/gcc-2.95.2/lib/libhistory.a(histfile.o): In function
`history_truncate_file':
/usr/include/sys/stat.h:161: undefined reference to `_fxstat'
collect2: ld returned 1 exit status
make[3]: *** [psql] Error 1
make[3]: Leaving directory
`/home/grad4/tawan/cs589/postgresql-7.1.2/src/bin/psql'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/home/grad4/tawan/cs589/postgresql-7.1.2/src/bin'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/grad4/tawan/cs589/postgresql-7.1.2/src'
make: *** [all] Error 2

I have no idea to figure it out. Hope you can help me out. Thanks

tony


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[ADMIN] upgrade?

[Jodi Kanter]

We are still running 7.1.3. Can anyone 
highlight the big differences or reasons to upgrade? Is there some documentation 
on this?
Thanks
Jodi


___Jodi 
L KanterBioInformatics Database AdministratorUniversity of 
Virginia(434) 924-2846[EMAIL PROTECTED]
 
 
 

Re: [ADMIN] VACUUM FULL

[Dan Langille]

On 13 May 2002 at 8:20, Brian McCane wrote:

> On Sun, 12 May 2002, Dan Langille wrote:
> 
> >
> > On 12 May 2002 at 12:49, Brian McCane wrote:
> >
> > > I am on FreeBSD 5.0.
> >
> > There is a reason why you must be on 5.0?  That is not recommended for
> > "sane" people.
> >
> > 5.0 is -current and not the best place to be running important
> > applications  At present 5.0 is -current, which is the version which
> > changes daily.  It's really only for people who are developing FreeBSD.
> > It frequently contains works in progress and experimental changes.

> Trust me, I am fully aware of this :)  I have been running BSD on my
> machine Since Bill and his wife announed the release of 386BSD 0.1 in an
> article in (I think) Dr. Dobbs.  I tend to pick and choose my times when I
> upgrade my OS, and the version I am now running is several months old.
> When I see a new feature I like/need, and have seen no major complaints in
> a while, I back up a week and grab a copy.  Unfortunately, it has been a
> while since I have been able to do this.

You are clearly qualified ;)

Too frequently we see people who jump into -current not knowing what they 
are getting into.

Personally, I have too many other things to do to attempt -current.
-- 
Dan Langille
The FreeBSD Diary - http://freebsddiary.org/ - practical examples


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [ADMIN] help me out on installation!!!

[Tom Lane]

Tao Wan <[EMAIL PROTECTED]> writes:
> I am installing postgresql-7.1.2  on Linux 2.4.12.

Just out of curiosity, why aren't you installing 7.2.1?

Even if you have some reason to want to use a 7.1.* release, 7.1.3
would be the preferred choice.

Dunno about the _fxstat problem.  Looking at /usr/include/sys/stat.h,
it seems that Linux is playing some weird games to try to achieve
binary compatibility, and this is falling down for some reason.
You'd probably be better off asking about it on a Linux-related list
(especially considering that the problem seems to be in libhistory.a,
and thus is not anything directly related to Postgres at all).

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [ADMIN] upgrade?

[Tom Lane]

Jodi Kanter <[EMAIL PROTECTED]> writes:
> We are still running 7.1.3. Can anyone highlight the big differences or rea=
> sons to upgrade? Is there some documentation on this?

The release notes always mention the main improvements.  Quoting from
http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/release.html:


Major changes in this release: 

VACUUM

 Vacuuming no longer locks tables, thus allowing normal user access during the 
vacuum. A new VACUUM FULL
 command does old-style vacuum by locking the table and shrinking the on-disk copy 
of the table. 

Transactions

 There is no longer a problem with installations that exceed four billion 
transactions. 

OID's

 OID's are now optional. Users can now create tables without OID's for cases where 
OID usage is excessive. 

Optimizer

 The system now computes histogram column statistics during ANALYZE, allowing much 
better optimizer choices. 

Security

 A new MD5 encryption option allows more secure storage and transfer of passwords. 
A new Unix-domain socket
 authentication option is available on Linux and BSD systems. 

Statistics

 Administrators can use the new table access statistics module to get fine-grained 
information about table and
 index usage. 

Internationalization

 Program and library messages can now be displayed in several languages. 


regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

[ADMIN] unregister steven@tie.cl

[Steven Cuthbertson]

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Re: [ADMIN] upgrade?

[Gareth Kirwan]

Yes there is 
documentation, yes there are changes.
if you're happy 
with what you're on, don't bother.
The main change I 
noticed was that it no longer allows the illegal syntax of  = 
NULL
( I KNOW I KNOW, 
but I liked using it! :p)
 
 
From the History 
file in Redhat RPM documentation for 7.2
 
Overview
 
   This 
release improves PostgreSQL for use in high-volume 
applications.
 
   
Major changes in this release:
 
   
VACUUM
 
   Vacuuming no 
longer locks tables, thus allowing normal user 
access   during 
the vacuum. A new "VACUUM FULL" command does 
old-style   vacuum 
by locking the table and shrinking the on-disk copy of 
the   
table.
 
   
Transactions
 
   There is no 
longer a problem with installations that exceed 
four   billion 
transactions.
 
   
OID's
 
   OID's are 
now optional. Users can now create tables without 
OID's   for cases 
where OID usage is excessive.
 
   
Optimizer
 
   The system 
now computes histogram column statistics 
during   
"ANALYZE", allowing much better optimizer choices.
 
   
Security
 
   A new MD5 
encryption option allows more secure storage 
and   transfer of 
passwords. A new Unix-domain socket 
authentication   
option is available on Linux and BSD systems.
 
   
Statistics
 
   
Administrators can use the new table access statistics module 
to   get 
fine-grained information about table and index usage.
 
   
Internationalization
 
   Program and 
library messages can now be displayed in 
several   
languages.
 
 
--
 
Migration to 
version 7.2
 
   A 
dump/restore using "pg_dump" is required for those wishing to 
migrate   data from any previous release.
 
   
Observe the following incompatibilities:
 
 * The semantics of the "VACUUM" command have 
changed in this release.   You may wish to 
update your maintenance procedures accordingly.
 
 * In this release, comparisons using = NULL will 
always return false (or   NULL, more 
precisely). Previous releases automatically 
transformed   this syntax to IS NULL. The 
old behavior can be re-enabled using a   
"postgresql.conf" parameter.
 
 * The "pg_hba.conf" and "pg_ident.conf" 
configuration is now only   reloaded after 
receiving a SIGHUP signal, not with each connection.
 
 * The function "octet_length()" now returns the 
uncompressed data   
length.
 
 * The date/time value 'current' is no longer 
available. You will need to   rewrite your 
applications.
 
 * The timestamp() function is no longer 
available.  Use timestamp   'string' 
instead, or CAST.
 
   The 
SELECT ... LIMIT #,# syntax will be removed in the next release. 
You   should change your queries to use separate LIMIT and OFFSET 
clauses, e.g.   LIMIT 10 OFFSET 20.

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Jodi 
  KanterSent: 13 May 2002 15:39To: Postgres Admin 
  ListSubject: [ADMIN] upgrade?
  We are still running 7.1.3. Can anyone 
  highlight the big differences or reasons to upgrade? Is there some 
  documentation on this?
  Thanks
  Jodi
  
  
  ___Jodi 
  L KanterBioInformatics Database AdministratorUniversity of 
  Virginia(434) 924-2846[EMAIL PROTECTED]
   
   
   

[ADMIN] root account needed??

[Tao Wan]

Hi, all,

just wonder whether I a root account required to install pgSql on Linux?

Thanks

Tony



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Re: [ADMIN] configure datatype name > 31?

[Tom Lane]

"Mark McEahern" <[EMAIL PROTECTED]> writes:
> Tom, thanks for your reply.  I am now able to create databases and users
> with longer names, but I am unable to login with the long username.

I think you're stuck on that, unless you want to be *really*
incompatible with the rest of the world.  The startup packet format has
hard-wired field sizes --- see src/include/libpq/pqcomm.h:

#define SM_DATABASE 64
#define SM_USER 32
#define SM_OPTIONS  64
#define SM_UNUSED   64
#define SM_TTY  64

Don't ask me why SM_USER is different from the rest :-(

If you change these I'd strongly advise bumping the protocol minor
version number, so that you don't have weird behavior should you try
to interoperate with standard code.

This is another thing that should be on the list of stuff to fix when
we next change the FE/BE protocol ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])

Re: [ADMIN] root account needed??

[Stephan Szabo]

On Mon, 13 May 2002, Tao Wan wrote:

> just wonder whether I a root account required to install pgSql on Linux?

You shouldn't need a root account to install from source, although you'll
almost certainly need to give a prefix to configure to put it in some
place the user has access to write to (since I believe the default is
/usr/local).


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]