Re: [HACKERS] Large Objects versus transactional behavior

2011-05-12 Thread YAMAMOTO Takashi
hi, > On Sat, Apr 30, 2011 at 2:58 PM, Kevin Grittner > wrote: >> This is related to the "SIREAD lock versus ACCESS EXCLUSIVE lock" >> thread, but seemed different enough to merit spinning off a new >> thread. >> >> Our shop hasn't used large objects so far because of the lack of >> security (unt

Re: [HACKERS] Large Objects versus transactional behavior

2011-05-12 Thread Kevin Grittner
YAMAMOTO Takashi wrote: > is there any chance to "just" make large objects obey the normal > semantics in future? I sure hope so, but I have no idea how hard that is. I feel the same about TRUNCATE TABLE now that I recognize the semantic difference between it and DELETE FROM with no WHERE cla

Re: [HACKERS] Large Objects versus transactional behavior

2011-05-06 Thread Robert Haas
On Sat, Apr 30, 2011 at 2:58 PM, Kevin Grittner wrote: > This is related to the "SIREAD lock versus ACCESS EXCLUSIVE lock" > thread, but seemed different enough to merit spinning off a new > thread. > > Our shop hasn't used large objects so far because of the lack of > security (until 9.1), so I n

[HACKERS] Large Objects versus transactional behavior

2011-04-30 Thread Kevin Grittner
This is related to the "SIREAD lock versus ACCESS EXCLUSIVE lock" thread, but seemed different enough to merit spinning off a new thread. Our shop hasn't used large objects so far because of the lack of security (until 9.1), so I never noticed the rather unusual transactional semantics of large o

Re: [HACKERS] Large objects.

2010-09-27 Thread Robert Haas
On Mon, Sep 27, 2010 at 2:25 PM, Dmitriy Igrishin wrote: > Hey Robert, Tom > > Tom, thank you for explanation! > >> Ouch.  Letting people write data to where they can't get it back from >> seems double-plus ungood. >> > Robert, yes, I agree with you. This is exactly what I wanted to say. > I've im

Re: [HACKERS] Large objects.

2010-09-27 Thread Dmitriy Igrishin
Hey Robert, Tom Tom, thank you for explanation! Ouch. Letting people write data to where they can't get it back from > seems double-plus ungood. > > Robert, yes, I agree with you. This is exactly what I wanted to say. I've implemented a stream class in C++ and this circumstance makes the code no

Re: [HACKERS] Large objects.

2010-09-27 Thread Robert Haas
On Mon, Sep 27, 2010 at 10:50 AM, Tom Lane wrote: > Robert Haas writes: >> According to the documentation, the maximum size of a large object is >> 2 GB, which may be the reason for this behavior. > > In principle, since pg_largeobject stores an integer pageno, we could > support large objects of

Re: [HACKERS] Large objects.

2010-09-27 Thread Tom Lane
Robert Haas writes: > According to the documentation, the maximum size of a large object is > 2 GB, which may be the reason for this behavior. In principle, since pg_largeobject stores an integer pageno, we could support large objects of up to LOBLKSIZE * 2^31 bytes = 4TB without any incompatible

Re: [HACKERS] Large objects.

2010-09-27 Thread Robert Haas
On Sun, Sep 26, 2010 at 12:21 PM, Dmitriy Igrishin wrote: > Yes, I am sure. I've tested it by test case in my original post. > Do you can compile and reproduce it please? I think the reason lo_read is returning 0 is because it's not reading anything. See attached test case, cleaned up a bit from

Re: [HACKERS] Large objects.

2010-09-26 Thread Dmitriy Igrishin
Hey Robert, Yes, I am sure. I've tested it by test case in my original post. Do you can compile and reproduce it please? -- // Dmitriy.

Re: [HACKERS] Large objects.

2010-09-26 Thread Robert Haas
On Fri, Sep 24, 2010 at 9:13 AM, Dmitriy Igrishin wrote: > Tell me please, why lo_write() returns me the number of bytes "actually > written" > when current write location is out of 2GB ? IMO, in this case it should > returns > at least zero. > lo_read() returns zero in this case, and it is correc

[HACKERS] Large objects.

2010-09-24 Thread Dmitriy Igrishin
Hey all, Here is simple test case of LOB usage, please, note the comments: #include #include int main(int argc, char* argv[]) { PGconn* c = PQconnectdb("password=test"); PGresult* r = PQexec(c, "BEGIN"); PQclear(r); const unsigned int id = lo_create(c, 0); int fd1 = lo_open(c, id,

