Robert Treat wrote:
The problem is that PostgreSQL is moving out of the realm of hard-core
geeks only and more into the mainstream. I'd bet a number of our users
have very little idea how autoconf and it's progeny work. It's probably
not unlikely that those folks would be able to figure out
hai, will it be possible to use one server for Process and another server
for Reports. We are using Postgresql as database and java
- Sivakumar
_
NRIs Zero balance Account. FREE Money Transfers with FREE DVD
On Sun, Apr 02, 2006 at 11:26:52PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
I have no objection to doing that, so long as you are actually doing it
correctly. This example shows that each jail must have its own
On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
If this is the story, then FBSD have broken their system and must revert
their change. They do not have kernel behavior that totally
On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
I venture that FBSD 6 has decided to return ESRCH (no such process)
where FBSD 4 returned some other error that acknowledged that the
process did exist (EPERM would be a reasonable guess).
If this is the story, then FBSD have broken
On Sun, Apr 02, 2006 at 11:41:01PM -0400, Kris Kennaway wrote:
On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
'k, but how do I fix kill so that it has the proper behaviour if SysV is
enabled?
Check the source, perhaps there's already a way. If not, talk to
whoever
On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
On Sun, 2 Apr 2006, Kris Kennaway wrote:
On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
If this is the story, then
On Mon, 3 Apr 2006, Stephen Frost wrote:
So I think the code is pretty bulletproof as long as it's in a system that
is behaving per SysV spec. The problem in the current FBSD situation is
that the jail mechanism is exposing semaphore sets across jails, but not
exposing the existence of the
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is why it's disabled by default, and the jail documentation
specifically advises of this possibility. Excerpt below.
Ah, I see, glad to see it's accurately documented.
As it has been for the last five years, I believe since introduction of the
On Sun, 2 Apr 2006, Tom Lane wrote:
Oops. Here is the problem: kill() is lying by claiming there is no such
process as 83699. It looks to me like there in fact is such a process, but
it's in a different jail.
I venture that FBSD 6 has decided to return ESRCH (no such process) where
FBSD
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson [EMAIL PROTECTED] writes:
Maybe I've misunderstood the problem here -- is the use of the GETPID
operation occuring within a coordinated set of server processes, or does it
also occur between client and server processes? I think it's quite
On Mon, 3 Apr 2006, Tom Lane wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a postmaster process is terminated
unexpectedly (ye olde
On Mon, Apr 03, 2006 at 06:51:45PM -0400, Stephen Frost wrote:
* Robert Watson ([EMAIL PROTECTED]) wrote:
On Mon, 3 Apr 2006, Stephen Frost wrote:
This is certainly a problem with FBSD jails... Not only the
inconsistancy, but what happens if someone manages to get access to the
On Mon, 3 Apr 2006, Tom Lane wrote:
Robert Watson [EMAIL PROTECTED] writes:
Any multi-instance application that uses unvirtualized System V IPC must know
how to distinguish between those instances.
Sure.
How is PostgreSQL deciding what semaphores to use? Can it be instructed to
use
On Mon, Apr 03, 2006 at 03:42:51PM -0400, Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
That's a fair question, but in the context of the code I believe we are
behaving reasonably. The reason this code exists is to provide some
insurance against leaking semaphores when a
On 4/4/06, siva kumar [EMAIL PROTECTED] wrote:
hai, will it be possible to use one server for Process and another server
for Reports. We are using Postgresql as database and java
You surely can use two servers, but they cannot share the same data
cluster. You would have to replicate your
FYI, I have left SRA and am now working for EnterpriseDB:
http://www.enterprisedb.com/news_events/press_releases/04_04_06.do
I will be doing the same community work I did before, so my role in the
project will not change. (I will remain perpetually backlogged. :-) )
I will always be
Bruce Momjian wrote:
FYI, I have left SRA and am now working for EnterpriseDB:
http://www.enterprisedb.com/news_events/press_releases/04_04_06.do
Congratulations!
I will be doing the same community work I did before, so my role in the
project will not change. (I will remain
Bruce,
On 4/4/06 5:06 PM, Bruce Momjian pgman@candle.pha.pa.us wrote:
I am also looking forward to working with EnterpriseDB on new projects
and opportunities.
Congrats!
- Luke
---(end of broadcast)---
TIP 1: if posting/reading through
Hi all,
I think I've found the cause (or one of the causes) why stats
collection is unreliable on Windows and I'm wondering about the best way
to go about fixing it.
The problem is that process IDs on Windows seem to be assigned without
much rhyme or reason and it seems to happen relatively
On Apr 4, 2006, at 10:39 , Tom Lane wrote:
So there's no additional risk --- in fact, arguably having such a
function crash during normal input of NULL would be a Good Thing,
because it would make it far more likely that the mistake would get
noticed and fixed before someone used it as a form
I'm glad to see work being done on domains. I'm definitely learning from
the discussion.
I wonder if we should implement 'GRANT USAGE ON DOMAINS' for spec
compliance sometime...
Chris
---(end of broadcast)---
TIP 3: Have you checked our
Michael Glaesemann [EMAIL PROTECTED] writes:
Granted, finding an error earlier than later is a Good Thing, but an
Even Better Thing would be to prevent crashing the backend, and
afaics (as far as that is) the change you propose doesn't hurt
anything. Do you see any way to do that?
For
On Apr 5, 2006, at 11:46 , Tom Lane wrote:
For starters we'd have to forbid any user-written C functions.
Somehow that doesn't seem like a net win.
Ouch.
Michael Glaesemann
grzm myrealbox com
---(end of broadcast)---
TIP 2: Don't 'kill -9'
Peter Brant [EMAIL PROTECTED] writes:
I think I've found the cause (or one of the causes) why stats
collection is unreliable on Windows and I'm wondering about the best way
to go about fixing it.
The problem is that process IDs on Windows seem to be assigned without
much rhyme or reason and
Tom Lane [EMAIL PROTECTED] wrote
The problem is that process IDs on Windows seem to be assigned without
much rhyme or reason and it seems to happen relatively frequently that a
new process will be assigned the same process ID as a process which
recently died.
That's an interesting theory,
Tom Lane [EMAIL PROTECTED] wrote
Redmond crowd should be able to figure out that recycling process IDs
instantly would be a stupid idea...)
Can you explain more of this? IMHO, if we rely on feature like this, the
difference is unstable-every-day vs. unstable-every-year.
Regards,
Qingqing
Qingqing Zhou [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote
Redmond crowd should be able to figure out that recycling process IDs
instantly would be a stupid idea...)
Can you explain more of this? IMHO, if we rely on feature like this, the
difference is unstable-every-day vs.
I've recently been playing with table partitioning limitations. Turning
over a large volume of data in inherited structures in a live
environment, and have run into a couple of snags in the planner.
The first is that LEFT JOIN will always do a sequential scan on all
inherited tables.
The second
Rod Taylor [EMAIL PROTECTED] writes:
I've recently been playing with table partitioning limitations. Turning
over a large volume of data in inherited structures in a live
environment, and have run into a couple of snags in the planner.
The first is that LEFT JOIN will always do a sequential
On Tue, 2006-04-04 at 23:50 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
I've recently been playing with table partitioning limitations. Turning
over a large volume of data in inherited structures in a live
environment, and have run into a couple of snags in the planner.
Folks,
I've been warned that Summer of Code is coming up again soon. We need to be
ready with proposals which are officially endorsed by the PostgreSQL project.
Which means we need:
a) Projects which could be accomplished in a summer, and
b) Students to do them.
We have one or two weeks to
Tatsuo,
I'm wondering if this was approved or not...
We haven't approved *anything* yet. The deadline was just Saturday, and I'm
still keying stuff into the conference management system.
--
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
33 matches
Mail list logo
