pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Sim Zacks <sim@compulab.co.il>
To: pgsql-general@postgresql.org
Subject: Re: Using Postgresql as application server
Date: Wed, 17 Aug 2011 09:05:44 +0300
Message-ID: <4E4B5A38.20008@compulab.co.il> (raw)
In-Reply-To: <4E49B47E.8020401@ringerc.id.au>
References: <CAN2Y=uPjF14F5A9JXj02_vaPw4TMR0WGQid_w80xt4sC8o4qGg@mail.gmail.com>
	<4E46D0D7.3090700@officenet.no>
	<CAHyXU0xQp+-sA6-oPJVTYaFBYO_R4P=fnX+jm8Pgy_j0rPcO7Q@mail.gmail.com>
	<4E49B47E.8020401@ringerc.id.au>

On 08/16/2011 03:06 AM, Craig Ringer wrote:
> On 15/08/2011 10:36 PM, Merlin Moncure wrote:
>> On Sat, Aug 13, 2011 at 2:30 PM, Andreas Joseph Krogh
>> <andreak@officenet.no> wrote:
>>> No, PG has never, and will never, act as an application-server.
>> Why in the world not?
>
> The biggest reason is safety. Beyond that, the lack of autonomous
> transactions, stored procedures, in-DB timers, and support for any
> protocol other than the native Pg database query protocol mean it's also
> rather impractical.
>
> I guess theoretically one could embed a JVM / Python instance / whatever
> in the postmaster and have it spawn new backends for incoming
> connections with other protocols. But ... why? Why add all that
> complexity and - more importantly - contaiminate PostgreSQL's address
> space with more code that can fail when you don't have to? PLs and user
> C procedures are already risk enough as far as I'm concerned.
>

As I've mentioned in other posts, we are using postgresql as a hybrid 
application server and have found it to be very practical and easy to 
code. For functions that need to run on a regular basis, we use a cron 
job, though from what I understand pgAgent should be able to handle that 
just as well.  Instead of using Listen/Notify to tell an application to 
send e-mails, we have an email function written in plpython that sends 
the email directly.
The reason to do this is because it gives you "write once" code which 
makes your application pretty much client-agnostic.

PG already spawns a new backend for each connection. So your specialized 
code has little chance of hosing the whole database.

We connect to other databases when we need to, mostly mysql using the 
MySQLdb python module, to move data to and from our website.

Scalability would be increased with multi-master replication, which 
bucardo currently does (I haven't tested it yet).

One issue you have is using database style hardware for application 
server needs, which may be more expensive.




view thread (88+ messages)  latest in thread

Message-ID: <4E4B5A38.20008@compulab.co.il>
Permalink:  ../4E4B5A38.20008@compulab.co.il/
Also on:    postgresql.org/message-id/4E4B5A38.20008@compulab.co.il

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: sim@compulab.co.il, pgsql-general@postgresql.org
  Subject: Re: Using Postgresql as application server
  In-Reply-To: <4E4B5A38.20008@compulab.co.il>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox