>
> Sorry, my day job is currently taking up all my spare cycles :( So I
> don't think I'll get a chance to wrap this up for 8.3.
>
> My recollection is that the patch was okay as far as it went, but I'm
> hesitant to add yet another alternative to the already complex set of
> choices for returning
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 inde
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
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
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...
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 th
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
>
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
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.
T
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
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 c
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
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
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 c
> >
> > 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
willi
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 probl
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 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 doe
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
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
-
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
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
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
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
t
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
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 broadcast)---
"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 fe
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
-
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 "arr
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
> http://archives.p
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 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.pg
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
> array_of_stru
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 ;-)
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 ow
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?
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* fixe
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 Eisen
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 som
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:
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
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
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 f
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,
>
> respec
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
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 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
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 of
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 applicati
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 applic
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, a
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
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
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 comman
54 matches
Mail list logo