On Thursday 14 December 2000 23:04, Vadim Mikheev wrote:
> > I wouldn't consider it's a bug, but from my point of view it is quite
> > strange. Any comments?
> >
> > BTW, I did a backup, and can supply anyone interested with original
> > table.
>
> Please send it me.
Another small comment. I did
Try \copy or copy commands in psql:
I normally use \copy for tab-delimited files.
But copy also works and has help
\h copy
Command: COPY
Description: Copies data between files and tables
Syntax:
COPY [ BINARY ] table [ WITH OIDS ]
FROM { 'filename' | stdin }
[ [USING] DELIMITER
Hi,
I have written a 'C' function to be called during INSERT trigger on a
table.
Are there any restrictions on the functions that can be called?
I know you can call SPI_* functions. But, can I call PQ* functions ?
e.g PQsetdb.
Is there any document which describes how the functions
I have obtained the CRC-64 code used in the SWISS-PROT genetic
database:
ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/SPcrc.tar.gz
(Thanks go to Henning Hermjakob <[EMAIL PROTECTED]> of the European
Bioinformatics Institute.) From the README:
The code in this package has been der
What is the schema of the table involved and what are the queries you
are trying to run?
Stephan Szabo
[EMAIL PROTECTED]
On Thu, 14 Dec 2000, Luis Sousa wrote:
> I'm trying to delete all the records or only one record or insert one
> record in a table but
> i'm having this message:
> ERROR: U
Alfred Perlstein wrote:
>
> If you're talking about vacuum, you really don't want to do this,
No, I'm not talking about vacuum as it is intended now, it's only a
process that scans tables to find available blocks/tuples. It is
virtually optional, if it doesn't run, the database will behave just
* mlw <[EMAIL PROTECTED]> [001214 09:30] wrote:
> "Martin A. Marques" 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 m
"Martin A. Marques" 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't doing anything of the sort (th
* Daniele Orlandi <[EMAIL PROTECTED]> [001214 09:10] wrote:
> Zeugswetter Andreas SB wrote:
> >
> > If the priority is too low you will end up with the same behavior as current,
>
> Yes, and it is the intended behaviour. I'd use idle priority for it.
If you're talking about vacuum, you really d
Zeugswetter Andreas SB wrote:
>
> If the priority is too low you will end up with the same behavior as current,
Yes, and it is the intended behaviour. I'd use idle priority for it.
> because the cache will be emptied by high priority multiple new rows,
> thus writing to the end anyways.
Yes, b
> when doing txlog switches there seems to be a problem with remembering the
> correct = active logfile, when the postmaster crashes.
>
> This is one of the problems I tried to show up previously:
> You cannot rely on writes to other files except the txlog itself !!!
Why? If you handle those fi
> I wouldn't consider it's a bug, but from my point of view it is quite strange.
> Any comments?
>
> BTW, I did a backup, and can supply anyone interested with original table.
Please send it me.
Vadim
> > > The tendency here seems to be towards an improved smgr.
> > > But, it is currently extremely cheap to calculate where a new row
> > > needs to be located physically. This task is *a lot* more expensive
> > > in an overwrite smgr.
>
> I don't agree. If (as I have proposed) the search is mad
* Ross J. Reedstrom <[EMAIL PROTECTED]> [001214 07:57] wrote:
> On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
> >
> > They all have an overwriting storage manager. The current storage manager
> > of PostgreSQL is non overwriting, which has other advantages.
> >
> > Ther
"Ross J. Reedstrom" wrote:
>
> On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
> >
> > The tendency here seems to be towards an improved smgr.
> > But, it is currently extremely cheap to calculate where a new row
> > needs to be located physically. This task is *a lot* mor
when doing txlog switches there seems to be a problem with remembering the
correct = active logfile, when the postmaster crashes.
This is one of the problems I tried to show up previously:
You cannot rely on writes to other files except the txlog itself !!!
Thus the current way of recor
On Thu, Dec 14, 2000 at 01:16:20PM +, Hannu Krosing wrote:
> The Hermit Hacker wrote:
> > vadim, for v7.2, is planning on re-writing the storage manager to do
> > proper overwriting of deleted space, which will reduce the requirement for
> > vacuum to almost never ...
>
> I hope that he do
"Ross J. Reedstrom" wrote:
>
> Not to mention the recent thread here about people recovering data that
> was accidently deleted, or from damaged db files: the old tuples serve
> as redundant backup, in a way. Not a real compelling reason to keep a
> non-overwriting smgr, but still a surprise bonu
On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
>
> They all have an overwriting storage manager. The current storage manager
> of PostgreSQL is non overwriting, which has other advantages.
>
> There seem to be 2 answers to the problem:
> 1. change to an overwrite storage
Okay,
Where would I find a definition of the tuple data? I didn't see anything
promising in include/storage?
I've found a definition for the page inside pagebuf.h That clears up all the
page stuff. I'm still having a little trouble decoding the tuple data
within. Hannu Krosing sent me a python s
> 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
Without knowing your schema and query, we can't tell you exactly. But
your query is trying to compare a string to an integer, whi
> When the filesystem fills and the txlog cannot be written,
> then the postmaster dies.
>
> postgres@s0188000zeu:/usr/postgres> time echo "copy
> journaleintrag from '/tmp/j.unl' delimiters '|';" | psql cusejoua
> FATAL 2: copy: line 64902, write(logfile 0 seg 2 off
> 6094848) failed: No sp
When the filesystem fills and the txlog cannot be written, then the postmaster dies.
postgres@s0188000zeu:/usr/postgres> time echo "copy journaleintrag from '/tmp/j.unl'
delimiters '|';" | psql cusejoua
FATAL 2: copy: line 64902, write(logfile 0 seg 2 off 6094848) failed: No space left
on dev
I'm trying to delete all the records or only one record or insert one
record in 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 wrote:
> > 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?
Hello,
I just have installed Vadim's patch for speeding up vacuum.
And have quite strange problem.
I have quite small table:
[root@mx src]# ls -l /home/postgres/data/base/db/users*
-rw--- 1 postgres postgres 4120576 Dec 14 08:48
/home/postgres/data/base/db/users
-rw--- 1 postgres po
El Mié 13 Dic 2000 22:24, xuyifeng escribió:
> 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 l
Hello,
Another question about vacuum. Will vacuum/drop/create deadlocks be fixed in
7.0.x branch? That's really annoying. I cannot run vacuum automatically due
to this. Just a patch will be really great. Is it so hard to fix?
--
Sincerely Yours,
Denis Perchine
---
The Hermit Hacker wrote:
>
> 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 m
> > 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
Michael Richards wrote:
>
> 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
Hi all,
I am adressing this email to this mailinglist due to the lack of some
address to post euphoric feedback to. Let me tell you my story:
This february I began working on a web-application using PHP and a
SQL-Database. My problem was to evaluate the right one:
Interbase was at the state of
Tim Allen wrote:
>
> 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 5M
Sorry for the website is not accessble that time but now it can be
access at this url http://208.160.255.143
this include an easy installation of PostgreSQL v.7.0.2 for windows
98,2000 and NT. there is a pg guardian that automatically start and setup
ur server and many more...:) hope you l
Sorry...that url for easy PostgreSQL (windowsm
35 matches
Mail list logo
