Hello,
I am writing a SPI function to run maintenance tasks on my auction
system but it keeps crashing the backend after running only one loop.
Now, I am not a C programmer, nor do I have any formal training in CS. I
thought I might run this function by you guys so that a cursory look
might revea
> Hmm,it seems that both current and REL7_0_PATCHES
> have already been changed.
> I committed the the change to current tree and
> asked Tatsuo to commit it to REL7_0_PATCHES tree.
I also committed current -:))
Vadim
"Mikheev, Vadim" wrote:
> > > Btree doesn't take into account that tuple was just marked
> > > for update but still alive. Seems it was handled properly in 6.5.X ?
> >
> > Nope. It has been broken a long time...
>
> Hmm, as I remember, Hiroshi fixed something in this area for 7.0.X.
> Hiroshi?
>
figuring I'd try out getting into the backend using postgres, to see if I
can 'bypass' some of the errors on those corrupted database, I'm wondering
if there is any way of taking what a 'select * from ' outputs:
1: userid = "cibc001154" (typeid = 1043, len = -1, typmod = 36, byval
> On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
> > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
> > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
> > ...
> > pg_mbcliplen cannot be used in the frontend. Remove them, please.
>
> Is there any way to use a s
Wow, has this been just one of those days ...
Trying to clean up a few of the database, I'm wondering how to fix some of
these things, if its even possible, without having to rebuild the whole
database:
%~/bin/postgres -O -P -D/pgsql/special/sales.org swissre
DEBUG: Data Base System is starti
Hello again.
I'm in the process of making a COM wrapper (enabling VB to connect to
PostGres) for the libpq library using Visual Studio 6.0 Pro, but have
a few problems. I can make use of the libpq.dll library from the COM
wrapper, but I thought that it might be a bit better if the actual
library
> > Btree doesn't take into account that tuple was just marked
> > for update but still alive. Seems it was handled properly in 6.5.X ?
>
> Nope. It has been broken a long time...
Hmm, as I remember, Hiroshi fixed something in this area for 7.0.X.
Hiroshi?
Probably, his fix somehow disappeared
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Can anyone explain why I must make / a character class
> in case-insensitive query in order to match / ?
What LOCALE are you using? There was a thread about strange ordering
rules confusing the LIKE/regexp optimizer recently ...
> > Btree doesn't take into account that tuple was just marked
> > for update but still alive. Seems it was handled properly in 6.5.X ?
>
> Nope. It has been broken a long time...
Ops. Ok...
Vadim
Can anyone explain why I must make / a character class
in case-insensitive query in order to match / ?
and then why does it work in plain ~ ?
hannu=> select * from item where path ~* '^/a';
path
--
/a/b/c
/a/b/d
/a/d/d
/aa/d
/a/b
/a/c
/a/d
(7 rows)
hannu=> select * from item wher
"Mikheev, Vadim" wrote:
>
> > I get an error (which is good). But, if I do
> >
> > #BEGIN;
> > #SELECT * FROM name_and_ip WHERE name = 'foo' OR name = 'bar' FOR
> > UPDATE;
> > #UPDATE name_and_ip SET ip = '192.168.186.249' where name = 'foo';
> > UPDATE 1
> > #COMMIT;
> > COMMIT
>
> Btre
Jarmo Paavilainen wrote:
>
> ...
> > > Is there a way to make postgre insensitive about field name cases?
> > >
> > > Like
> "initdb --fields-are-case-insensitive --compares-are-case-insensitive"
> ...
> > The main problem I see with case-insensitivity is the fact that there
> > are always more t
> I get an error (which is good). But, if I do
>
> #BEGIN;
> #SELECT * FROM name_and_ip WHERE name = 'foo' OR name = 'bar' FOR
> UPDATE;
> #UPDATE name_and_ip SET ip = '192.168.186.249' where name = 'foo';
> UPDATE 1
> #COMMIT;
> COMMIT
Btree doesn't take into account that tuple was just
@#%@#$@#$@!$@ and checking /var/log/messages confirms that :(
Sep 26 17:01:04 pgsql /kernel: (da1:ahc0:0:1:0): READ(10). CDB: 28 0 0 93 d6 9f 0 0 80
0
Sep 26 17:01:04 pgsql /kernel: (da1:ahc0:0:1:0): HARDWARE FAILURE info:93d6dd asc:32,0
Sep 26 17:01:04 pgsql /kernel: (da1:ahc0:0:1:0): No defe
It looks like you are suffering from actual hardware failures:
%cd /pgsql/data/base/horde
%ls -l pg_attribute_relid_attnam_index
-rw--- 1 pgsql pgsql 65536 Aug 21 12:27 pg_attribute_relid_attnam_index
%wc pg_attribute_relid_attnam_index
wc: pg_attribute_relid_attnam_index: read: Input/outp
* Alfred Perlstein <[EMAIL PROTECTED]> [000920 06:19] wrote:
> There's two tracebacks of crashed 7.0.2 backends at the end of this
> email.
Also, after this the database is extremely unstable, queries lock up
and the postgresql server (not OS) requires a complete restart and
vacuum analyze before
Tom is looking around the server right now, as he wants to try and see
what caused it before we go any further at trying to fix it, but I hadn't
thought to try FORCE ... thanks :)
On Wed, 27 Sep 2000, Hiroshi Inoue wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > The Herm
greetings,
i planning on making heavy use of the postgresql
inheritance features for a large scale application
and i was wondering if anyone has run into any interesting
errata regarding this that i should be aware of.
bugs, features, caveats, side notes etc..
Jeff MacDonald,
---
> -Original Message-
> From: [EMAIL PROTECTED]
> The Hermit Hacker
>
> Can someone add something to the docs that gives an example of what should
> be used from the command line to reindex a database's system tables?
>
> All the man page says is use th e-O an d-P options :(
>
> I'm getting
> I've tried:
>
> bin/postgres -O -P -D `pwd`/data horde
>
> POSTGRES backend interactive interface
> $Revision: 1.155.2.1 $ $Date: 2000/08/30 21:19:32 $
>
> backend> reindex database horde;
> backend>
>
> still get it ...
>
> I'm either doing something wrong with REINDEXng the system
> tab
> > Indice's TIDs are transient.
> > Isn't it useless to store indice's TIDs ?
>
> but yes Hiroshi is right. Index TID is transient. I first looked
> into pg sources two weeks ago so I have still holes in my knowledge.
> So that only solution is to traverse it ..
It was discussed several times f
Why not implement *true* CLUSTER?
With cluster, all heap tuples will be in cluster index.
Vadim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 26, 2000 2:15 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] pgsql is 75 times faster with
> > The last step could be done in two ways. First by limiting
> > number of indices for one table we can store coresponding
> > indices' TIDs in each heap tuple. The update is then simple
> > taking one disk write.
>
> Why limit it ? One could just save an tid array in each tuple .
And update *
Thomas Lockhart wrote:
>
> > Short Description
> > 7.0.2 source rpm failed to compile
> > Long Description
> > I'm running RedHat 6.2 SPARC, two processors, 128 MB RAM
> > I downloaded postgresql-7.0.2-2.src.rpm from your main FTP site and tried 'rpm
>--rebuild postgresql-7.0.2-2.src.rpm', it ra
Can someone add something to the docs that gives an example of what should
be used from the command line to reindex a database's system tables?
All the man page says is use th e-O an d-P options :(
I'm getting:
psql -h pgsql horde
ERROR: cannot read block 6 of pg_attribute_relid_attnam_index
tom is looking into a bug right now that he wants to try and fix before we
release it ... hopefully this week we'll release it ...
On Tue, 26 Sep 2000, G. Anthony Reina wrote:
> I remember a post about 2 weeks back concerning a new patch that was to
> be introduced as 7.0.3. I haven't seen any
...
> > Is there a way to make postgre insensitive about field name cases?
> >
> > Like
"initdb --fields-are-case-insensitive --compares-are-case-insensitive"
...
> The main problem I see with case-insensitivity is the fact that there
> are always more than one way to do it, as it depends on char
I remember a post about 2 weeks back concerning a new patch that was to
be introduced as 7.0.3. I haven't seen any reference to this since then.
Is this still happening, or will the patch be part of 7.1?
-Tony Reina
> Short Description
> 7.0.2 source rpm failed to compile
> Long Description
> I'm running RedHat 6.2 SPARC, two processors, 128 MB RAM
> I downloaded postgresql-7.0.2-2.src.rpm from your main FTP site and tried 'rpm
>--rebuild postgresql-7.0.2-2.src.rpm', it ran fine for a long time but then exit
> > > The last step could be done in two ways. First by limiting
> > > number of indices for one table we can store coresponding
> > > indices' TIDs in each heap tuple. The update is then simple
> > > taking one disk write.
> >
> > Why limit it ? One could just save an tid array in each tuple .
b
> That would be great, or alternatively, an attribute on the index?
yes attribute would be nice.
>
> Dec RDB offers this kind of feature, and it suffers from deadlocking
> problems because of index node vs. row locking as well as high lock
> contention when updating indexed data, so it's not ju
At 10:54 26/09/00 -0400, Tom Lane wrote:
>
>Comments? Is this a general enough mechanism, and does it fit well
>with the various setUID tricks that people are thinking about?
>
Didn't Peter & Jan have a rewrite of the permissions system in the pipeline
- or has that disappeared? What Jan was pro
I'm thinking about changing the way that access permission checks are
handled for rules. The rule mechanism provides that accesses to tables
that are mentioned within rules are done with the permissions of the
rule owner, not the invoking user. The way this is implemented is that
when a rule is
Jarmo Paavilainen wrote:
>
> Hi,
>
> Is there a way to make postgre insensitive about field name cases?
>
> Like "initdb --fields-are-case-insensitive --compares-are-case-insensitive"
>
> Yes I know about "CaseIsKept" and CaseIsNotKept (note the quotes). But that
> gives me more trouble than i
Hannu Krosing wrote:
>
> >
> > TODO:
> > - add HeapTupleHeaderData into each IndexTupleData
> > - change code to reflect above
> > - when deleting-updating heap then also update tuples'
> > HeapTupleHeaderData in indices
>
> I doubt everyone would like trading query speed for insert/update
> s
At 12:28 26/09/00 +0300, Hannu Krosing wrote:
>> TODO:
>> - add HeapTupleHeaderData into each IndexTupleData
>> - change code to reflect above
>> - when deleting-updating heap then also update tuples'
>> HeapTupleHeaderData in indices
>
>I doubt everyone would like trading query speed for insert
[EMAIL PROTECTED] wrote:
>
> Hello,
> I recently spoke about extending index scan to be able
> to take data directly from index pages. I wanted to know
> whether should I spend my time and implement it.
> So that I hacked last pgsql a bit to use proposed scan
> mode and did some measurements (see
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [000926 02:33] wrote:
> Hello,
> I recently spoke about extending index scan to be able
> to take data directly from index pages.
[snip]
>
> Is someone interested in this ??
Considering the speedup, I sure as hell am interested. :)
When are we going to ha
Hello,
I recently spoke about extending index scan to be able
to take data directly from index pages. I wanted to know
whether should I spend my time and implement it.
So that I hacked last pgsql a bit to use proposed scan
mode and did some measurements (see bellow). Measurements
was done on (id i
Hi,
Is there a way to make postgre insensitive about field name cases?
Like "initdb --fields-are-case-insensitive --compares-are-case-insensitive"
Yes I know about "CaseIsKept" and CaseIsNotKept (note the quotes). But that
gives me more trouble than it solves. And what about "case insensitive f
41 matches
Mail list logo
