Thread: PostgreSQL 7.0 a success
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
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: >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 >
> > 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
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 ----------------------------------
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