Re: Bug in pg_dump/restore -o

I think I see the cause.  I created a simple table and then generated
the dump.  I found this that the normal table had its COPY data in
binary format while the max oid dump was pure ASCII.  My guess is that
the max oid dump code isn't calling the right routine to dump its data.

---------------------------------------------------------------------------

Brent Verner wrote:
> [2002-01-17 12:49] Bruce Momjian said:
> 
> | It seems the -Fc format is somehow misinterpreting this.  I am
> | researching this now but if someone has a clue, I could use it.
> 
> Breakpoint 1, ExecuteSqlCommandBuf (AH=0x8056758, qryv=0x80614d0, bufLen=121)
>     at pg_backup_db.c:653
> 653     for (pos = 0; pos < (eos - qry); pos++)
> (gdb) next
> 655       appendPQExpBufferChar(AH->sqlBuf, qry[pos]);
> (gdb) 
> 658       switch (AH->sqlparse.state)
> (gdb) print *AH->sqlBuf
> $9 = {
>   data = 0x8056a10 "--\n-- Selected TOC Entries:\n--\n--\n-- TOC Entry ID 2 (OID 0)\n--\n-- Name: Max OID Type:
<Init>Owner: \n-- Data Pos: 0 (Length 0)\n--\n\nC", len = 132, maxlen = 256}
 
> (gdb) cont
> Continuing.
> pg_restore: [archiver (db)] could not execute query: no result from server
> pg_restore: *** aborted because of error
> 
> Notice the 'C' at the end of the AH->sqlBuf->data.  Looks like a
> bad count somewhere.  I won't have time to dig any more til after
> work to(day|nignt).
> 
> hth.
>   brent
> 
> -- 
> "Develop your talent, man, and leave the world something. Records are 
> really gifts from people. To think that an artist would love you enough
> to share his music with anyone is a beautiful thing."  -- Duane Allman
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026