Adrian Klaver writes:
> On Thursday 17 December 2009 6:39:45 pm CG wrote:
>> CREATE INDEX packet_search_trigram_packet_uuid_idx
>> ON dpo.packet_search_trigram
>> USING hash
>> (packet_uuid);
> You might want to take a look at upgrading to 8.4.2 per this from the release
> notes:
Actually, what
On Thursday 17 December 2009 6:39:45 pm CG wrote:
> --- On Thu, 12/17/09, Adrian Klaver wrote:
> > Would it be possible to see the table schemas and indices
> > ?
>
> Sure (you asked for it!!) :
>
>
> CREATE TABLE dpo.packet_search_trigram
> (
> id integer NOT NULL DEFAULT
> nextval('packet_sea
--- On Thu, 12/17/09, Adrian Klaver wrote:
>
> Would it be possible to see the table schemas and indices
> ?
>
> >
Sure (you asked for it!!) :
CREATE TABLE packet
(
id integer NOT NULL DEFAULT nextval('packet_id_seq'::regclass),
packet_uuid uniqueidentifier NOT NULL DEFAULT newid(),
- "CG" wrote:
> --- On Tue, 12/15/09, Adrian Klaver wrote:
>
> > From: Adrian Klaver
> > Subject: Re: [GENERAL] pg_dump and ON DELETE CASCADE problem
> > To: cgg...@yahoo.com
> > Cc: "postgresql listserv" , "Craig
> Ringer&quo
--- On Tue, 12/15/09, Adrian Klaver wrote:
> From: Adrian Klaver
> Subject: Re: [GENERAL] pg_dump and ON DELETE CASCADE problem
> To: cgg...@yahoo.com
> Cc: "postgresql listserv" , "Craig Ringer"
> , "Scott Marlowe"
> Date: Tuesday, December 1
On Tuesday 15 December 2009 2:33:39 pm CG wrote:
>
> Bingo. Showed right up. I did a reindex, and now it shows up searching via
> sequential scan or index scan.
>
> So that's pretty scary to have a corrupted index. Once I reindexed, I'm
> able to see /a lot/ of data I couldn't before. This is the
--- On Fri, 12/11/09, Scott Marlowe wrote:
> From: Scott Marlowe
> Subject: Re: [GENERAL] pg_dump and ON DELETE CASCADE problem
> To: cgg...@yahoo.com
> Cc: pgsql-general@postgresql.org, "Adrian Klaver" ,
> "Craig Ringer"
> Date: Friday, December 11, 2
On Thu, Dec 10, 2009 at 1:21 PM, CG wrote:
>
> Thanks for the suggestion. I'm not sure what you mean when you say I should
> restore to a file. Do you mean I should dump the database to an SQL file
> instead of the "compressed" format?
>
> What do you think I will find?
>
> In the database dump,
On Friday 11 December 2009 5:59:31 am CG wrote:
> That's really nifty! I didn't know you could do that!
>
> So I expanded it, and I grepped for that UUID through the 46 gig file, and
> I found the row in the dump that shouldn't be there... It defies
> explanation.
>
Just so I am clear it always ex
rce
> Subject: Re: [GENERAL] pg_dump and ON DELETE CASCADE problem
> To: cgg...@yahoo.com, pgsql-general@postgresql.org
> Date: Thursday, December 10, 2009, 3:29 PM
> CG wrote:
> > Thanks for the suggestion. I'm not sure what you mean
> when you say I should restore to a file. Do
- "CG" wrote:
> Thanks for the suggestion. I'm not sure what you mean when you say I
> should restore to a file. Do you mean I should dump the database to an
> SQL file instead of the "compressed" format?
See Johns answer.
>
> What do you think I will find?
>
> In the database dump, it
CG wrote:
Thanks for the suggestion. I'm not sure what you mean when you say I should restore to a
file. Do you mean I should dump the database to an SQL file instead of the
"compressed" format?
he meant...
pg_restore -f outputfile.sql yourdumpfile
this will convert the dumpfile to SQ
Thanks for the suggestion. I'm not sure what you mean when you say I should
restore to a file. Do you mean I should dump the database to an SQL file
instead of the "compressed" format?
What do you think I will find?
In the database dump, it is including a row that should be marked as deleted.
On Thursday 10 December 2009 7:27:54 am CG wrote:
> The command's nothing out-of-the-ordinary:
>
> #!/bin/bash
>
> export LD_LIBRARY_PATH=/usr/local/pgsql/lib
>
> #
> # Set Variables
> ##
lem, but some sort of MVCC irregularity where
pg_dump is able to dump rows that it shouldn't. I bet a VACUUM FULL would clean
this up, but I have a live problem here. If I eradicate it, who knows when
we'll see it again...
--- On Wed, 12/9/09, Craig Ringer wrote:
From: Cr
On 10/12/2009 3:31 AM, CG wrote:
Hi all,
We're using PostgreSQL 8.4 ... We do our nightly database backups with
pg_dump. I was doing a test restore and I encountered some data during
the reload that was in a table against the conditions of a foreign key
constraint. I run my restores with the "-e"
Hi all,
We're using PostgreSQL 8.4 ... We do our nightly database backups with pg_dump.
I was doing a test restore and I encountered some data during the reload that
was in a table against the conditions of a foreign key constraint. I run my
restores with the "-e" option to halt on errors, so
17 matches
Mail list logo
