Hi
Here is the error:
2010-04-08 17:30:41 ISTLOG: could not receive test message on socket for
statistics collector: Connection refused
2010-04-08 17:30:41 ISTLOG: disabling statistics collector for lack of
working socket
Regards
Senthil
-Original Message-
From: Kevin Grittner [mailto
On Sun, Jun 20, 2010 at 10:36 AM, Elior Soliman
wrote:
> Hello,
>
> My company looking for some solution for High availability with Postgres.
>
> Our optional solution is as follows :
> Two DB servers will be using a common external storage (with raid). Both
> servers are going to use the same DB
> average about two drive failures a monthYou must be having a real huge
> postgres setup with several hundreds of drives to have such high frequency of
> failure.
> As a place to put "one more> copy" it might make sense, as long as it had
> strong encryption.I didn't expand but that's what I
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Tuesday, June 22, 2010 2:41 PM
> To: Igor Neyman
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> "Igor Neyman" writes:
> > Attached is script that could be used to pre-cr
"Igor Neyman" writes:
> Attached is script that could be used to pre-create "parent" tables
> (from which partitions were inherited).
Thanks. Now that I dig into it, it looks like the actual trigger for
the problem is that pg_dump, not pg_restore, couldn't seek while it
was creating the dump fil
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Tuesday, June 22, 2010 1:10 PM
> To: Igor Neyman
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> "Igor Neyman" writes:
> > Attached are couple smallish files (I suspect,
wrote:
> I built a database on postgres8.1, then I did VACUUM FULL ANALYZE,
> but the query is still slow.
> Has anybody an idea ?
I recommend you re-post to the pgsql-performance list, after reading
this:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
The one thing I can say based on
Hi,
I built a database on postgres8.1, then I did VACUUM FULL ANALYZE, but the
query is still slow.
Has anybody an idea ?
Thanks
Dong
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
"Senthil Kumar G" wrote:
> I set it up the postgres db and wanted to enable the statistics
> collector in one of our customer server. Some how, it is not
> running. Please see the error below.
I am not able to view that. (I assume you embedded some image
format my OS doesn't understand.) Cou
"Igor Neyman" writes:
> Attached are couple smallish files (I suspect, CM_200909.bac might have
> just empty tables, no data - but it still produces an errror).
Hmm. I get
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 2741; 1259 30866 T
Uwe Bartels writes:
> i'm pretty sure there is no repetitive ddl happen on this or any other
> table. i checked this with the developers.
Well, *something* was blocking that RowExclusiveLock request, and for
sure it wasn't autovacuum. There has to be something else going on.
> but if i had an a
Cassiano, Marco wrote:
> Hi all,
>
>
>
> it's my first trial with pg_upgrade so I'm surely missing something
>
> I'm trying to launch pg_upgrade passing my super user name but
> pg_dumpall fails with a permission denied error
>
> I don't see the username in the pgdumpall callcould
> -Original Message-
> From: Kevin Grittner [mailto:kevin.gritt...@wicourts.gov]
> Sent: Tuesday, June 22, 2010 12:40 PM
> To: Igor Neyman; John Rouillard; Glyn Astill
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> Glyn Astill wrote:
>
> >
Glyn Astill wrote:
> so far I can only get the same error with large dump files.
"Large" being a relative term --
ever see it on a file smaller than 2GB?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
> -Original Message-
> From: Glyn Astill [mailto:glynast...@yahoo.co.uk]
> Sent: Tuesday, June 22, 2010 12:36 PM
> To: John Rouillard; Igor Neyman
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> --- On Tue, 22/6/10, Igor Neyman wrote:
>
> > From
--- On Tue, 22/6/10, Igor Neyman wrote:
> From: Igor Neyman
> Subject: Re: [ADMIN] parallel option in pg_restore
> To: "John Rouillard"
> Cc: pgsql-admin@postgresql.org
> Date: Tuesday, 22 June, 2010, 17:34
>
> No piping, just regular restore from the backup file.
>
Same here. If only I co
> -Original Message-
> From: John Rouillard [mailto:rou...@renesys.com]
> Sent: Tuesday, June 22, 2010 11:52 AM
> To: Igor Neyman
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> On Tue, Jun 22, 2010 at 11:05:02AM -0400, Igor Neyman wrote:
> > >
Hi Tom,
hmm. thanks for your answer.
i'm pretty sure there is no repetitive ddl happen on this or any other
table. i checked this with the developers.
but if i had an anti-wraparound vacuum, then i should see warnings like
these in the log. am i right? I don't have any warnings that day.
WARNING
On Tue, Jun 22, 2010 at 11:05:02AM -0400, Igor Neyman wrote:
> > "Igor Neyman" writes:
> > > I'm testing 8.4.4 (on Windows) before upgrading our app to this PG
> > > version.
> > > When running pg_restore with "-j 2" parallel option, I'm getting the
> > > following error:
> > > "pg_restore: [cu
"Igor Neyman" writes:
> Is that the information you asked for, or you want a sample of small
> backup file attached?
> I'm attaching pg_restore log file, if it's of any help.
If you can make a small archive file that provokes the problem, yes
please send it. Also, please show the exact pg_restor
> From: Igor Neyman
> Subject: Re: [ADMIN] parallel option in pg_restore
> To: "Tom Lane"
> Cc: pgsql-admin@postgresql.org
> Date: Tuesday, 22 June, 2010, 16:05
> > -Original Message-
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>
> > Sent: Tuesday, June 22, 2010 10:37 AM
> > To: Igor
Hi
I set it up the postgres db and wanted to enable the statistics collector in
one of our customer server. Some how, it is not running. Please see the
error below.
Can you let me know what could be the issue?
1. Error during server startup
2. On executing ps -ef |g
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Tuesday, June 22, 2010 10:37 AM
> To: Igor Neyman
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] parallel option in pg_restore
>
> "Igor Neyman" writes:
> > I'm testing 8.4.4 (on Windows) before upgrading
"Cassiano, Marco" wrote:
> Thank you (I hope this is the right list to post this)
Since you're basically reporting a failure of the beta test release
to perform as you expect, your best bet might have been to proceed
as outlined here:
http://wiki.postgresql.org/wiki/HowToBetaTest
That said
"Campbell, Lance" wrote:
> I want to add a timestamp column to some of my important table
> such that whenever an SQL "update" command is executed on the
> table the "updated_timestamp" timestamp column would be set with
> "now()".
I would write one function which I would bind as a BEFORE UPDA
PostgreSQL 8.4
I want to add a timestamp column to some of my important table such that
whenever an SQL "update" command is executed on the table the
"updated_timestamp" timestamp column would be set with "now()". Is
there a way to do this? I know I could go through and change my SQL all
over th
Uwe Bartels writes:
> last ween i've seen a blocking "automatic vacuum".
> as i understood, this is not supposed to happen. in the past i saw vacuum
> processes disappear, in case of the need of a lock.
What that sounds like is it was an anti-wraparound vacuum. Autovacuum
won't cancel those to a
Balkrishna Sharma wrote:
> If the database is not extremely huge, makes you wonder what does
> a RAID actually give us.
Well, RAID5 gives you a situations where you must have a second
drive fail before recovery for the first failure is complete, versus
being instantly dead on a single-drive fa
"Igor Neyman" writes:
> I'm testing 8.4.4 (on Windows) before upgrading our app to this PG
> version.
> When running pg_restore with "-j 2" parallel option, I'm getting the
> following error:
> "pg_restore: [custom archiver] dumping a specific TOC data block out of
> order is not supported without
# select version();
version
--
PostgreSQL 8.4.3 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC)
4.1.2 20071124 (Red Hat 4.1.2-42), 64-bit
(1 row)
On 22 June 2010 15:53, Kevin G
"Igor Neyman" wrote:
> I'm testing 8.4.4
> pg_restore with "-j 2" parallel option
> using pg_dump version 8.2.5.
> Is this error results from version differences between pg_dump and
> pg_restore?
Yeah, probably.
I suspect that you have the choice of dumping with the newer
pg_dump, or n
Uwe Bartels wrote:
> last ween i've seen a blocking "automatic vacuum".
What does SELECT version(); show?
-Kevin
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Hi,
last ween i've seen a blocking "automatic vacuum".
as i understood, this is not supposed to happen. in the past i saw vacuum
processes disappear, in case of the need of a lock.
this is the relvant extract from the log and the database:
2010-06-18 18:33:36.011 CEST172.19.5.34(57414)
I'm testing 8.4.4 (on Windows) before upgrading our app to this PG
version.
When running pg_restore with "-j 2" parallel option, I'm getting the
following error:
"pg_restore: [custom archiver] dumping a specific TOC data block out of
order is not supported without ID on this input stream (fseek
Hi all,
it's my very first trial with pg_upgrade so I'm surely missing
something
I'm trying to launch pg_upgrade passing my super user name but
pg_dumpall fails with a permission denied error
I don't see the username in the pgdumpall callcould it be this the
problem ?
Thank you (
35 matches
Mail list logo
