>I also installed iodbc like in the howto ...
You need iodbc only if you establish an ODBC connection from ur linux
box
> The problem comes into play when
i try to establish a tcp/ip
connection from windows
The point is tcp/ip
postmaster -i
-i option aloow accept tcp/ip
connections
I recently compiled Postgresql 7.3.1 on a Redhat 7.3 machine and everything seems to
be working ok except pg_retore. I get the following error message when running
pg_restore on a dump archive:
pg_restore: [custom archiver] out of memory
I can't figure this out. Does anyone know what the sol
Greetings Group,
I'm running 7.1.
Basically, my question is this: how do I delete an exact dup without
deleting the original?
Let me explain...
I just accidentally ran a restore on my perfectly running database. When I
originally made the dump file, I had OIDs turned on. I figured they were
On Sun, 5 Jan 2003, Jack Flak wrote:
> So, once again, here's my question: how do I go about deleting the
> duplicate entries WITHOUT also deleting the originals?
Maybe a dump with some awk/perl magic followed by a restore might be
the easiest way. :-(
"pg_dump -a -D" might give output that is
On Sun, 5 Jan 2003, Jack Flak wrote:
> Greetings Group,
>
> I'm running 7.1.
>
> Basically, my question is this: how do I delete an exact dup without
> deleting the original?
You can use one of the other hidden fields. ctid will be unique for the
various rows, but I'm not sure of a good way to
Jack Flak <[EMAIL PROTECTED]> writes:
> So, once again, here's my question: how do I go about deleting the
> duplicate entries WITHOUT also deleting the originals?
Perhaps something like
CREATE TABLE foo AS SELECT DISTINCT * FROM original;
then delete all from original, then INSERT INT
This is a rough description, should anyone see a need to correct it
please do so.
On Sat, 2003-01-04 at 09:42, Gaetano Mendola wrote:
> NOTICE: Pages 2518: Changed 38, Empty 0; Tup 75489: Vac 447, Keep 68661,
> UnUsed 144574.
> Total CPU 1.31s/0.25u sec elapsed 48.23 sec.
Pages = the # o
AFAIK there is no such function. I think you could create one in C by
look at both the semantics of pggetusername and the code that captures
connection ips for purpose of writing to the log files.
Robert Treat
On Sat, 2003-01-04 at 06:08, Rajesh Kumar Mallah. wrote:
>
> I had asked the same que
Robert Treat <[EMAIL PROTECTED]> writes:
> Tup = # of "rows" in your table
Right. This is the number of rows remaining after the vacuum, to be
precise.
> Keep = # of tuples that the db did not feel it could safely mark/remove
> (probably envolved in some type of transaction)
More specifically,
At some point after we upgraded to Postgres 7.2 from 7.1, we noticed that
VACUUM ANALYZE wasn't updating pg_class.reltuples. It only happened for
systems where we'd upgraded; a fresh installation or a new database was
not affected. So we started using
# vacuum TABLENAME; analyze TABLENAME;
wher
Would this work for you (if you can muck with the comm table temporarily
without causing problems)?
--Create a table with unique values
create temporary table communique as select distinct * from comm;
--Empty the table
delete from comm;
(or truncate comm if recent enough version or drop and rec
On Mon, 6 Jan 2003, Jeff Boes wrote:
>
> [...] Suddenly [...] ANALYZE isn't working properly (it is recording
> pg_class.reltuples far lower than the actual row count).
I had the same problem recently...
http://archives.postgresql.org/pgsql-bugs/2002-08/msg00015.php
where "vacuum analyze" and "
Jeff Boes <[EMAIL PROTECTED]> writes:
> This is just way too weird:
> $ psql
> # select count(*) from stat_fetch;
> count
>
> 143243
> (1 row)
> (Big table, two indexes.)
> # analyze stat_fetch;
> ANALYZE
> (That should update all the stats, right?)
> # select relname, reltuples fr
Hi. I have suffered for the last few years with M$ft access as the database
backbone for an application that I have been running. After scouring the
internet, I have switched the application to running on Linux, and using
Postgresql.
The main issue I had with Access was that as the database got
Hai David,
Thousands of thanks for Ur detailed explanation regarding my doubts.
It was quiet useful.
Thanks,
Senthil
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
15 matches
Mail list logo
