Althoug this happens on old 6.5.3, I would like to know if this has
been already fixed...
Here is the scenario:
1) before vacuum, table A has 8850 tuples.
2) vacuum on table A makes postgres crashed.
3) it crashes at line 1758:
Assert(num_moved == checked_moved);
I examined v
"Michael Richards" <[EMAIL PROTECTED]> writes:
> Following that I find the 2 word tuple pointers.
> The first word appears to be the offset in the page where the tuple can be
> found but the MSB has to be stripped off (haven't found it's function in the
> source yet).
> The second is the transact
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > pg_options.sample coming with 7.0.x does not work because:
> > 1) it exceeds 4096 bytes while read_pg_options() reads only first 4096
> >bytes of it.
>
> Oliver Elphick posted a patch for this recently (pghackers 28-Nov)
> and noted that it seeme
> Bruce Momjian writes:
>
> > ERROR: triggered data change violation on relation "primarytest2"
>
> We're getting this report about once every 48 hours, which would make it a
> FAQ. (hint, hint)
>
First time I heard of it. Does anyone know more details?
--
Bruce Momjian
On Thu, 14 Dec 2000, Christopher Kings-Lynne wrote:
> Plenty of other databases need to be 'vacuumed'. For instance, if you have
> an ms access database with 5 MB of data in it, and then delete all the data,
> leaving only the forms, etc - you will be left with a 5MB mdb file still!
>
> If you
> But why? I don't know of other databases that need to be 'vacuum'ed. Do
> all others just do it internaly on a regular basis?
>
> What am I missing here?
Plenty of other databases need to be 'vacuumed'. For instance, if you have
an ms access database with 5 MB of data in it, and then delete
On Wed, 13 Dec 2000, bpalmer wrote:
> > Yes, postgresql requires vacuum quite often otherwise queries and
> > updates start taking ungodly amounts of time to complete. If you're
> > having problems because vacuum locks up your tables for too long
> > you might want to check out:
>
> But why? I
> Yes, postgresql requires vacuum quite often otherwise queries and
> updates start taking ungodly amounts of time to complete. If you're
> having problems because vacuum locks up your tables for too long
> you might want to check out:
But why? I don't know of other databases that need to be 'v
* xuyifeng <[EMAIL PROTECTED]> [001213 18:54] wrote:
> I have this nasty problem too, in early time, I don't know the problem, but we used
>it for a while,
> than we found our table growing too fast without insert any record( we use update),
>this behaviour
> most like M$ MSACCESS database I h
I have this nasty problem too, in early time, I don't know the problem, but we used
it for a while,
than we found our table growing too fast without insert any record( we use update),
this behaviour
most like M$ MSACCESS database I had used a long time ago which don't reuse deleted
record
sp
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> That's odd, because it's in the 7.0.3 documentation...
Where? A quick grep doesn't find it there anywhere.
regards, tom lane
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> pg_options.sample coming with 7.0.x does not work because:
> 1) it exceeds 4096 bytes while read_pg_options() reads only first 4096
>bytes of it.
Oliver Elphick posted a patch for this recently (pghackers 28-Nov)
and noted that it seemed already fixe
I have this nasty problem too, in early time, I don't know the problem, but we used
it for a while,
than we found our table growing too fast without insert any record( we use update),
this behaviour
most like M$ MSACCESS database I had used a long time ago which don't reuse deleted
record
sp
beta1 was very low key ... it was announced here on the list as "its
packaged, try it out" ... there was no big hype about this one, but there
will be for beta2, which will most likely be after Vadim gets those vacuum
fixes in place, and Tom gets those planner fixes ...
On Thu, 14 Dec 2000, Tats
Thanks for responding. I've made some comments below.
On Wed, 13 Dec 2000, Nathan Myers wrote:
> On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote:
> > On Tue, 12 Dec 2000, Nathan Myers wrote:
> > > On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote:
> > > > > I was co-arc
That's odd, because it's in the 7.0.3 documentation...
Chris
> -Original Message-
> From: Peter Eisentraut [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 14, 2000 3:29 AM
> To: Christopher Kings-Lynne
> Cc: Pgsql-Hackers
> Subject: Re: [HACKERS] Bug in ILIKE function?
>
>
> Chri
pg_options.sample coming with 7.0.x does not work because:
1) it exceeds 4096 bytes while read_pg_options() reads only first 4096
bytes of it.
2) it allows spaces around "=" while parese_options() does not.
Apparently the sample file was brought in without enough testings when
7.0 was develo
I seem to miss the announce of beta testing of 7.1. Could someone
please give me a copy of the announcement?
--
Tatsuo Ishii
Alfred Perlstein <[EMAIL PROTECTED]> writes:
> If you're saying that you're OK with the work Vadim has done please
> let him know, I'm assuming he hasn't committed out of respect for your
> still standing objection.
Well, I'm still against committing it now, but I only have one core
vote, and I s
Hi.
I need a little help on the format of the postgres tables.
I've got this wonderfully corrupted database where just about everything is
fubar. I've tried a number of things to get it back using postgres and
related tools with no success. It looks like most of the data is there, but
there may
> I still don't see how dirty reads can solve the RI problems.
> If Xact A deletes a PK while Xact B inserts an FK, one of
> them will either see the new reference or the PK gone. But
> from a transactional POV it depends on if the opposite Xact
> finally commits or n
sorry, meant to respond to the original and deleted it too fast ...
Tom, if the difference between 7.0 and 7.1 is such that there is a
performance decrease, *please* apply the fix ... with the boon that OUTER
JOINs will provide, would hate to see us with a performance hit reducing
that impact .
* Tom Lane <[EMAIL PROTECTED]> [001213 15:18] wrote:
>
> I'm trying to resist the temptation to make this change right now :-).
> It's not quite a bug fix --- well, maybe you could call it a performance
> bug fix --- so I'm kind of thinking it shouldn't be done during beta.
> OTOH I seem to have
I need a little help on the format of the postgres tables.
I've got this wonderfully corrupted database where just about everything is
fubar. I've tried a number of things to get it back using postgres and
related tools with no success. It looks like most of the data is there, but
there may
Got it --- was the proverbial one-line fix --- thanks for the report!
regards, tom lane
bpalmer wrote:
>
> I noticed the other day that one of my pg databases was slow, so I ran
> vacuum on it, which brought a question to mind: why the need? I looked
> at my oracle server and we aren't doing anything of the sort (that I can
> find), so why does pg need it? Any info?
Hi,
I'm
* Martin A. Marques <[EMAIL PROTECTED]> [001213 15:15] wrote:
> El Mié 13 Dic 2000 16:41, bpalmer escribió:
> > I noticed the other day that one of my pg databases was slow, so I ran
> > vacuum on it, which brought a question to mind: why the need? I looked
> > at my oracle server and we aren'
I've been looking into Brian Hirt's complaint that 7.0.3 and 7.1 are
lots slower than 7.0.2 in planning big joins. The direct cause is that
since we now deduce implied equality clauses, the system has more
potential join paths than it used to --- for example, given "WHERE
a.x = b.y AND b.y = c.z"
El Mié 13 Dic 2000 16:41, bpalmer escribió:
> I noticed the other day that one of my pg databases was slow, so I ran
> vacuum on it, which brought a question to mind: why the need? I looked
> at my oracle server and we aren't doing anything of the sort (that I can
> find), so why does pg need
Hannu Krosing wrote:
>
> mlw wrote:
> >
> > Let me explain why I think the changes I mentioned are a good thing.
> >
> > (BTW gateway.mohawksoft.com seems to going to an old IP address that I
> > haven't had for years, something is strange.)
> >
> > So, using the IP address, go to this web site.
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing anything of the sort (that I can
find), so why does pg need it? Any info?
Thanks,
- brandon
b. palmer, [EM
On Wed, 13 Dec 2000, mlw wrote:
> Assuming all my assumptions are correct, (and I can't see how that is
> possible ;-), I should also call the Init function at this time.
>
> The big problem is calling the "Exit" function. I am sure that will not
> be easily done, or even doable, but we can drea
mlw wrote:
>
> Let me explain why I think the changes I mentioned are a good thing.
>
> (BTW gateway.mohawksoft.com seems to going to an old IP address that I
> haven't had for years, something is strange.)
>
> So, using the IP address, go to this web site.
> http://216.41.12.226/search
On Wed, Dec 13, 2000 at 03:16:28PM -0500, Randy Jonasz wrote:
> On Tue, 12 Dec 2000, Nathan Myers wrote:
> > On Tue, Dec 12, 2000 at 05:28:46PM -0500, Bruce Momjian wrote:
> > > > I was co-architect of the Rogue Wave Dbtools.h++ interface design
> > > > ... The design is really showing its age.
>
Database research papers at berkeley are at:
http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/papers/
On Wednesday 13 December 2000 12:16, DÅ wrote:
> Hi!
>
> My name is Daniel Åkerud, a swedish studen, writing an essay for my exam.
> The label will be something like: "Database algorithms".
> I know
Hi,
Where can I find documentation on WAL, TOAST and how to configure the
pg_hda.conf file?
Saludos... ;-)
--
System Administration: It's a dirty job,
but someone told I had to do it.
-
Martín Marqués
Interesting comments. I can see using the STL framework for iterating
through result sets being one way to go. Would something like:
vectortable = pgdb.exec("Select * from foo");
vector::iterator row;
vector::iterator end = table.end();
for( row = table.begin(); row != end; ++row ) {
*row >
I'm trying to delete all the records or only one record from a table but
i'm having this message:
ERROR: Unable to identify an operator '=' for types 'int4' and 'text'
You will have to retype this query using an explicit cast
What's this means ???
Thanks
Luis Sousa
Bruce Momjian writes:
> ERROR: triggered data change violation on relation "primarytest2"
We're getting this report about once every 48 hours, which would make it a
FAQ. (hint, hint)
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Christopher Kings-Lynne writes:
> I have just tried using the ILIKE function in 7.0.3.
There is no ILIKE function in 7.0.3.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
I found it in the PostgreSQL Administrator manual under "Managing Kernel
Resources".
Wade Oberpriller
>
> Hi,
> I have been using Postgres-7.0.2 on Solaris 8 for the past few months, and
> was about to upgrade to 7.1-test, and after following carefully the docs, I
> get this:
>
> postgres@u
Hi!
My name is Daniel Åkerud, a swedish studen, writing an essay for my exam.
The label will be something like: "Database algorithms".
I know it is a complex task, and will ofcourse, as soon as possible,
specify more preciesly what it will be about.
I have thoughts about writing about, for examp
Hi!
My name is Daniel Åkerud, a swedish studen, writing an essay for my exam.
The label will be something like: "Database algorithms".
I know it is a complex task, and will ofcourse, as soon as possible,
specify more preciesly what it will be about.
I have thoughts about writing about, for examp
Tom Lane writes:
> I take it from the smiley that you're not serious, but actually it seems
> like it might not be a bad idea. I could see appending a CRC to each
> tuple record. Comments anyone?
I think I missed the point here. With CRC you typically want to detect
data corruption. Where's
Max Khon <[EMAIL PROTECTED]> writes:
> test=# select a.id, b.id from a left join b using(id);
> id | id
> +
> 43 |
> 45 |
> (2 rows)
> test=# select * from a;
> id
>
> 45
> 43
> 34
> (3 rows)
Ugh. It looks like mergejoin must be mishandling the first left-side
item w
Hi!
My name is Daniel Åkerud, a swedish studen, writing an essay for my exam.
The label will be something like: "Database algorithms".
I know it is a complex task, and will ofcourse, as soon as possible,
specify more preciesly what it will be about.
I have thoughts about writing about, for examp
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> However, is it possible to create a type that has different parameters
> wherever it is used.
> For instance - the varchar type takes as a parameter the max characters in
> the field. Although there is only one varchar type, it has different
Martin A. Marques writes:
> IpcSemaphoreCreate: semget(key=5432004, num=17, 03600) failed: No space left
> on
> device
http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.htm#SYSVIPC
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Hi,
we are getting a bit close to add index support for int arrays using
GiST interface. This will really drive up performance of our full text
search fully based on postgresql. We have a problem with broken index
and couldn't find a reason. I attached archive with sources
for GiST functions and
Mikheev, Vadim wrote:
> > > So, I've run simple test (below) to check this. Seems that 7.1
> > > is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> > > triggers is quite bad for performance.
> > > Also, we should add new TODO item: implement dirty reads
> > > and use them in RI tri
El Lun 11 Dic 2000 12:07, Martin A. Marques escribió:
> Hi,
> I have been using Postgres-7.0.2 on Solaris 8 for the past few months, and
> was about to upgrade to 7.1-test, and after following carefully the docs, I
> get this:
>
> postgres@ultra31:~ > /usr/local/pgsql/bin/postmaster -D
> /usr/loca
hi, there!
test=# create table a(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
table 'a'
CREATE
test=# create table b(id int references a);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into a v
Let me explain why I think the changes I mentioned are a good thing.
(BTW gateway.mohawksoft.com seems to going to an old IP address that I
haven't had for years, something is strange.)
So, using the IP address, go to this web site.
http://216.41.12.226/search.php3
This is a test pag
>>
>> create unique index child_id_index on child (id);
>Thanks a lot. You saved my day :-)))
Always feels good to be able to help :-)
> > > CREATE TABLE will create implicit trigger(s) for FOREIGN
> KEY check(s)
> > > ERROR: UNIQUE constraint matching given keys for referenced
> > > tab
hi, there!
test=# create table a(id int primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'a_pkey' for
table 'a'
CREATE
test=# create table b(id int references a);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
test=# insert into a v
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > I just have to find where I call the exit function.
>
> That will be the hard part.
>
> FmgrInfo is not currently considered a durable data structure, and I
> think you will be in for grief if you try to make any guarantees about
> what wi
> I stated this before, but I did not get a helpful answer. I
> might have
> misunderstood tghe documentation on foreign keys:
>
> create table global(id serial);
> create table child(anything text) inherits(global);
need:
create unique index child_id_index on child (id);
> gives me
I stated this before, but I did not get a helpful answer. I might have
misunderstood tghe documentation on foreign keys:
create table global(id serial);
create table child(anything text) inherits(global);
insert into child(anything) values ('test);
Now, a select * from child shows
id anyth
On 13 Dec 2000, Anatoly K. Lasareff wrote:
> Date: 13 Dec 2000 14:06:16 +0300
> From: "Anatoly K. Lasareff" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Locale and multibyte support in 7.1
>
>
> Hi!
>
> I download, configure and install postgresql-7.1beta1 _exactly_ the
> s
Hi!
I download, configure and install postgresql-7.1beta1 _exactly_ the
same way as my previous version - 7.0.2:
./configure --enable-multibyte=KOI8 --enable-locale
gmake
gmake install
initdb
But it seems to me locale support gone out. In particulary
select upper('òÕÓÓËÉÊ ÔÅËÓÔ - Russian
> > anyway? ;-)) If so, a search for artistid 100050450 definitely *should*
> > use a sequential scan.
>
> I tested this statement against the database and you are right, about 14
> seconds with the index, 4 without.
Now I don't understand the problem any more. Are you complaining, that
the op
Hello all,
sorry, but I haven't received any replies to my previous message... and
it's important for me to solve it.
When I perform an action on a psql database (e.g. insert into a table),
some more action could be induced, via trigger firing:
- is it possible to know at any time the exact act
Christopher Kings-Lynne wrote:
>
> Hi,
>
> I have just tried using the ILIKE function in 7.0.3. I assume that it is
> just a case-insensitive version of LIKE. (Please correct me if I am wrong
> on this assumption.)
AFAIK postgres 7.0.3 does not have it, ILIKE appeared in 7.1
But you could u
63 matches
Mail list logo
