Isn't that what pg_stat_database reports with its xact_commit and
xact_rollback values?
On Wed, 19 Oct 2005, Christopher Kings-Lynne wrote:
do we maintain anything anywhere for this? mainly, some way of determining
# of 'sorts to disk' vs 'sort in memory', to determine whether or not
sort_
do we maintain anything anywhere for this? mainly, some way of
determining # of 'sorts to disk' vs 'sort in memory', to determine
whether or not sort_mem is set to a good value?
I don't think there is currently, but wondering how hard it would be to
get something like this added ... ?
While
Martijn van Oosterhout wrote:
> Very well, patch attached. It's quite simple actually. However, there
> seems to be some push back from people suggesting that jumping back to
> the main loop before the pager has quit is not buggy behaviour.
> Assuming that a ^C will kill the pager is just folly.
M
On Oct 18, 2005, at 10:03 PM, Michael Fuhr wrote:
On Tue, Oct 18, 2005 at 08:59:23PM -0600, Michael Fuhr wrote:
On Tue, Oct 18, 2005 at 09:41:21PM -0500, Larry Rosenman wrote:
I could not find a truss/strace binary on the box :(
In BSD land try ktrace.
...or attach with a debugger lik
On Tue, Oct 18, 2005 at 08:59:23PM -0600, Michael Fuhr wrote:
> On Tue, Oct 18, 2005 at 09:41:21PM -0500, Larry Rosenman wrote:
> > I could not find a truss/strace binary on the box :(
>
> In BSD land try ktrace.
...or attach with a debugger like gdb.
--
Michael Fuhr
--
On Tue, Oct 18, 2005 at 09:41:21PM -0500, Larry Rosenman wrote:
> I could not find a truss/strace binary on the box :(
In BSD land try ktrace.
--
Michael Fuhr
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Oct 18, 2005, at 9:39 PM, Tom Lane wrote:
Larry Rosenman writes:
I added a LIBS += -lpthread to the end of src/makefiles/
Makefile.netbsd and got a LOOP
on the make check :(
Er ... define "LOOP"?
postgres master process sitting with 98%+ cpu for >1hour and NO
progress being made.
Larry Rosenman writes:
> I added a LIBS += -lpthread to the end of src/makefiles/
> Makefile.netbsd and got a LOOP
> on the make check :(
Er ... define "LOOP"?
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill
Isn't that what pg_stat_database reports with its xact_commit and
xact_rollback values?
Ah yes. Doh :)
Chris
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Oct 18, 2005, at 8:49 PM, Larry Rosenman wrote:
On Oct 18, 2005, at 5:11 PM, Martijn van Oosterhout wrote:
On Tue, Oct 18, 2005 at 05:03:35PM -0500, Larry Rosenman wrote:
Doesn't appear to have a separate libc, HOWEVER, -lpthread may be
screwing
us:
If it is that, does it work
On Oct 18, 2005, at 5:11 PM, Martijn van Oosterhout wrote:
On Tue, Oct 18, 2005 at 05:03:35PM -0500, Larry Rosenman wrote:
Doesn't appear to have a separate libc, HOWEVER, -lpthread may be
screwing
us:
If it is that, does it work if you compile postgres with -lpthread.
Sure, we don't u
Josh Berkus wrote:
>>And I want to get statistic info through system views, like pg_statio_*.
>
> I don't think anyone disagrees with that. It's just a little too late to
> get in for 8.1.
Thanks for comment. I hope 8.2 will get it.
--
NAGAYASU Satoshi <[EMAIL PROTECTED]>
Satoshi,
> And I want to get statistic info through system views, like pg_statio_*.
I don't think anyone disagrees with that. It's just a little too late to
get in for 8.1.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)
Tom,
Tom Lane wrote:
>>do we maintain anything anywhere for this? mainly, some way of
>>determining # of 'sorts to disk' vs 'sort in memory', to determine whether
>>or not sort_mem is set to a good value?
>
> As of 8.1 you could turn on trace_sort to collect some data about this.
Why is the trac
On Tue, Oct 18, 2005 at 05:15:20PM -0500, Kevin Grittner wrote:
> I run into this problem sometimes, especially when I realize that
> the query I've just started is going to run for a very long time and
> not really provide anything useful. I find that I have to close the
> shell window to get out
On Tue, 18 Oct 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
do we maintain anything anywhere for this? mainly, some way of
determining # of 'sorts to disk' vs 'sort in memory', to determine whether
or not sort_mem is set to a good value?
As of 8.1 you could turn on tr
I think in this case you need to try to install the PL manually and see
what happens - run psql, attach the debugger to the backend, and issue
"create language plperl ..."
Having it die at this stage is rather strange.
cheers
andrew
Larry Rosenman wrote:
Upped the stack to 8Mb. Now it d
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Tue, 18 Oct 2005, Tom Lane wrote:
>> Looking at the code, I notice that the messages are all emitted at level
>> NOTICE. Perhaps that was not such a good idea --- it'd be pretty much
>> in-your-face if it were on all the time. Does anyone thin
On Tue, 18 Oct 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Tue, 18 Oct 2005, Tom Lane wrote:
Looking at the code, I notice that the messages are all emitted at level
NOTICE. Perhaps that was not such a good idea --- it'd be pretty much
in-your-face if it were on al
Robert,
> Anyone know of a script that can replay a PostgreSQL log file? Then I
> could log all queries, wait till the problem hits, and then replay to
> see if that reproduces it...
log_statement=true in your postgresql.conf file. The trick is weeding out
all the other non-query stuff.
--
-
On Tue, Oct 18, 2005 at 10:29:30PM +0300, Volkan YAZICI wrote:
> Hi,
>
> I'm trying to understand the schema laying behind
> backend/utils/adt/like.c to downcase letters [1]. When I look at the
> other tolower() implementations, there're lots of them spread around.
> (In interfaces/libpq, backend/
On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote:
> Upped the stack to 8Mb. Now it dies in Plcheck.
>
> Logs/bt.out in: http://www.lerctr.org/~ler/alphadeath2.tar.gz
Wierd, it's dying in malloc() because the C library called kill() from
__libc_mutex_unlock().
You're not the only o
Martijn van Oosterhout writes:
> On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote:
>> Upped the stack to 8Mb. Now it dies in Plcheck.
> Wierd, it's dying in malloc() because the C library called kill() from
> __libc_mutex_unlock().
I wonder if this is related to the "threaded libp
Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote:
>>> Upped the stack to 8Mb. Now it dies in Plcheck.
>
>> Wierd, it's dying in malloc() because the C library called kill()
>> from __libc_mutex_unlock().
>
> I wonder if this is r
Thanks to all who have been offering suggestions. I have been
reading them and will try to incorporate as much as possible.
I have already reworked that little brain-dead python script into
something which uses a regular expression to pick off all of the
data from each cost/timing line (including
On Tue, Oct 18, 2005 at 05:03:35PM -0500, Larry Rosenman wrote:
> Doesn't appear to have a separate libc, HOWEVER, -lpthread may be screwing
> us:
If it is that, does it work if you compile postgres with -lpthread.
Sure, we don't use the functions but maybe it's a prerequisite to be
able to dlop
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> do we maintain anything anywhere for this? mainly, some way of
> determining # of 'sorts to disk' vs 'sort in memory', to determine whether
> or not sort_mem is set to a good value?
As of 8.1 you could turn on trace_sort to collect some data abou
I run into this problem sometimes, especially when I realize that
the query I've just started is going to run for a very long time and
not really provide anything useful. I find that I have to close the
shell window to get out of it, and I'm always a bit uncomforatble
doing that.
-Kevin
>>> Mar
Tom Lane wrote:
> "Larry Rosenman" writes:
>> I just tried(!) to run the buildfarm script on a Alpha DS10L/NetBSD
>> 2.0 box. It died in make check.
>
> Given that the failure was in infinite_recurse, I'm guessing the
> problem is that the stack limit is less than our default expectation
> (4MB I
"Larry Rosenman" writes:
> I just tried(!) to run the buildfarm script on a Alpha DS10L/NetBSD 2.0 box.
> It died in make check.
Given that the failure was in infinite_recurse, I'm guessing the problem
is that the stack limit is less than our default expectation (4MB I think).
"Larry Rosenman" writes:
> Tom Lane wrote:
>> Given that the failure was in infinite_recurse, I'm guessing the
>> problem is that the stack limit is less than our default expectation
>> (4MB I think).
> What would you like me to set it to,
4mb will do.
> and how do we make sure that the build
Hi,
I installed 8.04 via RPM on Centos 4.2 which is the same as RedHat 4.2
and while booting the init script reports that the daemon [FAILED], but
after I logon it shows the postmaster running and I am able to connect
from any client remotely.
I made not modifcations to the script and there i
do we maintain anything anywhere for this? mainly, some way of
determining # of 'sorts to disk' vs 'sort in memory', to determine whether
or not sort_mem is set to a good value?
I don't think there is currently, but wondering how hard it would be to
get something like this added ... ?
tha
On Tue, 18 Oct 2005 12:24:03 -0600
Robert Creager <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Oct 2005 10:29:43 -0600
> Robert Creager <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 18 Oct 2005 00:25:25 +0100
> > Simon Riggs <[EMAIL PROTECTED]> wrote:
> > >
> > > Please try this patch and see if it reduce
Upped the stack to 8Mb. Now it dies in Plcheck.
Logs/bt.out in: http://www.lerctr.org/~ler/alphadeath2.tar.gz
$ tar tzvf alphadeath2.tar.gz
drwxr-xr-x 2 ler users 0 Oct 18 16:01 lastrun-logs
-rw-r--r-- 1 ler users 22708 Oct 18 14:50 lastrun-logs/CVS.log
-rw-r--r-- 1 le
Hi,
I'm trying to understand the schema laying behind
backend/utils/adt/like.c to downcase letters [1]. When I look at the
other tolower() implementations, there're lots of them spread around.
(In interfaces/libpq, backend/regex, backend/utils/adt/like and etc.)
For example, despite having pg_wc_t
I just tried(!) to run the buildfarm script on a Alpha DS10L/NetBSD 2.0 box.
It died in make check.
I have a tarball of the last-logs, to which I added a backtrace from the
coredump(!).
It's at: http://www.lerctr.org/~ler/alphadeath.tar.gz
$ gtar tzvf alphadeath.tar.gz
drwxr-xr-x ler/users
On Mon, 2005-17-10 at 13:32 -0400, Tom Lane wrote:
> I dislike portability approaches that try to enumerate supported cases,
> rather than being general in the first place.
Do we need to have this on every platform we support? The symbols we
want to hide are internal by convention anyway -- using
On Tue, 18 Oct 2005 10:29:43 -0600
Robert Creager <[EMAIL PROTECTED]> wrote:
> On Tue, 18 Oct 2005 00:25:25 +0100
> Simon Riggs <[EMAIL PROTECTED]> wrote:
> >
> > Please try this patch and see if it reduces the CS storm:
> >
Sorry, didn't work. Took about an hour, and now it's now at the CS st
On Tue, 18 Oct 2005 00:25:25 +0100
Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> Please try this patch and see if it reduces the CS storm:
>
> http://archives.postgresql.org/pgsql-patches/2005-10/msg00091.php
Yes, I will. I'd been trying to figure out what triggered it, as I was unable
to reproduc
As the release of PostgreSQL 8.1 draws near, it is once again time to update
the translations of the program messages. To check the status of your
language, check out this web site:
http://developer.postgresql.org/~petere/nlsstatus/
To participate in the translation effort, please follow t
Sandeep,
You seem to be having a lot of trouble understanding the evaluation
code which isn't that complex. Are you still trying to do that
case-insensitive comparison? If so, I seriously recommend that
you just look at the citext project on gborg and stop messing around in
the backend, it's jus
Hi,
I have a set of perl scripts which invoke each other (via system());
eventually I found that they were crashing and ultimately causing Perl
to SIGSEGV.
I am using Debian testing and have recompiled postgres-8.0.3-15 to
include debugging symbols. This is a dual-CPU dual-stacked IPv4/IPv6
host
On Tue, Oct 18, 2005 at 02:38:39PM +0530, sandeep satpal wrote:
>
> Hi,
>
> I have some doubts related to ExecEvalExpr functions which is used to
> executing the expression.
Since they are operators, they go through ExecEvalOper. However, after
the first call they go through ExecMakeFunctionRes
Tom Lane wrote:
Patrick Bakker <[EMAIL PROTECTED]> writes:
It would be useful if you could toggle SQL statement logging without
restarting PostgreSQL and additionally if you could turn on selective SQL
logging. Additionally, it would be great if you could log SQL statements to
a separate fil
Hi,
I have some doubts related to ExecEvalExpr functions which is used to
executing the expression.
Here we are finding the subexpression recursively.
But I am not able to find it out that where exactly the comparison taking
place.
For eg.
relation A
id name age
relation B
name age stat
On Tue, Oct 18, 2005 at 09:57:03AM +0200, Sebastián Ávila wrote:
> I'm new here, and I would like to know a few things about how developers
> works.
> Could be posible that two developers works on the same item, but in isolation?
> What happens with the different patchs they produced?
> I would li
Hi people,
I'm new here, and I would like to know a few things about how developers works.
Could be posible that two developers works on the same item, but in isolation?
What happens with the different patchs they produced?
I would like to do my PFC in semantic optimization, what is now
implemente
48 matches
Mail list logo
