Hi,
I'm using 8.1beta4 on a development server for a rather db-intensive
application. This application has a multiprocess daemon which was
working fairly well in past. After some recent changes I started having
deadlock problems. While investigating to remove what was causing them I
removed
On Thu, Oct 27, 2005 at 12:04:11AM -0400, Gayathri TK wrote:
Hi all,
I am new user of postgres.. I am currently working on a project
for my advisor and the project is to implement an algorithm for
materialiazed view design as explained in this paper
On Thu, Oct 27, 2005 at 10:59:30AM +0200, Matteo Beccati wrote:
Hi,
I'm using 8.1beta4 on a development server for a rather db-intensive
application. This application has a multiprocess daemon which was
working fairly well in past. After some recent changes I started having
deadlock
Hi Martijn,
Backtrace would be nice. I don't suppose your backend is compiled with
debugging? If so, try attaching to the backend and do:
break MemoryContextAlloc if size 10
Obviously something is trying to allocate and negative number of
bytes... 4291419108 = -3548188
Here is the
On Thu, Oct 27, 2005 at 11:37:09AM +0200, Matteo Beccati wrote:
Here is the backtrace, hoping I did it correctly:
Dagnammit. I was wondering if that was going to happen. If your
optimisation is up, the values of arguments to the functions don't
display right (look at the rest, they're obviously
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
(I expected the find the answer in the developer FAQ, but it's not
there).
Hope this helps,
On Thu, Oct 27, 2005 at 12:04:45PM +0200, Martijn van Oosterhout wrote:
On Thu, Oct 27, 2005 at
1. Move the test for strange memory alloc sizes to the palloc macros so
that on error, it points at the palloc call rather than mcxt.c.
Sure, it only attacks a small set of problems, but still.
2. Add either a GUC or a command line switch or PGOPTION switch to call
setrlimit to set the core size
On 2005-10-27, Paul Lindner [EMAIL PROTECTED] wrote:
On Mon, Oct 24, 2005 at 05:07:40AM -, Andrew - Supernews wrote:
I'm inclined to suspect that the whole sequence c1 f9 d4 c2 d0 c7 d2 b9
was never actually a valid utf-8 string, and that the d2 b9 is only valid
by coincidence (it's a
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
(I expected the find the answer in the developer FAQ, but it's not
there).
I removed it because it used to be in the main
On Thu, Oct 27, 2005 at 08:54:57AM -0400, Bruce Momjian wrote:
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
(I expected the find the answer in the developer FAQ, but
Martijn van Oosterhout wrote:
Belay that, you should be able to put a breakpoint on errstart or elog
or perhaps errmsg. Much easier...
After several tries, I finally found a way to produce a reliable
backtrace :)
Breakpoint 4, errfinish (dummy=0) at elog.c:346
346
Andrew Dunstan wrote:
Can anyone explain to me why 'localhost' in a .pgpass file matches
both a Unix socket and a tcp localhost connection?
Also, there is no documentation at all that I can see to cover the
Unix socket case. I found the information after much looking through
asking on
Martijn van Oosterhout kleptog@svana.org writes:
Hmm, depends. It's not asked often, that for sure. Yet everytime it
comes up I keep forgetting if I should be breaking on errstart, errmsg
or something else. One of these days I might just write it on a post-it
note next to my computer.
I
Matteo Beccati [EMAIL PROTECTED] writes:
(gdb) bt
#0 errfinish (dummy=0) at elog.c:346
#1 0x08265896 in elog_finish (elevel=20, fmt=0x831858c invalid memory
alloc request size %lu) at elog.c:930
#2 0x0827b5cf in MemoryContextAlloc (context=0x85b2238,
size=4279476584) at mcxt.c:505
#3
Hi Tom,
Well, this apparently indicates a bug in the new multixact code, but
there's not enough info here to figure out what went wrong. Can you
create a test case that will let someone else reproduce the problem?
Unfortunately the error pops up randomly in a very complex app/db and I
am
OK, developer's FAQ updated to mention errfinish,
---
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Hmm, depends. It's not asked often, that for sure. Yet everytime it
comes up I keep forgetting if I
Andrew Dunstan wrote:
Andrew Dunstan wrote:
Can anyone explain to me why 'localhost' in a .pgpass file matches
both a Unix socket and a tcp localhost connection?
Also, there is no documentation at all that I can see to cover the
Unix socket case. I found the information after
On Thu, Oct 27, 2005 at 03:45:16PM +0200, Matteo Beccati wrote:
Hi Tom,
Well, this apparently indicates a bug in the new multixact code, but
there's not enough info here to figure out what went wrong. Can you
create a test case that will let someone else reproduce the problem?
Matteo Beccati wrote:
Hi Tom,
Well, this apparently indicates a bug in the new multixact code, but
there's not enough info here to figure out what went wrong. Can you
create a test case that will let someone else reproduce the problem?
Unfortunately the error pops up randomly in a very
Hi,
Go up a few levels to GetMultiXactIdMembers and type info locals, see
if we can get the values of some of the variables there. Also, if you
can turn the debugging down to -O0, that will make the results in gdb
much more reliable.
It's clear at least that length is negative, but what about
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
Matteo Beccati wrote:
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Huh, it should be a global variable. Try
p *MultiXactState
--
Alvaro
Matteo Beccati wrote:
#2 0x0827b5cf in MemoryContextAlloc (context=0x856bcc8,
size=4278026492) at mcxt.c:505
__func__ = MemoryContextAlloc
#3 0x080b6a16 in GetMultiXactIdMembers (multi=320306, xids=0xbfbfaba4)
at multixact.c:935
pageno = 156
prev_pageno = 156
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Huh, it should be a global variable. Try
p *MultiXactState
Done:
(gdb) p *MultiXactState
$1 =
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls. So one backend could try to read the offset before
another one had the time to finish writing it.
Ugh, yes,
On Thu, Oct 27, 2005 at 10:23:07AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls. So one backend could try to read the offset
Martijn van Oosterhout kleptog@svana.org writes:
1. Move the test for strange memory alloc sizes to the palloc macros so
that on error, it points at the palloc call rather than mcxt.c.
What would that accomplish other than bloating the backend? We can't do
it anyway, because of
On Thu, Oct 27, 2005 at 10:41:08AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
1. Move the test for strange memory alloc sizes to the palloc macros so
that on error, it points at the palloc call rather than mcxt.c.
What would that accomplish other than bloating
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I don't see any easy way to fix this except by introducing a lot more
locking than is there now --- ie, holding the MultiXactGenLock until the
new mxact's starting offset has been written to disk. Any better ideas?
Well, it isn't a
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls. So one backend could try to read the offset before
another one had the time to finish
Alvaro Herrera wrote:
I don't see any easy way to fix this except by introducing a lot more
locking than is there now --- ie, holding the MultiXactGenLock until the
new mxact's starting offset has been written to disk. Any better ideas?
Well, it isn't a very good solution because it requires
Tom Lane wrote:
Both of these presume you have a programmer running the database, or at
least someone who's not scared of gdb.
I think you have the set relationship the wrong way around ;-)
Personally, I only use gdb in extremis, and I am sure the average DBA
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I confess being attracted to Martijn's idea of looping until the correct
answer is obtained. I don't think it's even too difficult to implement.
But I wonder if there's some hidden pitfall.
I've been looking at that and I think
Alvaro Herrera [EMAIL PROTECTED] writes:
The remaining question for me is, how do we sleep until the correct
offset has been stored?
I was thinking of just pg_usleep for some nominal time (1ms maybe)
and try to read the offsets page again. This is a corner case so
the performance doesn't have
Last night I was able to get a good stack trace out of some core files
to track down an issue with a corrupted index. Now I can't repeat that,
with either those core files or a new, unrelated coredump I've got.
Here's what I'm getting:
[EMAIL PROTECTED] coredumps]# gdb /usr/bin/postgres
On Thu, Oct 27, 2005 at 05:11:41PM +0200, Martijn van Oosterhout wrote:
On Thu, Oct 27, 2005 at 10:41:08AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
1. Move the test for strange memory alloc sizes to the palloc macros so
that on error, it points at the palloc
Tom, Alvaro
The remaining question for me is, how do we sleep until the correct
offset has been stored?
I was thinking of just pg_usleep for some nominal time (1ms maybe)
and try to read the offsets page again. This is a corner case so
the performance doesn't have to be great.
Let me know
Folks,
Looks like someone left their test settings in postgresql.conf.sample in
the beta4 release:
-Line 224
silent_mode = true
#silent_mode = false # DO NOT USE without syslog or
redirect_stderr
-
--
--Josh
Josh Berkus
Aglio Database Solutions
San
I wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found that bgwriter increments usage count of buffers when it writes
the buffers. I feel this behavior is strange, because the behavior of
bgwriter will affect buffer management strategy.
I think it might be sufficient to not increment
Jim C. Nasby [EMAIL PROTECTED] writes:
It would also be useful to be able to force the backend to
dump core so you can see if it's actually working
kill -ABRT backend-PID
regards, tom lane
---(end of broadcast)---
TIP 4:
Jim C. Nasby [EMAIL PROTECTED] writes:
It would also be useful to be able to force the backend to
dump core so you can see if it's actually working (granted, I know you
can end up hitting the ulimit depending on how much memory is being
consumed). Maybe there is a way to do this
Josh Berkus josh@agliodbs.com writes:
Looks like someone left their test settings in postgresql.conf.sample in
the beta4 release:
-Line 224
silent_mode = true
#silent_mode = false # DO NOT USE without syslog or
redirect_stderr
-
Don't see it in
On Thu, Oct 27, 2005 at 01:13:37PM -0400, Douglas McNaught wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
It would also be useful to be able to force the backend to
dump core so you can see if it's actually working (granted, I know you
can end up hitting the ulimit depending on
On Thu, Oct 27, 2005 at 09:54:03AM -0700, Josh Berkus wrote:
Looks like someone left their test settings in postgresql.conf.sample in
the beta4 release:
-Line 224
silent_mode = true
#silent_mode = false # DO NOT USE without syslog or
redirect_stderr
Are you sure
On Thu, Oct 27, 2005 at 07:20:57PM +0200, Martijn van Oosterhout wrote:
On Thu, Oct 27, 2005 at 01:13:37PM -0400, Douglas McNaught wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
It would also be useful to be able to force the backend to
dump core so you can see if it's
Tom,
Don't see it in my copy, nor in cvsweb.
Sorry. This looks like an artifact of the FreeBSD ports install combining
in weird ways with a CVS install of beta4. Sorry for the bogus report.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of
Kevin Murphy [EMAIL PROTECTED] writes:
I'm trying to build PG 8.1 beta on an AIX server.
The 'make' finishes without errors, but I'm getting lots of duplicate
symbol warnings like the following one. What am I to make of these?
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
If people would like to play, I have created a little kit to help in
creating first class enum types in a few seconds. It works something
like this:
make TYPENAME=rainbow ENUMS=' red, orange, yellow, green,
blue, indigo, violet '
make TYPENAME=rainbow install
psql -f
I wrote:
Hmm. pqStrerror is defined in libpgport (which is linked into the
backend) as well as libpq. ISTM that libpq should not be linked with
-Wl,-bI:../../../src/backend/postgres.imp, since it's not intended to
be loaded into the backend. Without having looked at the code, I'm
wondering
Tom Lane [EMAIL PROTECTED] writes:
We'd have to make sure zero is never the *correct* value of the offset,
but that just means wasting one word, which seems no problem.
In theory it's possible for only half the word to be written or even to have
outright garbage show up. In practice I think
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
We'd have to make sure zero is never the *correct* value of the offset,
but that just means wasting one word, which seems no problem.
In theory it's possible for only half the word to be written or even to have
outright
This is cool; it's something people can use today if nothing else.
Long-term, is it practical to have the enums compiled in? ISTM that's
not very workable, but I'm completely guessing. The other issue is that
this version makes it very difficult to change what's in the enum (not
that that's at all
This little snippet is great! The only problem I see is that the enums must be consistent across all modules.
What about loading a variable with a default value? Then it could be adjusted to 'play'.On 10/27/05, Jim C. Nasby
[EMAIL PROTECTED] wrote:This is cool; it's something people can use
As in subject.
What it does, it gets through picksplit, I return good values, valid unions,
etc. Than (I guess) postgres is trying to insert another value in tree, hence
penalty is called. Why one of the values penalty is called with is NULL, and
I have no idea if that's valid.
From all the
On Thu, Oct 27, 2005 at 04:54:36PM -0400, Ted Rolle wrote:
This little snippet is great! The only problem I see is that the enums must
be consistent across all modules.
What about loading a variable with a default value? Then it could be
adjusted to 'play'.
Huh? Sorry, but you completely
Matteo Beccati wrote:
Tom, Alvaro
The remaining question for me is, how do we sleep until the correct
offset has been stored?
I was thinking of just pg_usleep for some nominal time (1ms maybe)
and try to read the offsets page again. This is a corner case so
the performance doesn't have
Grzegorz Piotr Jaskiewicz [EMAIL PROTECTED] writes:
can I just run postgres, in non forking mode, on gdb?
Just start a normal session and then attach to the backend process with
gdb in a separate window. There's no reason to fool with a standalone
backend for 99.99% of debugging problems. With
Ok, Thanks for that. Script works great.
Here's bt I get:
#0 0xb7ef26a4 in ?? ()
#1 0xb7cae460 in _IO_list_all () from /lib/tls/libc.so.6
#2 0xb7ef2ea8 in ?? ()
#3 0x in ?? ()
#4 0x0844bebc in ?? ()
#5 0x in ?? ()
#6 0xb7cadff4 in ?? () from /lib/tls/libc.so.6
#7
Adding -hackers back to the list...
-Original Message-
From: Gregory Maxwell [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 27, 2005 5:03 PM
To: Jim Nasby
Subject: Re: [HACKERS] enums
On 10/27/05, Jim C. Nasby [EMAIL PROTECTED] wrote:
On Thu, Oct 27, 2005 at 04:54:36PM
Breakpoint 1, gistpenalty (giststate=0xbfc254e4, attno=0, key1=0xbfc252d4,
isNull1=0 '\0', key2=0xbfc24fd4, isNull2=0 '\0',
penalty=0xbfc24fb0) at gistutil.c:821
821 FunctionCall3(giststate-penaltyFn[attno],
(gdb) p key1
$1 = (GISTENTRY *) 0xbfc252d4
(gdb) p
Alvaro Herrera [EMAIL PROTECTED] writes:
Ok. I had hoped to reproduce the problem with pristine sources, in
order to verify that I was able to show it not appearing with my patch.
However I have been unable to create a situation in which the problem
appears. So I attach the patch that I came
On 10/27/05, Jim Nasby [EMAIL PROTECTED] wrote:
Adding -hackers back to the list...
You could as equally say that it's ordering it by the order of the
enum declaration, which seems quite reasonable to me.
I don't really see why that's considered reasonable, especially as a default.
I
I wrote:
I'm currently experimenting with an alternative approach, which leaves
the nextOffset arithmetic as it was and instead special-cases the zero
offset case this way:
Attached is a completed patch, which I've had no time to test yet, but
I have to leave for the evening right now --- so
Jim C. Nasby wrote:
On another note, I noticed that the comparison operators seem to be
comparing the underlying numeric value used to store the enum, which is
wrong IMO. Consider:
ENUM color 'red,blue,green'
CREATE TABLE t (c color);
INSERT INTO t VALUES('blue');
INSERT INTO t
On Thu, Oct 27, 2005 at 06:46:24PM -0400, Gregory Maxwell wrote:
So what do you propose we do for a default ordering? I hope you don't
think we should force a sort as though the enum labels were text...
I do think that. Or default ordering on whatever type the enum is (I can
see enums that are
Seems like decompress and compress were offending here, simply
removing them from gist index create helped.
But, I still get on explain analyze that seqscan was used, rather
than gist. Even tho ~ operator is defined for gist, and that seqscan
is set to false.
On 2005-10-28, at 00:24, gj
Gregory Maxwell wrote:
Yes, MySQL is broken in some regards, as usual. However, the API isn't
bad (except for the fact that it doesn't care what invalid crap you
throw at it), and more importantly there are thousands of apps and
developers who think around that interface. We should copy it
Jim C. Nasby wrote:
Like I said, if we're going to support a concept of ordering of items in
an enum then we need to support it fully. For starters that means having
the ability to re-order things in an enum seamlessly.
I do not see this at all. An enumeration defines an ordering and a
On Thu, Oct 27, 2005 at 07:02:45PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
On another note, I noticed that the comparison operators seem to be
comparing the underlying numeric value used to store the enum, which is
wrong IMO. Consider:
ENUM color 'red,blue,green'
CREATE TABLE t (c
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Like I said, if we're going to support a concept of ordering of items in
an enum then we need to support it fully. For starters that means having
the ability to re-order things in an enum seamlessly.
I do not see this at
On Oct 28, 2005, at 9:23 , Trent Shipley wrote:
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Like I said, if we're going to support a concept of ordering of
items in
an enum then we need to support it fully. For starters that means
having
the ability to
Sorry for all this crap, this is bullocks.
reason was, one of internal functions didn't filled out length value,
and since the type is variable length, we had trouble.
Postgres wasn't copying anything, since length was 0, hence the NULL -
key.
So here's little request. Could someone please put
Trent Shipley wrote:
An enumeration is just a computer science short-hand way to define a set and a
native collation for the set.
An enumeration's native collation need not be the only, or even the most
common, collation for the enumerated set of symbols.
No it's not. Many
The docs have this description for pg_class::relfilenode: Name of the
on-disk file of this relation; 0 if none. However, Elein just pointed
out to me that there are no entries with 0, so this description seems
incorrect. What should we say? It appears that in at least some of these
cases the
On Thu, Oct 27, 2005 at 05:41:01PM -0600, Michael Fuhr wrote:
If you want values ordered lexically then you can enumerate them
that way. Why force that behavior on people who want to order based
on some other criteria?
Well, I was arguing about the default behavior. I'd bet that we're going
What about use the declaration order as the enum order?, for example: if I
declare something like: CREATE ENUM hola ('item1', 'item3', 'item2');
-this is just assuming an hypothetical approach to use enum types in this
way- and the logical order of the items could be 'item1', 'item3', 'item2'
just
Jim C. Nasby wrote:
Andrew, you mentioned that if you want to change the ordering you should
just create a new type. What about if you need to change the values that
are in the enum? MySQL does (or at least did, it's been some time since
I've messed with this) a horrible job at that. There's
Cristian Prieto wrote:
What about use the declaration order as the enum order?, for example: if I
declare something like: CREATE ENUM hola ('item1', 'item3', 'item2');
-this is just assuming an hypothetical approach to use enum types in this
way- and the logical order of the items could be
On Thu, Oct 27, 2005 at 09:12:15PM -0400, Andrew Dunstan wrote:
The docs have this description for pg_class::relfilenode: Name of the
on-disk file of this relation; 0 if none. However, Elein just pointed
out to me that there are no entries with 0, so this description seems
incorrect. What
Grzegorz - it'd be great if you submitted documentation improvements :)
Grzegorz Jaskiewicz wrote:
Sorry for all this crap, this is bullocks.
reason was, one of internal functions didn't filled out length value,
and since the type is variable length, we had trouble.
Postgres wasn't copying
On Thu, Oct 27, 2005 at 09:12:15PM -0400, Andrew Dunstan wrote:
The docs have this description for pg_class::relfilenode: Name of the
on-disk file of this relation; 0 if none. However, Elein just pointed
out to me that there are no entries with 0, so this description seems
incorrect. What
On Thursday 2005-10-27 17:39, Michael Glaesemann wrote:
On Oct 28, 2005, at 9:23 , Trent Shipley wrote:
On Thursday 2005-10-27 16:22, Andrew Dunstan wrote:
Jim C. Nasby wrote:
snip/
Relational databases already have a type for unordered sets: tables.
IMO, if there's going to be a separate
Andrew Dunstan [EMAIL PROTECTED] writes:
The docs have this description for pg_class::relfilenode: Name of the
on-disk file of this relation; 0 if none. However, Elein just pointed
out to me that there are no entries with 0, so this description seems
incorrect. What should we say? It
On Thu, Oct 27, 2005 at 09:45:05PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Andrew, you mentioned that if you want to change the ordering you should
just create a new type. What about if you need to change the values that
are in the enum? MySQL does (or at least did, it's been
Ted Rolle wrote:
This little snippet is great! The only problem I see is that the
enums must be consistent across all modules.
What about loading a variable with a default value? Then it could
be adjusted to 'play'.
You can set a default for a variable using one of these types, as
It would just be a standard ALTER TABLE foo ALTER COLUMN bar TYPE
newtype USING expression operation. You would write a function that
took a value of the old type and returned a value of the new type and
use a cll to that function in the expression. Since these would be named
types,
Just testing pl/pgsql functions in 8.1beta4, I see failures for syntax that
works in 8.0.3. The simplest test case for this is:
create table ptest(foo int, bar varchar(10));
create or replace function modify_ptest(
foo int,
bar varchar)
returns numeric as $$
declare
res
Jim C. Nasby wrote:
On Thu, Oct 27, 2005 at 09:45:05PM -0400, Andrew Dunstan wrote:
Jim C. Nasby wrote:
Andrew, you mentioned that if you want to change the ordering you should
just create a new type. What about if you need to change the values that
are in the enum? MySQL does (or
The other issue is ease of use.
We used lookup tables in bugzilla when it was converted to work with
Postgres. But many users will find having to do that annoying, to say
the least. I think there's a very good case for providing true enums.
Then why did you use lookup tables instead of a
On Fri, 28 Oct 2005, Philip Yarra wrote:
Just testing pl/pgsql functions in 8.1beta4, I see failures for syntax that
works in 8.0.3. The simplest test case for this is:
The function below fails for me similarly in 8.0.3 on execution. 8.1
merely tells you at creation time.
Using bar and foo
Jim C. Nasby [EMAIL PROTECTED] writes:
On Wed, Oct 26, 2005 at 09:29:23PM -0400, Tom Lane wrote:
Could you send me the whole file (off-list)?
Ok, will send URL as soon as I have it from client.
Well, the answer is that there's nothing wrong with that index except
that four consecutive pages
On Fri, 28 Oct 2005 01:37 pm, Stephan Szabo wrote:
The function below fails for me similarly in 8.0.3 on execution. 8.1
merely tells you at creation time.
Ah, good point... works for very small values of works then :-) My
mistake.
Using bar and foo as both parameter names and the field
Philip Yarra [EMAIL PROTECTED] writes:
Without really wishing to volunteer myself: should plpgsql allow using
parameters with the same name as the columns being referred to within the
function, provided they're qualified as function_name.parameter?
No, because that just changes where the
On Thu, Oct 27, 2005 at 11:53:01PM -0400, Tom Lane wrote:
BTW, Jim, any thoughts about how the index got corrupted? Have you
had any crashes on that machine lately?
Write-through cache on drive array that's not battery backed. Plus, the
backend has been crashing on a sig 11 about once a week
Gavin Sherry [EMAIL PROTECTED] writes:
Definately. I've seen faulty hardware somehow zero blocks where I would
have expected random data. I wonder if we can test with PageIsNew(), which
is very inexpensive. The question is: what do we do when we detect this?
I think erroring out with a message
On Fri, 28 Oct 2005 02:10 pm, Tom Lane wrote:
Without really wishing to volunteer myself: should plpgsql allow using
parameters with the same name as the columns being referred to within the
function, provided they're qualified as function_name.parameter?
No, because that just changes
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Oct 27, 2005 at 11:53:01PM -0400, Tom Lane wrote:
BTW, Jim, any thoughts about how the index got corrupted? Have you
had any crashes on that machine lately?
Write-through cache on drive array that's not battery backed. Plus, the
backend has
Philip Yarra [EMAIL PROTECTED] writes:
Hmmm... is it feasible to make the error message a little more useful?
People who didn't use the old-style positional parameters might not
understand where $1 and $2 are coming from.
Not sure how --- the arm's-length relationship between plpgsql and the
On Fri, 28 Oct 2005, Christopher Kings-Lynne wrote:
Grzegorz - it'd be great if you submitted documentation improvements :)
I don't see any GiST specific problem in Grzegorz's case.
Grzegorz Jaskiewicz wrote:
Sorry for all this crap, this is bullocks.
reason was, one of internal functions
On Fri, 28 Oct 2005 03:03 pm, Tom Lane wrote:
Philip Yarra [EMAIL PROTECTED] writes:
Hmmm... is it feasible to make the error message a little more useful?
People who didn't use the old-style positional parameters might not
understand where $1 and $2 are coming from.
Not sure how --- the
1 - 100 of 102 matches
Mail list logo
