> >> 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.
>
> The mere existence of the k
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 broadcast)
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 g
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 plann
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 sequent
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 i
"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-e
"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,
Qin
"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 intere
"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 rea
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'
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?
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 extens
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 o
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 frequ
Bruce,
On 4/4/06 5:06 PM, "Bruce Momjian" 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 Usenet, please send an
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 per
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 gr
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 yo
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 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 non-
On Mon, 3 Apr 2006, Tom Lane wrote:
BTW, as long as we're annoying the freebsd-stable list with discussions of
workarounds, I'm wondering whether our shared memory code might have similar
risks. Does FBSD 6 also lie about the existence of other-jail processes
connected to a shared memory seg
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:
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 often-recommended
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 rea
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 4
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 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 o
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
https://www.onli
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
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
> whoe
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 bro
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
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 ha
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
35 matches
Mail list logo
