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
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 like
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
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 file
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 ExecMakeFunctionResult.
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
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 just
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
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 reproduce it
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 storm
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 a
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
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
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
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 reduces the CS storm:
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 ... ?
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
Larry Rosenman ler@lerctr.org 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
Larry Rosenman ler@lerctr.org 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).
Tom Lane wrote:
Larry Rosenman ler@lerctr.org 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
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
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 about
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
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
Martijn van Oosterhout kleptog@svana.org 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
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 one
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,
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, 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 all
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 think it'd be
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
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
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 of
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
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]
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:
snip
If it is that, does it work if you compile postgres with -lpthread.
Sure, we
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:
snip
If it is that, does it
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
Larry Rosenman ler@lerctr.org 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:
On Oct 18, 2005, at 9:39 PM, Tom Lane wrote:
Larry Rosenman ler@lerctr.org 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
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 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
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.
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
44 matches
Mail list logo
