On Mon, Mar 07, 2005 at 09:04:04PM +0530, Gourish Singbal wrote:
> Hi,
>
> Can anybody provided me the procedure to take online backups in 8.0.1.
> Simple steps would be really great..
>
> --
> Best,
> Gourish Singbal
>
> ---(end of broadcast)---
Mondrian just went 1.0 and support PostgreSQL. Never tried it, though.
http://perforce.eigenbase.org:8080/open/mondrian/doc/index.html
On Wed, Sep 22, 2004 at 09:21:54AM -0500, Ben Kim wrote:
>
> Dear list,
>
> I wonder if I could get recommendations/reviews/experience for analytics
> tools tha
On Wed, Aug 18, 2004 at 04:09:33PM +0200, [EMAIL PROTECTED] wrote:
> How do you share the data-definitions of your project(s) when they
> change (template1) ? Do you create all system-tables at pg_init
> runtime, and thus diff the C-source?
We track all DDL in CVS and manually create "patches" t
On Wed, Jul 07, 2004 at 04:28:53PM +0100, Hilary Forbes wrote: >
> ... when I run pg_dump to restore the data, one table with approx
> 5.5 million records gives me
>
> ERROR: invalid memory alloc request size 1073741824
What do you mean "pg_dump to restore the data"? One would normally use
psql
The names of the participants have been changed to protect the innocent.
I'm trying to recover some lost data from this weekend. Apparently, we were able to
INSERT into critical_table without error, but not able to SELECT, COPY, or VACUUM
critical_table. I saved a copy of the PGDATA directory a
On Tue, Jan 13, 2004 at 11:36:19PM -0500, Tom Lane wrote:
> Michael Adler <[EMAIL PROTECTED]> writes:
> > On many occasions, I've noticed that some PostgreSQL activity takes
> > far longer than it previously did and that disabling syslogd addresses
> > the sym
On many occasions, I've noticed that some PostgreSQL activity takes far longer than it
previously did and that disabling syslogd addresses the symptoms.
Most recently, it took 20-60 seconds to VACUUM a small, heavily updated table, while
it used to take a fraction of a second. I found syslog e
