[GENERAL] Question about Linux, threads, and Postgres

1999-01-31 Thread Felix Morley Finch

I've been running various versions of Postgres for several years now,
including one prototype web site for a customer.  I currently run
6.3.2 at home, and will upgrade to 6.4.2, but I have some questions.

I am programming on Linux 2.0, libc6, in C.

I am writing a server application to sit between the database and
clients.  I would like to thread it.  This is strictly a home
education application, so I don't mind experimenting.  I have written
some small threaded apps before, but nothing fancy.  In particular, I
have never used any "third party" libraries; it has all been my code
and general libc stuff.

The Linux thread documentation mentions problems using X libraries
which have been compiled without threading support, either designed-in
or even using the compile time flag _REENTRANT.  As long as only one
thread calls all non-threaded functions, errno itself is safe, because
all the threaded code uses a per-thread value, leaving the global
errno to the unthreaded code.  I would not be surprised to find there
are other global variables also abused this way :-)

Q 1: Does anyone have experience with Postgres in a threaded program?

Q 2: Is it necessary and/or sufficient to have only one thread talk to
 the Postgres library?

Q 3: Would it be good / bad to compile 6.4.2 with -D_REENTRANT, and
 would this help with Q#2?

I searched the archives, but variations on "thread" found nothing but
references to threaded mailing list archives :-)

