PostgreSQL 7.0 a success

First of all,
Let me say I dont have much experience with postgresql and I've
done only few tests, so excuse me for any wrong comments i make.

I think the following things should be improved in postgresql now:

- reliability
- Documentation

Sometimes a table doesnt exist anymore but it's still listed in
pg_class table, or the opposite, or you did a physical backup and you wanna
restore
the db, and other things that could be improved and more documented.

Some crashes we tested (like powering down the system while
running with flush off) were just fatal to some tables, and after restart
we got
the 'backend terminated...' message when trying to use the table.
We also tried a dump after restarting, but other processes that started
after the
dump were frozen, waiting for the dump to complete.

I also miss something like mysql's isamchk and a better control of the
security,
with 1 system table controlling passwords, hosts allowed and denied, and
anything
for the users of all databases.

just my 2 cents......

regards,

At 23:20 20/05/00 -0400, Bruce Momjian wrote:

PostgreSQL 7.0 has been a huge success. Bug reports since release have
been so few that we thought our e-mail system wasn't working properly.
Turns out things are very quiet because the release is so stable.

So, those people waiting on the fence to try 7.0, go ahead. It is
ready for prime-time.

Of course, we have big plans for 7.1, and will start on that shortly.

-- 
Bruce Momjian                        |  http://www.op.net/~candle
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

Gustavo Henrique Maultasch
gustavoh@sysadmin.com.br

On Wed, 24 May 2000, Gustavo Henrique wrote:

First of all,
Let me say I dont have much experience with postgresql and I've
done only few tests, so excuse me for any wrong comments i make.

I think the following things should be improved in postgresql now:

- reliability
- Documentation

Sometimes a table doesnt exist anymore but it's still listed in
pg_class table, or the opposite, or you did a physical backup and you
wanna restore the db, and other things that could be improved and more
documented.

example? some way to recreate for debugging?

Some crashes we tested (like powering down the system while running
with flush off) were just fatal to some tables, and after restart we
got the 'backend terminated...' message when trying to use the table.
We also tried a dump after restarting, but other processes that
started after the dump were frozen, waiting for the dump to complete.

