Hi Tom & pg_list,
> "Shutdown"? Exactly what happened there? It certainly doesn't look
> like you had a clean shutdown.
mmm, yes the postmaster was running in foregroud and was interrupted by a
CTRL+C
What's the correct way to shutdown? kill -15 I think...
> At this point I think your o
Is it possible have on log file the time stamp ?
Ciao
Gaetano
--
#exclude
#include
printf("\t\t\b\b\b\b\b\b");.
printf("\t\t\b\b\b\b\b\b");
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Hi!
There are no problems with large tables.
I am running postgresql with a database with over 100,000,000 records.
The biggest table is with about 55,000,000 rows there are tables with with
25,000,000 and 19,000,000 rows and few other with less than 10,000,000. It
works pretty good. It's online
"Gaetano Mendola" <[EMAIL PROTECTED]> wrote:
> Is it possible have on log file the time stamp ?
>
I find it !!! Thank you anyway.
It's enough send the SIGHUP to postmaster
for don't loose the existing connections?
Ciao
Gaetano
--
#exclude
#include
printf("\t\t\b\b\b\b\b\b");.
printf("\t\t
Always me... ;P
I've just recover my installation by using pg_resetxlog.
But, what is the operation made by this command? I believe it performs a
reset to the previous checkpoint, so some data could be lost..
>From now I'll use the start/stop/status script that I've found in
contrib/start_scr
Jodi Kanter wrote:
> I am currently using a Perl data loader that was set up to load data to
three particular
> tables.
(Snip)
> I have placed some debugging syntax in the code and it seems that the
extra time if
> related to postgres as I had originally thought it may have to do with
the pars
are you running that on 32 bit or 64 bit hardware? I have an 18G
database which is mostly one table. Dumps and restores in
about 2-4 hours but sometimes is slow on certain operations.
Running it on 4G Ram, redhat 7.2 enterprise kernel.
> Hi!
> There are no problems with large tables.
> I a
> my $dbh=DBI->connect(dbi:Pg ...);
>
> my $insh = $dbh->prepare("Insert into table values (?,?,?)";
>
$insh->begin_work;
> foreach ($excelrow){
> parse;
> $insh->execute($data1,$data2,$data3);
> }
$insh->commit;
>
> I have written a few script of that kind my self, and I was really
> surp
Hi, I'm having trouble sorting my data.
I'm using PostgresQL 7.2 compiled with:
--enable-multibyte=LATIN1 --enable-locale
I've also created a test db, with one table:
CREATE DATABASE "testdb" WITH ENCODING = 'LATIN1';
And
CREATE TABLE "sorttest" (
"id" int8 NOT NULL,
"data" varchar(100),
On Mon, 2002-03-25 at 11:14, Niclas Gustafsson wrote:
> Hi, I'm having trouble sorting my data.
>
> I'm using PostgresQL 7.2 compiled with:
> --enable-multibyte=LATIN1 --enable-locale
...
> Then I've inserted some test values which seem to be sorted wrongfully
> when I issue an
> select * from s
Hi,
I am sure that 1) is correct, allthough I think I've overlooked 2)!
pg_controldata reports: (last 2 rows)
LC_COLLATE: en_US
LC_CTYPE: en_US
Is it possible to change this after you've run initdb?
Regards,
Niclas Gustafsson
-Origin
Hrm, a big RTFM to myself. :)
>"The sort order used within a particular database cluster is set
>by initdb and cannot be changed later, short of dumping all data,
>rerunning initdb, and reloading the data."
Well I changed LC_ALL to LATIN1 and run initdb, dumped back all the
data, but the sort
On Mon, 2002-03-25 at 11:47, Niclas Gustafsson wrote:
> Hi,
>
> I am sure that 1) is correct, allthough I think I've overlooked 2)!
> pg_controldata reports: (last 2 rows)
> LC_COLLATE: en_US
> LC_CTYPE: en_US
>
> Is it possible to change th
On Mon, 2002-03-25 at 12:41, Niclas Gustafsson wrote:
> Hrm, a big RTFM to myself. :)
> >"The sort order used within a particular database cluster is set
> >by initdb and cannot be changed later, short of dumping all data,
> >rerunning initdb, and reloading the data."
>
> Well I changed LC_ALL
Sorry, I'm a bit overclocked today, the locale is ofcourse
sv_SE...
-Original Message-
From: Oliver Elphick [mailto:[EMAIL PROTECTED]]
Sent: den 25 mars 2002 13:57
To: Niclas Gustafsson
Cc: [EMAIL PROTECTED]
Subject: Re: [ADMIN] to --enable-locale or not to --enable-locale?
On Mon, 20
On Mon, 2002-03-25 at 12:59, Niclas Gustafsson wrote:
> Sorry, I'm a bit overclocked today, the locale is ofcourse
> sv_SE...
Well if that doesn't sort right, it is a problem with the lcoale
definition, not PostgreSQL. As I understand it, PostgreSQL merely uses
the locale without amendment.
--
I have
multi tables with over 10,000, 000 rows, the biggest one is 70, 000, 000 rows.
For each table, there are several indexes, almost all columns are varchar2. In
my experiences, with many indexes on large table, data insertion will be a pain.
In my case, I have 30, 000 rows to be inserted
"Niclas Gustafsson" <[EMAIL PROTECTED]> writes:
> Well I changed LC_ALL to LATIN1 and run initdb, dumped back all the
> data, but the sorting order seem to wrong still, allthough different,
> pg_controldata shows:
> LC_COLLATE: C
> LC_CTYPE:
I had a view set up and then went and had to change one of the tables that
was referenced in the view. I needed to drop one of the field in this particular
table so I created a temp table (without the field I wanted to eliminate) and
then moved the data in. I dropped the original table and th
I should also mention that the view no longer states its definition when \d
is used.
Thanks
Jodi Kanter
___Jodi
L KanterBioInformatics Database AdministratorUniversity of
Virginia(434) 924-2846[EMAIL PROTECTED]
got it workingI was trying to create and rename the view but apparently
that breaks some sort of link.
It worked when I completely removed the existing view and then recreated
with original name from scratch.
thanks anyway...
Jodi
- Original Message -
From:
Jodi
Kanter
21 matches
Mail list logo