I also saw the news about 6.5 going from table locks to no locks.
This sounds pretty exciting!  I think it will be fun to write some
test programs for that, leave my box thrashing on it for a while when
I go to work :-)  But I have to find the usual spare time first :-(

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  PGP = 91 B3 94 7C E9 E8 76 2D   E1 63 51 AA A0 48 89 2F  ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o



Re: [GENERAL] Re: Displaying Image BLOBs

1999-01-31 Thread Herouth Maoz

At 18:01 +0200 on 26/01/1999, Fabrice Scemama wrote:


 Keeping information about sizes of images might be embarrassing,
 though I think there's on CPAN Perl modules to learn from an image
 it's size, jpeg or gif alike (not sure).

 But people might prefer using only the WIDTH *or* the HEIGHT
 parameter; Netscape and Explorer will then keep the image ratio
 when displaying the image.

I guess we're drifting off-topic, but for those who write this sort of
program for embedding images in HTML pages, it's important to know:

If you explicitly state the full size (width and height) in the IMG tag,
your browser will be able to allocate the needed screen space even before
the image loads. Therefore, if all the images in your page are tagged with
their sizes, the browser is able to display the page's text before loading
the images.

This causes the users to have an early feedback - they see that "something
is coming through", thus takes some frustration away and gives an illusion
of speed. If you don't do things this way, the text will not show until the
last of the unsized images have loaded.

In a similar vain, avoid using a large tables that contain the rest of your
page's contents. Netscape waits for the /TABLE before it displays the
page, which means none of the contents will show until the page is fully
loaded. It's better to decompose things into smaller tables and just align
them. This advice is useful for those who want to display database results
on an HTML page.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma





Re: [GENERAL] viewing/editing function definitions

1999-01-31 Thread Herouth Maoz

At 12:38 +0200 on 28/01/1999, Danny Rice wrote:


 With pgaccess I can "Open" a user defined function and see how it was
 defined.  Is there a way to do this with psql or some other interface
 (preferably text based)?  What is the best way to edit an existing
 function?

The only way I can think of is to dump the specific function using pg_dump
with appropriate flags. This enables you to see it.

Editing would be editing the resulting file, dropping the function and
running the file through psql. However, there is a catch here - last time I
tried this was on 6.2.1 - and this is that if you have a table that relies
on this function for default or constraint, I think you'll run into a
problem. This is probably because the new function definition has a
different OID.

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma





[GENERAL] Missing features ?

1999-01-31 Thread Joerg Huettmann

Hi!

I'm looking for a kind of history or archive-feature in Postgresql like in the
older postgres versions.
There it was possible by using Tmin and Tmax to recover old states of a
database.
Unfortunatly I didn't find something about database backup and recovery with
postgresql in the manual.

Can anybody help me with this problem?

Thanks...Joerg



[GENERAL] A forward-compatible pg_dump?

1999-01-31 Thread Herouth Maoz

After *months* of delays, we are *finally* going to port all our databases
(and that's hundreds of small ones) to 6.4.2 from 6.2.1.

So, I took a test-case database and tried to load it from our backup dumps.
Ah... Close, but no cigar. Several syntax changes happened over the past
two years, including the dropping of archiving (obsoleting the "archive"
keyword in the dumps), and a change in the constraint syntax.

Also, old pg_dump doesn't dump privileges correctly, and frankly, it would
be a pain to enter each database and start granting from memory or a
handwritten list...

So, I recalled that there was somebody who wrote a forward-compatible
pg_dump. Something that works on 6.2.1 (or was it 6.1?) but outputs 6.4 or
6.3 schema syntax. Is that someone still around?

If so, can this thingy, wherever I may get it, be used to dump properly
from 6.2.1 to 6.4.2, and will it dump grants as well?

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma





Re: [GENERAL] Question about Linux, threads, and Postgres

1999-01-31 Thread Adam Haberlach

On Sat, Jan 30, 1999 at 09:08:14PM -0800, Felix Morley Finch wrote:

 Q 1: Does anyone have experience with Postgres in a threaded program?

I have done a bit of this under BeOS (where each window gets
its own event loop and thread).  My first program turned out to have
problems in my initial port of the libraries, and in the process
of finding that out I ended up making the app rely on using a single
PgDatabase object protected by a home-brewed locking class.
In my recent apps I have just been instantiating the PgDatabase
objects wherever needed.  I have not noticed any problems, but I have
also not done much real testing.

 Q 2: Is it necessary and/or sufficient to have only one thread talk to
  the Postgres library?

Well, it would be sufficient--I am not sure if it is necessary.
When I get around to cleaning up my hackish port of the client libs
to BeOS, I will keep an eye out for things that could cause problems.




Re: [GENERAL] A forward-compatible pg_dump?

1999-01-31 Thread Oliver Elphick

Herouth Maoz wrote:
  After *months* of delays, we are *finally* going to port all our databases
  (and that's hundreds of small ones) to 6.4.2 from 6.2.1.
  ...
  So, I recalled that there was somebody who wrote a forward-compatible
  pg_dump. Something that works on 6.2.1 (or was it 6.1?) but outputs 6.4 or
  6.3 schema syntax. Is that someone still around?
 
My version was from 6.3.2 - 6.4.  I have sent a copy to Herouth for
further hacking...

Would it be a good idea to have an archive of enhanced pg_dump programs
for earlier releases?

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight  http://www.lfix.co.uk/oliver
   PGP key from public servers; key ID 32B8FAA1
 
 "Jesus saith unto him, I am the way, the truth, and the
  life; no man cometh unto the Father, but by me."  
John 14:6 





Re: [GENERAL] Question about Linux, threads, and Postgres

1999-01-31 Thread Felix Morley Finch

In article [EMAIL PROTECTED], Adam Haberlach 
[EMAIL PROTECTED] writes:

 On Sat, Jan 30, 1999 at 09:08:14PM -0800, Felix Morley Finch wrote:

 Q 2: Is it necessary and/or sufficient to have only one thread talk to
 the Postgres library?

   Well, it would be sufficient--I am not sure if it is necessary.
 When I get around to cleaning up my hackish port of the client libs
 to BeOS, I will keep an eye out for things that could cause problems.

Hm.  I wonder.  If libpq doesn't know about per-thread errno, but
uses the global one, and my code thinks the per-thread errno is set,
this might cause problems.  I wonder if there are any other libc
variables which also have per-thread and global versions.

-- 
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
 Felix Finch: scarecrow repairman  rocket surgeon / [EMAIL PROTECTED]
  PGP = 91 B3 94 7C E9 E8 76 2D   E1 63 51 AA A0 48 89 2F  ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o



[GENERAL] Postgres on BSDI-3.1

1999-01-31 Thread Sergei Chernev

Hello,

Does anybody know about supporting postgres on BSDI-3.1.
I know it works well on BSDI-4.0 platform, but i have no this version
yet.
Current version (v6.4) of postgres does not work with PL/pgSQL and 
server crashing when i work with it via ODBC on BSDI-3.1. 
Compiling and installing postgres was quite clear and easy.

Thank you,
---
Sergei Chernev
Internet: [EMAIL PROTECTED]
Phone: +7-3832-397354