PostgreSQL 7.5?

csn

Now that PG 7.4 is in RC, any idea what's on the menu for 7.5? All I know is that a native Windows port will probably be a goal.

LordShryku

I hope so. I love using Postgres, but on my Windows machines, I'm stuck with MySQL. Don't get me wrong...MySQL ain't bad....I just miss Postgres on those machines.

Sxooter

Things being worked that may or may not be in 7.5:

Point in time recovery
Native Windows port
Much less aggresive background vacuuming (insertint some usleep() statements every x blocks) for better 24/7 operation
fixes for making int8 types use indexes by default without extra handling. Especially important for people working with JDBC applications, where queries are often built by the application many layers deep from human interaction, and simple fixes are harder to apply.

Sxooter

Oh, another feature that may be getting into 7.5 would be background fsm maintenance on pages that are in buffer (i.e. really cheap top lazy vacuum and toss into the fsm.)

Also, it looks like ERserver is getting quite a workout, so it's likely to move closer and closer to inclusion, but not likely to be core by 7.5.

Also, it looks like a first stab at 2 or 3 phase commit may make it into the 7.5 branch, which will be a nice answer for certain enterprise replication / load balanced applications.

csn

Sxooter-

Point in time recovery

That's not "time-travel" (rollback db to a certain point in time) is it?

fixes for making int8 types use indexes by default without extra handling.

What extra handling is there (currently)?

What's fsm? File System M....? 😉

.. 2 or 3 phase commit ...

Is that nested transactions?

Sxooter

Originally posted by csn
Sxooter-

Point in time recovery

That's not "time-travel" (rollback db to a certain point in time) is it?

fixes for making int8 types use indexes by default without extra handling.

What extra handling is there (currently)?

What's fsm? File System M....? 😉

.. 2 or 3 phase commit ...

Is that nested transactions?

PITR is close to time travel, but more oriented towards recovery. Basically, it allows you to make a backup on say, Sunday, then store all the transactions after that. Then, should something horrible befall your database, you can restore from Sunday's backup, then roll forward all the transaction logs up to a certain point in time. It also acts as a nice underlying mechanism for lazy / async replication.

The extra handling is basically a few minor hacks to things like JBoss CMP (connection management pooling or something like that) lib that adds ' marks around numbers in the where clause so that postgresql will coerce them to match the proper index type (i.e. int8/int2).

fsm is free space map. It's a map of free space in the database tables that vacuum fills up when run in lazy mode (i.e. plain vacuums, not vacuum full) which the database can then use again. What they're looking at doing is having a built in lazy vacuum process that runs in the background and harvests free pages only in pages that are currently in the buffer. This is cheap to do since it involves no I/O.

2 or 3 phase commit is a way of performing distributed transactions wherein a master db server initiates the transaction, then sends a copy of it to another server (it's slave) which then either commits it or not, and the master can be programmed to handle slave failure in many ways.

It basically is a way of providing replication / high reliability in certain environments.