Actually, the more I look at it, I realize it was correct before
We want to link against readline.lib and history.lib, but the ones in
the GnuWin32 distribution are broken.
The .lib files are made from the .def files, which are supposed to list
the exports, but don't.
They can be made from
Hi everyone,
I was playing with converting unixtop (the version of top used in
FreeBSD) to only show PostgreSQL processes pulled from the
pg_stat_activity table. I have a version that kind of works here:
http://pgfoundry.org/frs/download.php/1468/ptop-3.6.1-pre6.tar.gz
I've tried it on FreeBSD
The .def files can be generated from cygwin or mingw's dlltool command:
erase readline.def
erase history.def
dlltool --export-all-symbols -z readline.def libreadline.a
dlltool --export-all-symbols -z history.def libhistory.a
lib /machine:i386 /def:readline.def
lib /machine:i386 /def:history.def
Hello
Current result from xpath function isn't indexable. It cannot be
problem with possibility cast it to some base types.
CREATE OR REPLACE FUNCTION xml_list_to_int(xml[])
RETURNS int[] AS $$
SELECT ARRAY(SELECT to_number(($1[i])::text,'99.99')::int
FROM generate_series(1,
On Mon, 2007-09-24 at 10:55 -0700, Joshua D. Drake wrote:
IMO, monitor_ seems weird versus track_. To me monitor implies actions
to be taken when thresholds are met. PostgreSQL doesn't do that.
PostgreSQL tracks/stores information for application to monitor or
interact with and those
Am Montag, 24. September 2007 schrieb Joshua D. Drake:
IMO, monitor_ seems weird versus track_. To me monitor implies actions
to be taken when thresholds are met. PostgreSQL doesn't do that.
PostgreSQL tracks/stores information for application to monitor or
interact with and those application
Chuck McDevitt wrote:
Maybe I need to do some research on readline... this seems more
complicated than I expected.
Does no one else use readline on Windows? Is the Gnuwin32 readline a
fraud? I just don't know.
readline has never worked well on Windows which is why we don't use it
with the
On Mon, Sep 24, 2007 at 11:51:47PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, neither the new nor the old scripts run ECPG tests on my setup,
so I have been unable to test that.
I'm confused. We have MSVC buildfarm animals that show green, so aren't
they
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, neither the new nor the old scripts run ECPG tests on my setup,
so I have been unable to test that.
I'm confused. We have MSVC buildfarm animals that show green, so aren't
they getting through ECPG tests?
I can
On Mon, Sep 24, 2007 at 01:33:33PM -0400, Chuck McDevitt wrote:
Sorry, completion_matches hasn't existed in readline for a long time.
You need to define:
#define HAVE_RL_COMPLETION_APPEND_CHARACTER 1
#define HAVE_RL_COMPLETION_MATCHES 1
#define HAVE_RL_FILENAME_COMPLETION_FUNCTION 1
On Tue, 2007-04-10 at 16:23 +0900, Koichi Suzuki wrote:
Here're two patches for
1) lesslog_core.patch, patch for core, to set a mark to the log record
to be removed in archiving,
2) lesslog_contrib.patch, patch for contrib/lesslog, pg_compresslog and
pg_decompresslog,
respectively,
On Tue, 2007-09-25 at 10:15 +0200, Csaba Nagy wrote:
On Mon, 2007-09-24 at 10:55 -0700, Joshua D. Drake wrote:
IMO, monitor_ seems weird versus track_. To me monitor implies actions
to be taken when thresholds are met. PostgreSQL doesn't do that.
PostgreSQL tracks/stores information for
On Tue, Sep 25, 2007 at 02:58:54AM -0400, Chuck McDevitt wrote:
Actually, the more I look at it, I realize it was correct before
We want to link against readline.lib and history.lib, but the ones in
the GnuWin32 distribution are broken.
The .lib files are made from the .def files, which are
Magnus Hagander wrote:
On Mon, Sep 24, 2007 at 11:51:47PM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
However, neither the new nor the old scripts run ECPG tests on my setup,
so I have been unable to test that.
I'm confused. We have MSVC buildfarm animals that show green,
Magnus Hagander wrote:
If this has never run on the buildfarm, my guess is that it's been broken
for about 5 weeks - when the major rewrite got in.
Can someone confirm if this has ever executed on the buildfarm? Or if they
the same errors with HEAD that I do? I haven't been running ecpgcheck
Magnus Hagander wrote:
Can you check if your manually linked version works in non-US locales? If
you can't check, can you email me (offlist) with the binary (and the DLLs)
and I can run a test here. If they *have* fixed the issue so it works in
non-US locales, it's certainly worth expending
Am Dienstag, 25. September 2007 schrieb Pavel Stehule:
Current result from xpath function isn't indexable. It cannot be
problem with possibility cast it to some base types.
Nikolay might be able to remind us what happened to the proposed functions
xpath_bool, xpath_text, etc.
--
Peter
On Tue, Sep 25, 2007 at 06:09:36AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
Can you check if your manually linked version works in non-US locales? If
you can't check, can you email me (offlist) with the binary (and the DLLs)
and I can run a test here. If they *have* fixed the
On Tue, Sep 25, 2007 at 06:00:46AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
If this has never run on the buildfarm, my guess is that it's been broken
for about 5 weeks - when the major rewrite got in.
Can someone confirm if this has ever executed on the buildfarm? Or if they
Magnus Hagander wrote:
To the best of my knowledge, I was never aware that the ECPG checks ever
ran cleanly for MSVC, so I never enabled it for the buildfarm.
Pah, it's even been in the weekly news ;-)
I read that at best sporadically.
Seriously, though, if you'd monitored your
On Tue, Sep 25, 2007 at 08:06:49AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
To the best of my knowledge, I was never aware that the ECPG checks ever
ran cleanly for MSVC, so I never enabled it for the buildfarm.
Pah, it's even been in the weekly news ;-)
I read
On Tue, Sep 25, 2007 at 11:07:27AM +0200, Magnus Hagander wrote:
Oh, and I'm now seeing failures on my dev box with ECPG on the MSVC build
using the old way (.bat-files):
array_of_struct.c
array_of_struct.pgc(26): error C2065: 'customer' : undeclared identifier
On Tue, Sep 25, 2007 at 02:13:05PM +0200, Michael Meskes wrote:
On Tue, Sep 25, 2007 at 11:07:27AM +0200, Magnus Hagander wrote:
Oh, and I'm now seeing failures on my dev box with ECPG on the MSVC build
using the old way (.bat-files):
array_of_struct.c
array_of_struct.pgc(26):
On Tue, Sep 25, 2007 at 02:20:34PM +0200, Magnus Hagander wrote:
Irrk. The C file is very wrong indeed. Here's the relevant part where it
shoudl be declaring 'customer':
/* exec sql type customer is struct { #line 12 array_of_struct.pgc struct
varchar_name_12 { int len; char arr[ 50 ]; }
On Thu, Sep 20, 2007 at 05:12:45PM -0700, Tom Raney wrote:
We are pleased to announce an upcoming patch to the hash index code
which improves build time and index size, based on this item in the
TODO list:
During index creation, pre-sort the tuples to improve build speed
On Tue, Sep 25, 2007 at 02:58:15PM +0200, Michael Meskes wrote:
On Tue, Sep 25, 2007 at 02:20:34PM +0200, Magnus Hagander wrote:
Irrk. The C file is very wrong indeed. Here's the relevant part where it
shoudl be declaring 'customer':
/* exec sql type customer is struct { #line 12
Hi,
Now that PostgreSQL 8.3 enables autovacuum by default, I think pgbench
should stop issuing vacuum in pgbench -i since an ordinary vacuum will
take very long time under autovacuum running. If there's no objection,
I will remove vacuum from pgbench.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Kenneth Marshall [EMAIL PROTECTED] writes:
On Thu, Sep 20, 2007 at 05:12:45PM -0700, Tom Raney wrote:
Using our implementation, build times and index sizes are
comparable with btree index build times and index sizes.
...
That is super! (and timely)
It is pretty super. I have a few comments
What do these output lines in pg_resetxlog of 8.3 mean?
First log file ID for new XLOG:
First log file segment for new XLOG:
What does it mean to have a new XLOG?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
We previously discussed compressing the numeric data type for small values:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
We didn't do this for 8.3 but in any case Tom did suggest we ought to reverse
the weight and
Zdenek Kotala wrote:
Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
We previously discussed compressing the numeric data type for small
values:
http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php
We didn't do this for 8.3 but in any case Tom did suggest we ought
to
On Tue, Sep 25, 2007 at 03:35:47PM +0100, Gregory Stark wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
On Thu, Sep 20, 2007 at 05:12:45PM -0700, Tom Raney wrote:
Using our implementation, build times and index sizes are
comparable with btree index build times and index sizes.
...
Tatsuo Ishii [EMAIL PROTECTED] writes:
Now that PostgreSQL 8.3 enables autovacuum by default, I think pgbench
should stop issuing vacuum in pgbench -i since an ordinary vacuum will
take very long time under autovacuum running. If there's no objection,
I will remove vacuum from pgbench.
I'd be
Peter Eisentraut [EMAIL PROTECTED] writes:
What do these output lines in pg_resetxlog of 8.3 mean?
First log file ID for new XLOG:
First log file segment for new XLOG:
What does it mean to have a new XLOG?
Why does that wording surprise you? pg_resetxlog is for wiping out
your xlog
On Sep 25, 2007, at 11:26 , Kenneth Marshall wrote:
Although I am very excited about this patch, I do not see any real
value
in including it in 8.3.
I don't think you have to worry about it being in 8.3. Feature freeze
was months ago.
Michael Glaesemann
grzm seespotcode net
On 9/25/07, Tom Lane [EMAIL PROTECTED] wrote:
I'd be inclined to leave it there, simply because you'll be changing
the conditions of the benchmark if you take it out. I have not noticed
any particular problems with it...
The only problem I faced is while executing custom scripts using
On Tue, 2007-09-25 at 12:33 -0400, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
What do these output lines in pg_resetxlog of 8.3 mean?
First log file ID for new XLOG:
First log file segment for new XLOG:
What does it mean to have a new XLOG?
Why does that wording
On Tue, 25 Sep 2007, Tatsuo Ishii wrote:
Now that PostgreSQL 8.3 enables autovacuum by default, I think pgbench
should stop issuing vacuum in pgbench -i since an ordinary vacuum will
take very long time under autovacuum running. If there's no objection,
I will remove vacuum from pgbench.
Just
On Tue, 2007-09-25 at 22:16 +0530, Pavan Deolasee wrote:
The only problem I faced is while executing custom scripts using
pgbench.
You either need to do the initialization (pgbench -i) or run with -n
option
(no vacuum). But I don't have any strong preference here.
Yes, I had that problem
Many of us would like to see libedit ported to Windows too ;-)
Yeah, it's on my (insanely long) TODO to look at sometime :-)
//Magnus
I've thought about working on a libedit port myself, but I don't see how
that would help PostgreSQL unless the PostgreSQL community would be
willing to
Chuck McDevitt wrote:
Many of us would like to see libedit ported to Windows too ;-)
Yeah, it's on my (insanely long) TODO to look at sometime :-)
//Magnus
I've thought about working on a libedit port myself, but I don't see how
that would help PostgreSQL unless the PostgreSQL
Chuck McDevitt wrote:
Many of us would like to see libedit ported to Windows too ;-)
Yeah, it's on my (insanely long) TODO to look at sometime :-)
//Magnus
I've thought about working on a libedit port myself, but I don't see how
that would help PostgreSQL unless the PostgreSQL
Greg Smith [EMAIL PROTECTED] writes:
Tom gets credit for naming the attached patch, which is my latest attempt to
finalize what has been called the Automatic adjustment of
bgwriter_lru_maxpages patch for 8.3; that's not what it does anymore but
that's where it started.
I've applied this
Chuck McDevitt wrote:
Many of us would like to see libedit ported to Windows too ;-)
Yeah, it's on my (insanely long) TODO to look at sometime :-)
//Magnus
I've thought about working on a libedit port myself, but I don't see how
that would help PostgreSQL unless the PostgreSQL community
On Tue, 25 Sep 2007, Tom Lane wrote:
-Heikki didn't like the way I pass information back from SyncOneBuffer
back to the background writer.
I didn't either --- it was too complicated and not actually doing
anything useful.
I suspect someone (possibly me) may want to put back some of that same
Hi Mark,
I haven't yet looked at what you've done, but I'm an enthusiastic supporter
of this idea. We're looking to do something that will view running queries
and allow drill down into those executing at any given time, showing their
plans and some notion of what operators are being executed.
Neil Conway [EMAIL PROTECTED] wrote:
To review, Pavel Stehule submitted a proposal and patch to add support
for table functions a few months back:
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00318.php
http://archives.postgresql.org/pgsql-patches/2007-05/msg00054.php
Pavel
On Tue, 2007-25-09 at 22:15 -0400, Tom Lane wrote:
I believe that (1) is now committed (renamed to RETURN QUERY),
but what is the status of (2)?
Personally I won't cry if this doesn't make it into 8.3, particularly
since there was some disagreement about it. But if you intend to make
it
Neil Conway [EMAIL PROTECTED] writes:
On Tue, 2007-25-09 at 22:15 -0400, Tom Lane wrote:
Personally I won't cry if this doesn't make it into 8.3, particularly
since there was some disagreement about it. But if you intend to make
it happen, the days grow short.
My recollection is that the
On Tue, 25 Sep 2007, Luke Lonergan wrote:
One strategy we've considered is to use the same approach as pstack on
Solaris - it takes a pid and dumps the stack of a backend, which clearly
shows which executor node is being worked on currently. I think pstack
uses dtrace underneath the hood...
Mark Wong wrote:
Hi everyone,
I was playing with converting unixtop (the version of top used in
FreeBSD) to only show PostgreSQL processes pulled from the
pg_stat_activity table. I have a version that kind of works here:
Nice idea. But I got a segfault trying to execute it. My SO is a
Hi Greg,
On 9/25/07 9:15 PM, Greg Smith [EMAIL PROTECTED] wrote:
It's also worth noting that there's a similar Linux utility called gstack.
Cool!
So - the basic idea is that we could uncover the current run context in a
very lightweight manner by just dumping the stack and interpreting it.
Kenneth Marshall wrote:
On Tue, Sep 25, 2007 at 03:35:47PM +0100, Gregory Stark wrote:
Kenneth Marshall [EMAIL PROTECTED] writes:
On Thu, Sep 20, 2007 at 05:12:45PM -0700, Tom Raney wrote:
Using our implementation, build times and index sizes are
comparable with btree index
53 matches
Mail list logo
