Re: Concerns about this release

>>>Don Baccus said:> > It also means that the PostgreSQL hackers can say that their database is> > ready for 24x7
operationin "the default" mode.> > > Plenty of people already run it 24x7.
 

I guess many do, actually. With the old (existing) code. I used to run most of 
my production systems with beta code years ago - as at that time PostgreSQL 
was beta quality anyway :) - but I currently run 7.0 on such systems, planning 
an upgarde to 7.1 anytime now - actually, the delay is because I need to shut 
down that large 24x7 setup!
> 2. outer joins didn't change the semantics of existing queries.  You can>     write queries you couldn't write
before,but your old queries work>     without change.
 

Not true!

SQL that worked in 7.0 does not work always in 7.1. Arguably, that can be 
explained by 'bad SQL', but does not change the fact.

The default SQL inheritance also makes things much, much different. Let me 
explain with this 'intuitive' schema:

CREATE TABLE maillog (from    text,to    text,msgdate    datetime,msgid    text,bytes    int
);

Now this is the 'current' log data, and we need to archive it periodically, to 
keep the old data and at the same time avoid unnecessary performance decrease. 
So we create archive tables like this

CREATE TABLE maillog200101 () INHERITS (maillog);
CREATE TABLE maillog200102 () INHERITS (maillog);

Data gets there by

INSERT INTO maillog200101 SELECT * FROM maillog WHERE msgdate >= '2001-01-01' 
and msgdate < '2001-02-01';
DELETE FROM maillog WHERE msgdate >= '2001-01-01' and msgdate < '2001-02-01';

etc.

One of the reasons in doing this is that the archive creation software needs 
not know the exact structure of the table it archives...

Under 7.0 everything is as expected. Under 7.1 when you SELECT from maillog, 
you also select from all inherited tables, which is not expected. One can of 
course rewrite all the SELECTs :-)

Sorry for the off-topic, but this hit me badly :)
> 4. WAL was a scary change due to the scope, but it didn't change the>     semantics of transactions.

But it was discussed many, many times before being implemented. 
> 5. The semantics of VACUUM have changed.  Silently (in the sense that>     there's no notification or warning spewed
out).

You argue with Tom here, but both of you go call the same beast differently.
Sure, semantics of the 'VACUUM' command has changed. The old semantics is now 
available as 'VACUUM FULL' - as it was already commented, this is no worry for 
new users. The new semantics of VACUUM may actually be an improvement, because 
many people need to run VACUUM in order to update statistics. The only benefit 
I see from VACUUM FULL is disk space usage reduction - which most 
administrators do not do as default action (that is, rarely in scripts).

If free heap is reused in both tables and indexes, I do not see much trouble 
in the new semantics, especially for 24x7 setups! Tables, that are used for 
'logs' always grow - if you take my example above, given you have ca 1 million 
records a month, after the first month the maillog table is supposed to 
contain 1 million records, then those get deleted and the new tuples will 
occupy another 1 million records disk space... now given that we archive the 
old data and not just throw it away, if free space reuse is available, the 
maillog table will never grow more than 2 million records in size, which is 
reasonable. With the old vacuum semantics, the vacuuming of such tables is 
expensive (as they usually have indexes) and the saved disk space is not 
significant.
> I think the new VACUUM is a great thing, and frankly I don't care all > that much about the VACUUM FULL command
issue. I tend to take the view > that command semantics shouldn't be changed if one can avoid it.  It's a > view built
onthe fact that about twenty years of my past life were > spent as a language implementor and dealing with customer
feedbackwhen > I've been foolish enough to make semantics changes of this sort.
 

I fully agree with this.

However, what I think Tom had not said in his defense is that the new VACUUM 
semantics is expected to greatly improve the experience with PostgreSQL. As 
such, NEW users are more likely to appreciate it. More users = more found bugs 
= better PostgreSQL (perhaps other benefits :) It may also be an improvement 
for true 24x7 setups - users of my PostgreSQL powered company management 
database start to complain when i do VACUUM during the day, as table locking 
is 'freezing' for example cash register operation, and 'people in the queue 
are waiting' etc ;)
> > Bring it on!  I have good backups :).> > > Uh ... if you're truly 24x7 critical then rolling back to your last >
backupwouldn't cut it, I'd think  ...
 

Ah... backups.. and they also load back so slow :)


Daniel