Postgres 8.0 windows processes, field testing, and Hibernate

Scott Goldstein wrote:

I had a couple of questions about Postgres 8.0 on Windows platforms:

1. Has Postgres 8.0 seen many field deployments yet? What have been
the results?

There seems to have been a good take-up. Some people will have been
deploying it even before the official release. Accurate numbers are
obviously hard to come by, but I'd guess we've had more new users this
release than any previous I can recall.

2. When running a test against Postgress, I noticed in the Windows
task manager that several postgres.exe processes we're created. What
controls the number? Why more than one?

You will have (assuming the same as on *nix):
1. Master process - starts all the others
2. One backend per client
3. Stats buffer/collector
4. Auto-vacuum (optional, not really part of the main system yet)

This provides good separation between different elements, in case of
bugs/crashes. Your postgresql.conf controls how many clients can connect
and hence how many processes.

3. Has anyone tried to integrate Hibernate with Postgres 8.0?

Don't know about on Windows, but we seem to get questions regarding
Hibernate on the list. It seems to generate some quite clumsy SQL from
time to time, but I must admit I've never used it myself.

Helpful?
--
Richard Huxton
Archonet Ltd

Scott Goldstein <sgoldstein@apache.org> writes:

I had a couple of questions about Postgres 8.0 on Windows platforms:

1. Has Postgres 8.0 seen many field deployments yet? What have been the
results?

I have 8.0.2 in production with zero problems. It's not a high-load
installation but it's been completely solid.

2. When running a test against Postgress, I noticed in the Windows task
manager that several postgres.exe processes we're created. What controls
the number? Why more than one?

Postgres is a multiprocess database, not multithread. So you will get
a Postgres.exe process for each connection.

3. Has anyone tried to integrate Hibernate with Postgres 8.0?

Our production system uses Hibernate with 8.0 and the corresponding
JDBC driver--no problems at all.

-Doug

Richard Huxton wrote:

You will have (assuming the same as on *nix):
1. Master process - starts all the others
2. One backend per client
3. Stats buffer/collector
4. Auto-vacuum (optional, not really part of the main system yet)

It appears that, when started as a Windows service, four backend processes
(postgres.exe) are started even though there are no clients yet. Is this simply
to avoid backend process creation time for the first few clients? Out of
curiosity, is this approach also used on *nix?

A pg_ctl.exe is also running. I presume that is the one that starts the
postmaster and then sits and waits for a signal to shutdown the service?

Joe

On Fri, Jun 24, 2005 at 04:00:36PM -0400, Joe wrote:

Richard Huxton wrote:

You will have (assuming the same as on *nix):
1. Master process - starts all the others
2. One backend per client
3. Stats buffer/collector
4. Auto-vacuum (optional, not really part of the main system yet)

It appears that, when started as a Windows service, four backend processes
(postgres.exe) are started even though there are no clients yet.

They likely belong to the stats collector process, the stats buffer
process, the background writer process, and one postmaster to rule them
all. They are all launched from the same postgres.exe executable.

Is this simply to avoid backend process creation time for the first
few clients?

No, we don't do that.

Out of curiosity, is this approach also used on *nix?

Yes.

A pg_ctl.exe is also running. I presume that is the one that starts the
postmaster and then sits and waits for a signal to shutdown the service?

Probably.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
Jude: I wish humans laid eggs
Ringlord: Why would you want humans to lay eggs?
Jude: So I can eat them