>>> On Fri, Feb 24, 2006 at 5:25 pm, in message
<[EMAIL PROTECTED]>,
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> Having it build with PGXS would be a definite plus for ease of
> installation.
It does.
---(end of broadcast)---
TIP 1: if posti
Kevin Grittner wrote:
> I've not dealt with pgfoundry before, so I don't know how much
> modification, if any, is needed to set that up. It's working for us now
> by building in standard contrib fashion (from contrib/fsutil). The
> files:
Having it build with PGXS would be a definite plus for e
>>> On Fri, Feb 24, 2006 at 5:00 pm, in message
<[EMAIL PROTECTED]>, "Jim C. Nasby"
<[EMAIL PROTECTED]>
wrote:
> Oh, so does it actually involve any server modifications? Or can it
just
> go into pgfoundry?
No server modifications. I've got it bundled up as though it were
going to be under cont
Oh, so does it actually involve any server modifications? Or can it just
go into pgfoundry?
On Fri, Feb 24, 2006 at 08:25:03AM -0600, Peter Brant wrote:
> The code in question is written as C extension functions. I think we
> were thinking it might be something for contrib (although perhaps that
>
Ühel kenal päeval, R, 2006-02-24 kell 19:20, kirjutas Csaba Nagy:
> On Fri, 2006-02-24 at 19:12, Rod Taylor wrote:
> > On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote:
> > > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > > I watch for table bloat but I haven't figured out a nice way of tracking
> >
On Fri, 2006-02-24 at 19:20 +0100, Csaba Nagy wrote:
> On Fri, 2006-02-24 at 19:12, Rod Taylor wrote:
> > On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote:
> > > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > > I watch for table bloat but I haven't figured out a nice way of tracking
> > > > down the
On Fri, 2006-02-24 at 19:12, Rod Taylor wrote:
> On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote:
> > Rod Taylor <[EMAIL PROTECTED]> writes:
> > > I watch for table bloat but I haven't figured out a nice way of tracking
> > > down the postgresql process with the oldest transaction running short o
On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > I watch for table bloat but I haven't figured out a nice way of tracking
> > down the postgresql process with the oldest transaction running short of
> > patching PostgreSQL to report the XID for a conne
Rod Taylor <[EMAIL PROTECTED]> writes:
> I watch for table bloat but I haven't figured out a nice way of tracking
> down the postgresql process with the oldest transaction running short of
> patching PostgreSQL to report the XID for a connection in
> pg_stat_activity.
I don't think you need a patc
> > I'm curious as to how you monitor for total transaction time length
> to
> > ensure that vacuum is able to do its thing, particularly when the
> > transaction is active (not IDLE).
>
> We run a database vacuum nightly and review it the next day.
Ahh.. different issues again I guess.
I have
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> We haven't used tablespace features yet, as 3 of the 4 databases
> running PostgreSQL so far are on Windows. We have run out of space a
> couple times, and it seems like it handles it well in terms of not
> corrupting the database, and resuming OK onc
>>> On Fri, Feb 24, 2006 at 10:57 am, in message
<[EMAIL PROTECTED]>,
Rod Taylor <[EMAIL PROTECTED]> wrote:
>
> PostgreSQL seems to deal with out of diskspace situations pretty
well
> when it impacts a tablespace (global stuff like WAL or
subtransactions
> have issues -- but they grow slowly) as
On Fri, 2006-02-24 at 09:48 -0600, Kevin Grittner wrote:
> >>> On Fri, Feb 24, 2006 at 9:34 am, in message
> <[EMAIL PROTECTED]>,
> Rod Taylor <[EMAIL PROTECTED]> wrote:
> >
> > You don't need to know the free diskspace in real time. A 2 minute
> old
> > value is probably just as good.
>
> Not
>>> On Fri, Feb 24, 2006 at 9:34 am, in message
<[EMAIL PROTECTED]>,
Rod Taylor <[EMAIL PROTECTED]> wrote:
>
> You don't need to know the free diskspace in real time. A 2 minute
old
> value is probably just as good.
Not really, this sort of monitoring has kept us from crashing under our
old dat
Kevin Grittner wrote:
Since we have what we need to get our work done, and the community at
large doesn't seem interested, I'll shelve the idea of submitting
anything.
I think you have misinterpreted. By all means share the code. Put it on
your website or start a pgfoundry project. Even i
> > This seems an area where providing consistent cross- platform
> behavior
> > might be difficult. Do we actually need this functionality inside the
>
> > DBMS in the first place?
>
> It sounds like we should probably just shelve the idea of sharing this
> code. It is very useful to us, since
>>> On Thu, Feb 23, 2006 at 8:43 pm, in message
<[EMAIL PROTECTED]>,
Neil Conway <[EMAIL PROTECTED]> wrote:
> Kevin Grittner wrote:
>> Peter Brant, a consultant working with us, has written code which
is
>> working for this under both Linux and Windows. [...] For Linux, he
>> used statvfs.
>
>
The code in question is written as C extension functions. I think we
were thinking it might be something for contrib (although perhaps that
would be too much of an official blessing too?)
Pete
>>> "Jim C. Nasby" <[EMAIL PROTECTED]> 02/24/06 8:04 am >>>
Isn't this something that could be accompli
On Thu, Feb 23, 2006 at 11:32:05PM -0500, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Do we actually need this functionality inside the
> > DBMS in the first place?
>
> I think that is the $64 question. My immediate instinct is "no".
> See the knock-down-drag-out fights we had
Neil Conway <[EMAIL PROTECTED]> writes:
> Do we actually need this functionality inside the
> DBMS in the first place?
I think that is the $64 question. My immediate instinct is "no".
See the knock-down-drag-out fights we had last summer about whether
to expose any filesystem access in built-in
Kevin Grittner wrote:
Peter Brant, a consultant working with us, has written code which is
working for this under both Linux and Windows. [...] For Linux, he
used statvfs.
statvfs(2) is standardized, but doesn't seem portable: it isn't
available on OSX 10.3, NetBSD 2.0 or OpenBSD, for example
Kevin Grittner wrote:
So, my questions:
(1) Did I miss something regarding mingw support for statvfs?
(2) If not, is it acceptable for a source file to contain that much
#if code for Windows?
I should probably also ask a tertiary question. His implementation
reports space in 1K increments
Kevin Grittner wrote:
(2) If not, is it acceptable for a source file to contain that much
#if code for Windows?
Large chunks of platform-specific code usually go in src/port
100 lines for a WIN32 piece would not be out of order there.
If that proves difficult, let us see the mods and
As part of integrating PostgreSQL into our production environment, we're
working on monitoring software, to provide the same kinds of status
reporting and alerts we have implemented for our outgoing commercial
database product. One of the things we show on our "big board" is
impending failure cond
24 matches
Mail list logo
