pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedlarge object error
4+ messages / 4 participants
[nested] [flat]
* large object error
@ 1998-10-26 01:00 Peter Garner <peter.garner@toward.com>
1998-10-26 06:54 ` Re: [INTERFACES] large object error Peter T Mount <peter@retep.org.uk>
1998-10-26 16:16 ` Re: [INTERFACES] large object error Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 4+ messages in thread
From: Peter Garner @ 1998-10-26 01:00 UTC (permalink / raw)
To: pgsql-interfaces; +Cc: peter.garner@toward.com
Hi All! :-)
Thanks for your help! :-) I am attempting to write an app
that uses large objects. It is an offline Usenet NNTP news
reader that stores all of the message information in a
postgres database. I am using the LOBS to hold the
message body. Thus one of the tables is declared as
create table Msg_Bodies
(
Msg_Id text not null ,
Msg_Body OID not null ,
primary key ( Msg_Id )
) ;
I am getting a wierd error attempting to access the lobs.
When I close the lob, I get the error
PQfn: expected a 'V' from the backend. Got 'N' instead
From this point on, all further attempts to access LOBs
generate this error.
The lobs are already created, and were stored in the table
without error. This error occurs later when I try to read
the lob. I have written some simple function wrappers to
the postgres lob functions that do some logging and the
sequence of events is :
Entering int lobOpen ( Oid oid , int nMode )
Oid is 145147 mode is 262144
In lobOpen ( Oid oid , int nMode ), l_open returned 0
Leaving int lobOpen ( Oid oid , int nMode )
Entering lobRead ( char * caBuff , int nLen )
Length is 1048575, FD is 0
Leaving lobRead ( char * caBuff , int nLen ), returning 1151
Entering lobClose () , FD is 0
PQfn: expected a 'V' from the backend. Got 'N' instead
As you can see the lob is opened and read OK, and the data
returned by the read is correct. But closing kills
everything. Does anyone know that this error means?
The contents of the trace file (PQtrace (PQconn * , FILE *)
is :
To backend> Qselect proname, oid from pg_proc where proname = 'lo_open' or proname = 'lo_close' or proname = 'lo_creat' or proname = 'lo_unlink' or proname = 'lo_lseek' or proname = 'lo_tell' or proname = 'loread' or proname = 'lowrite'
From backend> P
From backend> "blank"
From backend> T
From backend (#2)> 2
From backend> "proname"
From backend (#4)> 19
From backend (#2)> 32
From backend> "oid"
From backend (#4)> 26
From backend (#2)> 4
From backend> D
From backend (1)> À
From backend (#4)> 11
From backend (7)> lo_open
From backend (#4)> 7
From backend (3)> 952
From backend (1)> À
From backend (#4)> 12
From backend (8)> lo_close
From backend (#4)> 7
From backend (3)> 953
From backend (1)> À
From backend (#4)> 10
From backend (6)> loread
From backend (#4)> 7
From backend (3)> 954
From backend (1)> À
From backend (#4)> 11
From backend (7)> lowrite
From backend (#4)> 7
From backend (3)> 955
From backend (1)> À
From backend (#4)> 12
From backend (8)> lo_lseek
From backend (#4)> 7
From backend (3)> 956
From backend (1)> À
From backend (#4)> 12
From backend (8)> lo_creat
From backend (#4)> 7
From backend (3)> 957
From backend (1)> À
From backend (#4)> 11
From backend (7)> lo_tell
From backend (#4)> 7
From backend (3)> 958
From backend (1)> À
From backend (#4)> 13
From backend (9)> lo_unlink
From backend (#4)> 7
From backend (3)> 964
From backend> "SELECT"
To backend> F
To backend (4#)> 952
To backend (4#)> 2
To backend (4#)> 4
To backend (4#)> 145147
To backend (4#)> 4
To backend (4#)> 262144
From backend> V
From backend> G
From backend (#4)> 4
From backend (#4)> 0
From backend> 0
To backend> F
To backend (4#)> 956
To backend (4#)> 3
To backend (4#)> 4
To backend (4#)> 0
To backend (4#)> 4
To backend (4#)> 0
To backend (4#)> 4
To backend (4#)> 0
From backend> V
From backend> G
From backend (#4)> 4
From backend (#4)> 0
From backend> 0
To backend> F
To backend (4#)> 954
To backend (4#)> 2
To backend (4#)> 4
To backend (4#)> 0
To backend (4#)> 4
To backend (4#)> 1048575
From backend> V
From backend> G
From backend (#4)> 1151
From backend (1151)>
Hi there, I got a new video card (matrox millenium) and would like to know
how to switch X-servers before I plug it in. I'm using the XFree86 3.3.2
rpms from the RH 4.2 updates. /usr/X11/bin/X is a link to a binary called
Xwrapper and then I also have XFree86_S3 and XFree_SVGA in that directory.
At the moment it uses the S3 server which works fine with my old card. How
will I be able to switch it to the SVGAserver needed for the new card ???
Does anyone know what that Xwrapper does or whether I can simply bypass it
and make X a link to the SVGA server ?? Thanks,
GErald
\\\|///
| ~ ~ |
(- 0 0 -)
------------------oOOo-(_)-oOOo------------------
Gerald Willmann Department of Economics
96F Escondido Vlg. Stanford University
Stanford, CA 94305 CA 94305-6072, USA
+1(650)497-0902 oooO 725-8921 / 5702 (fax)
------------------( )-----Oooo------------------
\ ( ( )
\_) ) /
(_/
From backend> 0
To backend> F
To backend (4#)> 953
To backend (4#)> 1
To backend (4#)> 4
To backend (4#)> 0
From backend> N
Thanks all! :-)
Peter
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] large object error
1998-10-26 01:00 large object error Peter Garner <peter.garner@toward.com>
@ 1998-10-26 06:54 ` Peter T Mount <peter@retep.org.uk>
1 sibling, 0 replies; 4+ messages in thread
From: Peter T Mount @ 1998-10-26 06:54 UTC (permalink / raw)
To: Peter Garner <peter.garner@toward.com>; +Cc: pgsql-interfaces
On Mon, 26 Oct 1998, Peter Garner wrote:
> Hi All! :-)
>
> Thanks for your help! :-) I am attempting to write an app
> that uses large objects. It is an offline Usenet NNTP news
> reader that stores all of the message information in a
> postgres database. I am using the LOBS to hold the
> message body. Thus one of the tables is declared as
>
> create table Msg_Bodies
> (
> Msg_Id text not null ,
> Msg_Body OID not null ,
>
> primary key ( Msg_Id )
>
> ) ;
>
>
> I am getting a wierd error attempting to access the lobs.
> When I close the lob, I get the error
>
> PQfn: expected a 'V' from the backend. Got 'N' instead
What interface are you using?
When I was implementing large object for JDBC, I came across this. If
you're using libpq, I may know where the problem is.
>
--
Peter T Mount peter@retep.org.uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] large object error
1998-10-26 01:00 large object error Peter Garner <peter.garner@toward.com>
@ 1998-10-26 16:16 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 4+ messages in thread
From: Tom Lane @ 1998-10-26 16:16 UTC (permalink / raw)
To: peter.garner@toward.com; +Cc: pgsql-interfaces
"Peter Garner" <peter.garner@toward.com> writes:
> I am getting a wierd error attempting to access the lobs.
> When I close the lob, I get the error
> PQfn: expected a 'V' from the backend. Got 'N' instead
This is a bug in libpq 6.3.2 (and probably all prior releases).
It doesn't cope with "NOTICE" messages issued by the backend during
a fast-path function call, which is what all the lo_XXX routines are.
It's impossible to guess from this much info what the NOTICE is and
whether it's anything significant; very possibly it's ignorable.
The backend is willing to proceed with the transaction, anyway.
This bug is fixed in the current sources. Although 6.4 is officially
still beta, I'd really suggest using a current snapshot in place of
6.3.2 --- I believe the current sources are more stable than 6.3.2.
(My company is currently running production apps on a server built
from a late-September snapshot, and it's given us no trouble ...
whereas 6.3.2 had some nasty bugs that got tickled by our apps.)
Alternatively, I think that a small patch to the 6.3.2 sources to handle
NOTICE messages during PQfn() was posted to one or another of the pgsql
mailing lists sometime this summer (not by me). Check the archives.
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [INTERFACES] large object error
@ 1998-10-26 12:41 Cary B. O'Brien <cobrien@access.digex.net>
0 siblings, 0 replies; 4+ messages in thread
From: Cary B. O'Brien @ 1998-10-26 12:41 UTC (permalink / raw)
To: pgsql-interfaces
Peter wrote...
> Hi All! :-)
>
> Thanks for your help! :-) I am attempting to write an app
> that uses large objects. It is an offline Usenet NNTP news
> reader that stores all of the message information in a
> postgres database. I am using the LOBS to hold the
You might want to investigate the disk space usage of large objects
and postgresql. My quick investigation indicated that each large
object took up at least one 16k file. In addition, all the files were
in the same directory.
The downside is wasted disk space for articles and (if you end up with
lots and lots of articles in the same database) slow directory
look-ups.
You may want to store the articles in plain disk files, with a hashed
directory structure. You could use a sequence or the oid as a
key. I.E. article 12345678 goes in file 12/34/56/78. I have done this
before with other databases. It also lets you spread things out
over multiple file systems.
Note:
1) This was the result of about an hour's worth of testing.
2) It might not be applicable in your situation. For example,
BLOBS might still be a very good idea if your clients are
coming in over TCP/IP and don't have file system access.
3) It ought to work.
Comments?
[big snip]
--- cary
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~1998-10-26 16:16 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-10-26 01:00 large object error Peter Garner <peter.garner@toward.com>
1998-10-26 06:54 ` Peter T Mount <peter@retep.org.uk>
1998-10-26 16:16 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-10-26 12:41 Re: [INTERFACES] large object error Cary B. O'Brien <cobrien@access.digex.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox