Sorry...that url for easy PostgreSQL (windowsm
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
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
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
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
> > 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
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
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
---
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,
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
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?
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
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
> 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
> 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
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
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
"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 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
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
"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
* 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
> > > 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
> 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
> 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
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
* 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
"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
* 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
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
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
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
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
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
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
35 matches
Mail list logo
