On Tue, 2007-10-30 at 00:48 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > What I'd like to do is force all of the RMs to record the lsn of any WAL
> > record that starts an incomplete action.
> > ...
> > I'd like to suggest that those changes be performed now for 8.3 *and*
>
"Meredith L. Patterson" <[EMAIL PROTECTED]> writes:
> In brief, when installing on OS X with "make install-strip",
> installation goes fine, but initdb dies here:
> ...
> I see three possible fixes:
> 1) Patch config/install-sh such that on OS X, install-strip calls 'strip
> -x'. This removes loc
Simon Riggs <[EMAIL PROTECTED]> writes:
> What I'd like to do is force all of the RMs to record the lsn of any WAL
> record that starts an incomplete action.
> ...
> I'd like to suggest that those changes be performed now for 8.3 *and*
> back-patched for 8.2.
There is zero chance of the former and
Hi all,
Three years ago, Andrew MacRae logged the following bug:
http://archives.postgresql.org/pgsql-bugs/2004-02/msg00042.php
In brief, when installing on OS X with "make install-strip",
installation goes fine, but initdb dies here:
creating conversions... ERROR: could not load library
"/
On Mon, Oct 29, 2007 at 07:32:11PM -0300, Alvaro Herrera wrote:
> Gregory Stark wrote:
> > "Hannu Krosing" <[EMAIL PROTECTED]> writes:
> >
> > > What I was referring to, was a "code cleanup" of libpq several
> > > years ago, when someone (maybe Bruce IIRC) removed ability to
> > > accept multiple
We've had two hard to diagnose errors in recovery in recent months. ISTM
that the core issue is the way we allow Resource Managers to have
multi-stage WAL actions that persist for long periods of time. This
means we have no way of telling whether the answer
rm_safe_restartpoint() == false is a mome
Josh Berkus wrote:
Not only would they be generally useful for SP programming, but multisets
would eliminate one of the big hurdles in re-writing T-SQL stored
procedures in PG, and thus make it easier to port from SQL Server. You
don't hear a lot of demand for multisets on the mailing lists be
Gregory Stark wrote:
> "Hannu Krosing" <[EMAIL PROTECTED]> writes:
>
> > What I was referring to, was a "code cleanup" of libpq several years
> > ago, when someone (maybe Bruce IIRC) removed ability to accept multiple
> > recordsets from backend altogether, on the basis that it is not used
> > any
"Hannu Krosing" <[EMAIL PROTECTED]> writes:
> What I was referring to, was a "code cleanup" of libpq several years
> ago, when someone (maybe Bruce IIRC) removed ability to accept multiple
> recordsets from backend altogether, on the basis that it is not used
> anyway.
You can still receive multi
Ühel kenal päeval, L, 2007-10-27 kell 14:10, kirjutas David Fetter:
> On Sun, Oct 28, 2007 at 12:05:26AM +0300, Hannu Krosing wrote:
> > Ühel kenal päeval, L, 2007-10-27 kell 12:55, kirjutas Josh Berkus:
> > > Merlin, Pavel,
> > >
> > > > Mutable session variables would be nice, but I'll take a p
On Mon, 2007-10-29 at 17:34 -0300, Alvaro Herrera wrote:
> Maybe hack the postmaster to have a new special connection mode which
> keeps the connection open until the startup process exits, to avoid
> polling continuously (ideally report progress too, if at all
> possible).
That sounds good to me
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I think the mythical pg_ping utility should be written. It seems the
> easiest way out of the problem.
If pg_ctl were still a shell script there would be some point in that,
but since it's a C program it can certainly do anything a separate
utility wou
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> How about an environment variable to control the timeout? Is that
>> cleaner?
> I don't see why it should be. I think Peter's --timeout suggestion
> should be just fine.
I wrote a moment ago that the user can hit control-C whe
Peter Eisentraut wrote:
> Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
> > I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
> > sometimes just times out and there is no way to make it wait a little
> > longer. I would like to add an option to be able to change tha
Bruce Momjian wrote:
How about an environment variable to control the timeout? Is that
cleaner?
I don't see why it should be. I think Peter's --timeout suggestion
should be just fine.
cheers
andrtew
---(end of broadcast)---
TIP 4: Hav
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Somehow, the 60 second timeout seems completely arbitrary anyway. Maybe we
> should remove it altogether. We could add an option as described above, but
> then the packager who creates the init script or whoever creates the initial
> configuration
Peter Eisentraut wrote:
> Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
> > I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
> > sometimes just times out and there is no way to make it wait a little
> > longer. I would like to add an option to be able to change tha
> --- Original Message ---
> From: Peter Eisentraut <[EMAIL PROTECTED]>
> To: pgsql-hackers@postgresql.org
> Sent: 29/10/07, 17:54:00
> Subject: Re: [HACKERS] pg_ctl configurable timeout
>
> Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
> > I'm having trouble with the hardcoded 6
Or ... ask the application not the OS
psql> select version() ;
Cheers
Medi
On 10/29/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>
> Leaving aside the question of why one might want to do this, Unix 101
> should show you many ways to do it. For example,
>
> sed -n -e 's/.*PG_VERSION /PG
On Mon, 2007-10-29 at 14:20 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > One minor thing: I think it's still dependent on locale though, because
> > the output of pg_controldata is locale-dependent, right? It would work
> > fine for me, but it would be nice if there was somet
Jeff Davis <[EMAIL PROTECTED]> writes:
> One minor thing: I think it's still dependent on locale though, because
> the output of pg_controldata is locale-dependent, right? It would work
> fine for me, but it would be nice if there was something that could be
> released that anyone could use, includ
>>> On Mon, Oct 29, 2007 at 11:50 AM, in message
<[EMAIL PROTECTED]>, Jeff Davis <[EMAIL PROTECTED]>
wrote:
> Also, did you publish your pg_clearxlogtail program anywhere? I think
> that would be helpful to many people, but I don't see it on pgfoundry.
So far I've just included with the email o
Am Freitag, 17. August 2007 schrieb Peter Eisentraut:
> I'm having trouble with the hardcoded 60 second timeout in pg_ctl. pg_ctl
> sometimes just times out and there is no way to make it wait a little
> longer. I would like to add an option to be able to change that, say
> pg_ctl -w --timeout=120
On Mon, 2007-10-29 at 09:56 -0500, Kevin Grittner wrote:
> Here's our script:
Thanks, I think that is better than what I'm doing.
One minor thing: I think it's still dependent on locale though, because
the output of pg_controldata is locale-dependent, right? It would work
fine for me, but it woul
On Fri, Oct 26, 2007 at 10:39:12PM -0400, Greg Smith wrote:
> There's a couple of potential to-do list ideas that build on the changes
> in this area in 8.3:
I think that's the right way to go. It's too bad that this may still
happen in 8.3, but we're way past the point that this is a bug fix,
I
>>> On Fri, Oct 26, 2007 at 6:28 PM, in message
<[EMAIL PROTECTED]>, Jeff Davis <[EMAIL PROTECTED]>
wrote:
> [ of course, there's no guarantee that the archive_command succeeds in
> that time ]
Which is one of the things we would want to cause an alert.
-Kevin
-
>>> On Fri, Oct 26, 2007 at 6:39 PM, in message
<[EMAIL PROTECTED]>, Jeff Davis <[EMAIL PROTECTED]>
wrote:
> On Fri, 2007-10-26 at 18:06 -0500, Kevin Grittner wrote:
>> Hmmm... We would actually prefer to get the WAL file at the
>> specified interval. We have software to ensure that the warm
>>
Leaving aside the question of why one might want to do this, Unix 101
should show you many ways to do it. For example,
sed -n -e 's/.*PG_VERSION /PG_VERSION /p' -e /PG_VERSION/q config.log
Please don't cross-post questions like this, especially when it's not
really a PostgreSQL question at a
Hi All,
I am giving the command
cat config.log|grep -w 'PG_VERSION'
Which gives the following Output:
| #define PG_VERSION "8.3beta2"
| #define PG_VERSION "8.3beta2"
| #define PG_VERSION "8.3beta2"
| #define PG_VERSION "8.3beta2"
| #define PG_VERSION "8.3beta2"
| #define PG_VERSION "8.3beta2
LS,
I don't know if this is the right mailing list to post my request. But here
it goes. PostgreSQL has greatly support for data types inet and cidr. But so
far I haven't been able to figure out how one would convert a ip/netmask
(what one will find on a network card) pair into a network cidr.
I'
* Joshua D. Drake:
> If you need obfuscation (and you don't, you just think you do, no
> offense) use C.
Or put the relevant code into some package/module/whatever, stored on
the file system, and include that.
--
Florian Weimer<[EMAIL PROTECTED]>
BFK edv-consulting GmbH ht
* Tom Lane:
> I am fairly sure that this bug explains problems previously reported
> by Merlin Moncure:
> http://archives.postgresql.org/pgsql-general/2006-10/msg01312.php
> and Florian Weimer:
> http://archives.postgresql.org/pgsql-general/2006-11/msg00305.php
> In both those cases, off-list inve
Andrew Dunstan wrote:
>
>
> Gaetano Mendola wrote:
>> hubert depesz lubaczewski wrote:
>>
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
>> it seems that the stats collector on my box is using more CPU than
>> it did in the past.
>>
Magnus Hagander wrote:
> Gaetano Mendola wrote:
>> hubert depesz lubaczewski wrote:
>>> On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
>>> it's well known bug, and it was fixed in 8.2.
Gaetano Mendola wrote:
hubert depesz lubaczewski wrote:
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
it seems that the stats collector on my box is using more CPU than
it did in the past.
it's well known bug, and it was fixed in 8.2.4:
http://www.post
Gaetano Mendola wrote:
> hubert depesz lubaczewski wrote:
>> On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
>>> it seems that the stats collector on my box is using more CPU than
>>> it did in the past.
>> it's well known bug, and it was fixed in 8.2.4:
>> http://www.postgresql.or
hubert depesz lubaczewski wrote:
> > On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
>> >> it seems that the stats collector on my box is using more CPU than
>> >> it did in the past.
> >
> > it's well known bug, and it was fixed in 8.2.4:
> > http://www.postgresql.org/docs/current
hubert depesz lubaczewski wrote:
> On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
>> it seems that the stats collector on my box is using more CPU than
>> it did in the past.
>
> it's well known bug, and it was fixed in 8.2.4:
> http://www.postgresql.org/docs/current/interactive/
On Mon, Oct 29, 2007 at 09:52:24AM +0100, Gaetano Mendola wrote:
> it seems that the stats collector on my box is using more CPU than
> it did in the past.
it's well known bug, and it was fixed in 8.2.4:
http://www.postgresql.org/docs/current/interactive/release-8-2-4.html
...
Prevent the statisti
Gaetano Mendola wrote:
> Hi all,
> it seems that the stats collector on my box is using more CPU than
> it did in the past.
This is a known bug that was fixed in 8.2.4, so you need to upgrade.
//Magnus
---(end of broadcast)---
TIP 7: You can help
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
it seems that the stats collector on my box is using more CPU than
it did in the past.
This is what I'm observing:
CPU usage for the stat process: 25% flat
$ psql -c "select version()"
version
41 matches
Mail list logo