Re: [HACKERS] Large objects through ODBS

2004-11-30 Thread Joshua D. Drake
Bojidar Mihajlov wrote: Hi all! I need to operate with large objects through ODBC in C/C++ program. How can I do that? Look at the contrib lo data type. Sincerely, Joshua D. Drake __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.

[HACKERS] Large objects through ODBS

2004-11-30 Thread Bojidar Mihajlov
Hi all! I need to operate with large objects through ODBC in C/C++ program. How can I do that? __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com ---(end of broadcast)---

Re: [GENERAL] [HACKERS] large objects

2003-06-22 Thread Bruce Momjian
Add to TODO: * Allow SSL-enabled clients to turn off SSL transfers --- Tom Lane wrote: > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > > Ok, I tried to try this but I can not get SSL to _not_ be used when > > co

Re: [GENERAL] [HACKERS] large objects

2003-06-09 Thread Tom Lane
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > Ok, I tried to try this but I can not get SSL to _not_ be used when > connecting via any tcp connection, unless the client hasn't been built > with ssl support of course. Yeah, I believe that's the way it works. It seems overly fascist of the SSL c

Re: [HACKERS] large objects

2003-06-08 Thread Nigel J. Andrews
Note, primary list address changed to -general, I'd suggest any followups remove the -hackers, which I've left in just for 'closure'. On Fri, 6 Jun 2003, Nigel J. Andrews wrote: > On Fri, 6 Jun 2003, Tom Lane wrote: > > > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > > > Now, I did a little

Re: [HACKERS] large objects

2003-06-08 Thread Nigel J. Andrews
Repost just to add the information that this is [now] on 7.3.3, previously on 7.3.2. Sorry for the noise of the incomplete previous message, although the email lists seem to be very light this last week. Obviously the mail server is still feeling under the weather, I presume many posts have been

Re: [HACKERS] large objects

2003-06-08 Thread Tom Lane
"Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > Now, I did a little bit of testing and when doing a \lo_export > in psql connected via localhost a SIGPIPE is generated in > write() in libc and psql quit, without printing any message to the > terminal. Perhaps interestingly > the file that gets

Re: [HACKERS] large objects

2003-06-08 Thread Nigel J. Andrews
On Fri, 6 Jun 2003, Tom Lane wrote: > "Nigel J. Andrews" <[EMAIL PROTECTED]> writes: > > Now, I did a little bit of testing and when doing a \lo_export > > in psql connected via localhost a SIGPIPE is generated in > > write() in libc and psql quit, without printing any message to the > > termina

[HACKERS] large objects

2003-06-06 Thread Nigel J. Andrews
I realise large objects are liked anymore and that the wire protocol is changing in 7.4 but I've just posted this message into the PHP documentation: -- begin Using php 4.3.0 and PostgreSQL 7.3.1 I can write a simple script in which pg_lo_write seems to always return 1 and not the number of by

Re: [HACKERS] Large objects and ecpg

2001-09-19 Thread Michael Meskes
On Wed, Sep 19, 2001 at 12:46:03AM +0530, Chamanya wrote: > Can I use ecpg with large objects? All examples in documentation are for > libpq. Yes and no. Since ECPG uses libpq it should not be too difficult to use the lo functions too. But there is no way to use them via some EXEC SQL statements

[HACKERS] Large objects and ecpg

2001-09-18 Thread Chamanya
Hi all, Can I use ecpg with large objects? All examples in documentation are for libpq. Thanks Shridhar _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)-

[HACKERS] Large objects and table deletion.

2001-07-22 Thread Grant
When I delete a table that has an OID, the OID does not get deleted correct? How can I delete the data from the large object? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEm

Re: [HACKERS] large objects dump

2001-06-05 Thread Denis Perchine
Hi, > I had PostgreSQL 7.0.3 (7.1 now) and one nice day I've noticed that much > number of my BLOBs are broken! Although they seems to be with good content > in file system (xinv[0-9]+ files) I was not able to get them via > lo_export... After spending some time trying to fix it, I decided to wri

[HACKERS] large objects dump

2001-06-05 Thread Maks N. Polunin
Hello, All! I had PostgreSQL 7.0.3 (7.1 now) and one nice day I've noticed that much number of my BLOBs are broken! Although they seems to be with good content in file system (xinv[0-9]+ files) I was not able to get them via lo_export... After spending some time trying to fix it, I decided to wri