Here is the announcement for everyone to review, enjoy and click on the CFP link:

Following on the smashing success of PostgreSQL Conference East, PostgreSQL Conference West, The PostgreSQL Conference for Decision Makers, End Users and Developers, is being held at the Sir Francis Drake Hotel in San Francisco from November 2nd through 4th 2010. Please join us in making this the largest PostgreSQL Conference to date!

      * General PostgreSQL: 
              * Administration 
              * Performance 
              * High Availability 
              * Migration 
              * GIS 
              * Integration 
              * Solutions and White Papers 
      * The Stack: 
              * Python/Django/Pylons/TurboGears/Custom 
              * Perl5/Catalyst/Bricolage 
              * Ruby/Rails 
              * Java (PLJava would be great)/Groovy/Grails 
              * Operating System optimization
                (Linux/FBSD/Solaris/Windows) 
              * Solutions and White Papers 

This is my first post on Replicator, I'm going to start by describing the terminology we use, bringing some analogies from other replication systems.

Replicator is an asynchronous master-to-multiple-slaves replication system. It works by propagating binary changes from a single read-write node (called master) to one or more read-only nodes (called slaves) through an intermediary (forwarder) process. The data changes are stored in binary transaction files on a per-transaction basis. Additionally, each file contains a list of replication tables the data belongs to. Every slave has a distinct set of tables to replicate. Finally, transaction files are addressed by a special data structure called replication queue.

After connecting to the forwarder for the first time each slave node performs an initial sync (full dump) by requesting a complete up-to-date snapshot of replication tables. The forwarder doesn't necessarily resend such request to a master process. Instead, it checks the queue for past full dumps and reuses them if appropriate.

To reduce the bandwidth and disk space consumption per each slave the set of tables replicated by the slave is compared with the set of current transaction's tables, and the forwarder decides to send a transaction to the slave only when these 2 sets intersects; thus, each slave receives data only for those tables it replicates. So far, there was an important exception to this rule: full dump transactions were always sent to every slave. The original justification for this was the fact that full dump was required after addition of a new replicated table, and every slave had to be aware of this addition.

In 1.8 we introduced a new feature called 'per-table dumps', which allowed a slave to request a snapshot of a single table, instead of requesting a full dump. Currently, when a new table is added to the replication, only a single per-table dump is requested, and there's no need for a full dump. This made possible for a slave to 'skip' a full dump, and changes committed last week implement exactly this: if the slave is in sync (i.e. doesn't wait for a dump, or recovering from an error), the forwarder just skips sending full dump transactions to this slave, therefore avoiding most bandwidth-consuming transactions. It's a clear win!

Additionally there is another related positive change. When a slave restores full dump transaction it replaces the data of each replicated table with the one from the dump, leaving the table inconsistent for some period of time (which is usually short, but depends on table size and other factors). By reducing the average number of dumps per each slave we also reduced the number of these 'inconsistency gaps'. Double win!

The next version, 1.9, is still in development. We put it (as well as other open-source projects) on github, so you are welcome to check it out and join the replicator mailing list.

Stay tuned for further updates!

How do deal with disagreement about the deliverable:

This is an interesting one. I wanted to keep FOSSExperts simple. That is why the deliverable on the ALTER TABLE project is simple, committed to PostgreSQL Core.

That may not work in all circumstances. So I am considering one of two options. The first option is courtesy of Josh Berkus. The idea would be to have a board of people that determine whether or not the deliverable has been met. This has merit because you have a panel of experts that make the determination. It can make the review process painless but is also takes the power out of both the funders and developers.

The second one is to take a vote. It would work something like this.

• Developer states project is complete and demonstrates completeness based on the deliverable.
  
• Every person who funded the project votes on whether or not the project is complete.
  • If 66% vote the project complete, developer gets their money.
    
  • If less than 66% vote project incomplete, developer doesn't get their money.
    

  There would have to be some caveats. First the funders need to be able to communicate with the developer because they may not have understood part of the spec. Further as we are working with Open Source, the end deliverable may have been changed based on the will of the community versus the developer (see the Hot Standby work with PostgreSQL).

  The voting would also need to be limited to a period of time. I was thinking 14 days. The 66% would be tallied against those that voted in that 14 days.

  I like this idea because it removes the third party and it stops a single funder from calling foul as they are part of a collective vote. What do you think?
  

Remember a lot of your questions can be answered in the FAQ as well.

FOSSExperts is a new site specifically engineered to allow FOSS developers to raise money for projects they are trying to develop. The idea stemmed from the very cool Kickstarter. With our focus obviously being on a different kind of creative.

This is long overdue in the FOSS Community. There are a great deal of communities out there (LedgerSMB for example) that can use a place for their developers to try and raise funds for a specific feature. LedgerSMB just recently had a discussion on developing a Payroll module. Developing a Payroll module will be expensive for a single small company to absorb, but 20 small companies? Not nearly as expensive.

What FOSSExperts is not, is a place to send money to global projects such as Debian or PostgreSQL.org. It is for specific, well defined proposals and has a specific and defined delivery as well as refund policies etc.

Right now, we are in closed Beta. If you have a project or proposal you would like to try out you need to email me directly but we are interested. So take a look, and let the rage begin! If you like, you can review one of the larger proposals already on the site as well.

This is generously borrowed from the PostgreSQL Docs, and updated to something that represents a modern approach to PostgreSQL backups. This documentation has always bothered me because it should have been re-written years ago. Yes I plan on submitting a more comprehensive version as a patch but I don't have time to push it into DocBook right now. If someone else wants to grab it, please do.

Yes, I really do believe the use of plain text backups is a mistake. Yes I realize PostgreSQL has the limitation of not being able to backup the cluster in anyway but plain text.

pg_dump dbname > outfile

pg_dump -U $username --format=c --file=$mydatabase.sqlc $dbname

 -U, --username=NAME      connect as specified database user
 -F, --format=c|t|p       output file format (custom, tar, plain text)
 -f, --file=FILENAME      output file name

pg_restore -U $username --dbname=$dbname --index=$indexname

pg_restore -U $username --dbname=$dbname --function=$functionname(args)

pg_restore -U $username --dbname=$dbname --table=$tablename

pg_restore -U$username --dbname=$databasename $filename

Do not confuse --file with $filename. The --file option is used to turn a custom format backup into a plain text backup. The value of --file will be used as the output file for that transformation.

psql $dbname < $backupfile

pg_dumpall -g -U$username --file=$globals.sql; 
psql -AtU postgres -c "SELECT datname FROM pg_database \
                          WHERE NOT datistemplate"| \
while read f; 
   do pg_dump -Upostgres --format=c --file=$f.sqlc $f;
done;

Remember, pg_dumpall creates a plain text backup. This means you will need to use psql to restore the globals backup file.

psql -U postgres;
create user one with encrypted password 'foo';
create user two with encrypted password 'bar'
create user three with encrypted password 'baz';

create database drupal;
\c drupal -- (assumes the use of psql)
create schema one authorization one;
create schema two authorization two;
create schema three authorization three;

alter user one set search_path = 'one';
alter user two set search_path = 'two';
alter user three set search_path = 'three';

alter table one.users set schema public;
alter table one.sessions set schema public;

create role drupal user one,two,three;
alter table users owner to drupal;
alter table sessions owner to drupal;
grant insert,update,delete on users to drupal;
grant insert,update,delete on sessions to drupal;

$db_prefix = array('users' => 'public.',
                 'sessions' => 'public.',);

Then on Monday I received notice, the hotel acquisitions team (EDB) has received an amazing counter offer from a competing hotel.

The hotel is still in San Francisco, it is a four star hotel and the rate is much better for attendees (159.00 vs. 199.00). Here is the catch, which if you are reading on Planet you have to wait until after the jump.... Read more...

$ easy_install Simpycity

Disparate Representations

Forging Anew

class model(ctx.Model()):
     table = ['id','name']
     __load__ = ctx.Function("load_obj", ['id'])

class model(ctx.Model()):
...

new = ctx.Function("new_obj",['name'], return_type=model)

import yourmodel
o = yourmodel.new("Some name")
o.commit()

Twisty Little Properties

aModel.comments

    from simpycity.helpers import prop
    
    class myTextObject( ctx.Model() ):
        table = ['id', 'value']
        __load__ = ctx.Function("textobject.by_id",['id'])
        comments = prop( get=ctx.Function("textobject.comments", ['id']) )
        
    mto = myText(1)
    comments = mto.comments

    from simpycity.helpers import sprop
    
    class myTextObject( ctx.Model() ):
        ...
        comments = property(sprop( get=ctx.Function("textobject.comments", ['id']) ))

Next