operating system? I've had 'hard crashes' on my servers in the past, with
older versions of PostgreSQL, and not seen this :(

I also miss something like mysql's isamchk and a better control of the
security, with 1 system table controlling passwords, hosts allowed and
denied, and anything for the users of all databases.

pg_hba.conf?

On 5/24/00 7:53 PM -0300 gustavoh@sysadmin.com.br wrote:

First of all,
Let me say I dont have much experience with postgresql and I've
done only few tests, so excuse me for any wrong comments i make.
I think the following things should be improved in postgresql now:
- reliability
- Documentation

At 23:20 20/05/00 -0400, Bruce Momjian wrote:

So, those people waiting on the fence to try 7.0, go ahead. It is
ready for prime-time.

Of course, we have big plans for 7.1, and will start on that shortly.
Bruce Momjian | http://www.op.net/~candle

What I'd like to see would be a software RAID similar to what is in MySQL
3.23.x. That would be my only real feature request at this point.

--
Jeffrey H. Johnson - jeff@websitefactory.net - System Administration - TrN
Barnet Worldwide Enterprises - The Website Factory - www.websitefactory.net

On Wed, 24 May 2000, Jeffrey H. Johnson wrote:

What I'd like to see would be a software RAID similar to what is in MySQL
3.23.x. That would be my only real feature request at this point.

What for? If you use a free OS like xBSD or Linux, they have such
capabilities (ccd and md, respectively). If you use a commercial OS, you
either its already there (AIX) or you can buy it (Veritas for Solaris)

-alex

You can do software raid via the OS if you really want. In Linux your use
the mdtools package and the multiple device kernel options, on FreeBSD
there are two packages to do the same thing.

At 08:40 PM 5/24/00, Jeffrey H. Johnson wrote:

Sometimes a table doesnt exist anymore but it's still listed in
pg_class table, or the opposite, or you did a physical backup and you
wanna restore the db, and other things that could be improved and more
documented.

example? some way to recreate for debugging?

1. When you have created temp table and just killed frontend. Backend realize that connection
is broken and somehow did not remove the table from pg_class. Then it will exists on the disk
and in pg_class.
2. When you do operations with large objects (they are treated as relations also) and you do rollback
or again connect broken. Or you do lots of lo_unlink and rollback or just broke connection. Then it will
be in pg_class, but file will already be deleted. This can happend if you do big transaction with lo like:
select lo_unlink(lo) from lo_container; And you have more than 3000 large objects associated with
lo_container.lo.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Gustavo Henrique wrote:

First of all,
Let me say I dont have much experience with postgresql and I've
done only few tests, so excuse me for any wrong comments i make.

I think the following things should be improved in postgresql now:

- reliability

Have you had real reliability issues or theoretical ones ?

On what version ?

- Documentation

Could you be more specific ?

What is it you are missing in docs - maybe better organization ?

Sometimes a table doesnt exist anymore but it's still listed in
pg_class table, or the opposite,

Does it happen under normal use or must you do some of the dirty
tricks with "flush off" ?

or you did a physical backup and you wanna
restore the db, and other things that could be improved and more documented.

Some crashes we tested (like powering down the system while
running with flush off) were just fatal to some tables,

Yes with "flush off" they are supposed to be fatal.
Flush off is a performance hack for computers with UPSes.

I also miss something like mysql's isamchk

What does it do ?

and a better control of the security, with 1 system table
controlling passwords, hosts allowed and denied, and
anything for the users of all databases.

Currently this is held in pg_hba.conf mainly due to performance issues.

(IMHO these performance issues would really be an issue under DoS attack
;)

just my 2 cents......

Thanks!

--------
Hannu

Jeffrey H. Johnson wrote:

What I'd like to see would be a software RAID similar to what is in MySQL
3.23.x. That would be my only real feature request at this point.

Could you please explain this to some detail? Only databases
using RAW devices, on a per-OS specific implementation, could
implement RAID similar behaviour AFAIK. So which operating
systems (Vendor, Distibution and version, kernel-version) are
supported by MySQL WRT this feature by now?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Denis Perchine <dyp@perchine.com> writes:

example? some way to recreate for debugging?

1. When you have created temp table and just killed frontend. Backend
realize that connection is broken and somehow did not remove the table
from pg_class. Then it will exists on the disk and in pg_class.

Hmm. I said to myself "no way", and did "create temp table foo ..."
followed by killing psql from another window. By golly, the pg_temp
file was still there, and it was still listed in pg_class, just as you
said. But then I haven't been able to repeat it in quite a few tries.
So there's a bug there, but it's not too easy to reproduce. Do you
have any idea what contributing conditions might be involved?

2. When you do operations with large objects (they are treated as
relations also) and you do rollback or again connect broken. Or you do
lots of lo_unlink and rollback or just broke connection.

lo_unlink is not safe to rollback, any more than a plain drop table is.
This is a known deficiency and probably will be for a while. In the
meantime the standard advice is "don't do that".

regards, tom lane

1. When you have created temp table and just killed frontend. Backend
realize that connection is broken and somehow did not remove the table
from pg_class. Then it will exists on the disk and in pg_class.

Hmm. I said to myself "no way", and did "create temp table foo ..."
followed by killing psql from another window. By golly, the pg_temp
file was still there, and it was still listed in pg_class, just as you
said. But then I haven't been able to repeat it in quite a few tries.
So there's a bug there, but it's not too easy to reproduce. Do you
have any idea what contributing conditions might be involved?

I always get it when run vacuumlo from contribs on database with large (20000-30000)
number of LOs.

2. When you do operations with large objects (they are treated as
relations also) and you do rollback or again connect broken. Or you do
lots of lo_unlink and rollback or just broke connection.

lo_unlink is not safe to rollback, any more than a plain drop table is.
This is a known deficiency and probably will be for a while. In the
meantime the standard advice is "don't do that".

Actually this mean that postgres does not have safe support for BLOBs.
Hopefully tuple stuff will be in the next release. I've tested alpha patch and
it works quite fine except some queries was broken.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

On Thu, 25 May 2000 06:21:10 +0200 (MEST) Jan Wieck wrote:

Could you please explain this to some detail?

From the MySQL 3.23.16-alpha documentation:

For now the only allowed RAID_TYPE is STRIPED ... If you specify
RAID_TYPE=STRIPED for a MyISAM table, MyISAM will create
RAID_CHUNKS sub-directories named 00, 01, 02 in the database
directory. In each of these directories MyISAM will create an
table_name.MYD. When writing data to the data file, the RAID
handler will map the first RAID_CHUNKSIZE *1024 bytes to the first
file, the next RAID_CHUNKSIZE *1024 bytes to the next file and so
on.

I wouldn't call that RAID; it's missing "redundant". Being able to
exercise some control over the physical location of data to balance
I/O isn't a bad idea, but I doubt that it need be mixed up with RAID
concepts.

Only databases using RAW devices, on a per-OS specific
implementation, could implement RAID similar behaviour AFAIK.

Hmm? From some high level viewpoint RAID is spreading data around
multiple locations with sufficient redundancy that if one of those
locations disappears, the data is still able to be accessed.

I don't see how blocks-on-filesystems are inherently so different to
blocks-on-raw-devices that this redundancy is not at least
theoretically possible. Am I missing something?

My immediate reaction though is that RAID is better either done in
hardware, or integrated with the OS kernel where it is easier to get
real status information from devices. Trying to build an application
that can cope with filesystems disappearing out from under it would be
very challenging, particularly for an application that has to be
portable.

Regards,

Giles

JanWieck@t-online.de (Jan Wieck) writes:

Do you mean the TOAST snapshot I provided?

No, he's just griping about the fact that manipulating many thousand
Large Objects in one transaction stresses the system unpleasantly.
(Too many table locks grabbed is the usual killer, I think.) TOAST
should eliminate those problems.

regards, tom lane