Peter, I hope this long and boring message can shed some light on my
difficulties getting jdbc & postgres6.5b1(current snapshot) to work
with blobs.  I have NO problem with text, numeric, etc.  Just blobs &
the LO interface.

I feel that it is a 64 vs 32 bit memory management problem.

My system:

uname -a
SunOS vlad 5.7 Generic_106541-03 sun4u sparc SUNW,Ultra-5_10

postgreSQL:
[PostgreSQL 6.5.0 on sparc-sun-solaris2.7, compiled by cc ]

cc -V
cc: WorkShop Compilers 5.0 98/12/15 C 5.0

The database & tables:

mini_stores=> select * from item;
item_num|item_picture|item_descr
|ship_unit |unit_price|stock
--------+------------+--------------------------------------------------------------+----------+----------+-----

       1|       18602|Maximum protection for high-mileage
runners                   |pair      |$75.50    | 1000
       2|       18617|Customize your mountain bike with extra-durable
crankset      |each      |$20.00    |  500
       3|       18634|Long drive golf balls -fluorescent
yellow                     |pack of 12|$50.00    |  200
       4|       18652|Your first season's baseball
glove                            |pair      |$25.00    |  250
       5|       18668|Minimum chin contact, feather-light, maximum
protection helmet|each      |$35.50    |   50
(5 rows)


Now the java code that reads the item table and tries to display the
image & data.  This is "borrowed" from an example from informix &
their store7/mini_stores jdbc examples.
-----BEGIN---
/***************************************************************************

 *
 *  Title:          demo4.java
 *
 *  Description:    To use the fetch_buf_size connection parameter to
 *                  optimize the query and retrieve large byte data in
the
 *                  form of an image
 *
 *  An example of running the program:
 *
 *   java demo4 jdbc:postgresql:mini_stores <userid> <password>
 *
 ***************************************************************************

*/

import java.awt.*;
import java.awt.image.*;
import java.awt.event.*;
import java.sql.*;

public class demo4 extends Frame {
    static String connURL; // the URL to be used for establishing the
JDBC
 static String usr; // the user id to connect with.
 static String pwd; // the pasword of the user id.

    Connection conn;        // the database connection
    ResultSet queryResults; // the ResultSet containing the rows
returned by

    // The GUI controls
    Label itemNumLabel;
    TextField itemNumField;
    Label itemDescrLabel;
    TextArea itemDescrArea;
    Label shipUnitLabel;
    TextField shipUnitField;
    Label unitPriceLabel;
    TextField unitPriceField;
    Label stockLabel;
    TextField stockField;
    Label itemPictureLabel;
    ImgCanvas itemPictureCanvas;
    Button nextRowBtn;


    public static void main(String args[]) {
  if (args.length != 0) {
   connURL = args[0];
   usr = args[1];
   pwd = args[2];
   demo4 thisDemo = new demo4();
  } else {
   System.out.println("Missing input!! Please specify the connection
URL");
   System.out.println("Usage...java demo4 <jdbc_conn_url>");
  }
    }

    public demo4() {
  super();
  createControls();
  connectToDBServer();
  executeQuery();
    }

    private void createControls() {
  setLayout(null);
  setSize(700,500);
  setVisible(true);
  setTitle("Item Table Data");

  // Adding label & text-field for item_num column
  itemNumLabel = new Label("Item Num");
  itemNumLabel.setBounds(12,24,60,24);
  add(itemNumLabel);
  itemNumField = new TextField();
  itemNumField.setBounds(84,24,50,38);
  add(itemNumField);

  // Adding label and text-area for item_descr column
  itemDescrLabel = new Label("Item Description");
  itemDescrLabel.setBounds(12,72,96,24);
  add(itemDescrLabel);
  itemDescrArea = new TextArea();
  itemDescrArea.setBounds(12,108,194,168);
  add(itemDescrArea);

  // Adding label & text-field for ship_unit column
  shipUnitLabel = new Label("Ship Unit");
  shipUnitLabel.setBounds(24,288,60,38);
  add(shipUnitLabel);
  shipUnitField = new TextField();
  shipUnitField.setBounds(84,288,84,38);
  add(shipUnitField);

  // Adding label & text-field for unit_price column
  unitPriceLabel = new Label("Unit Price");
  unitPriceLabel.setBounds(24,336,60,38);
  add(unitPriceLabel);
  unitPriceField = new TextField();
  unitPriceField.setBounds(84,336,84,38);
  add(unitPriceField);

  // Adding label & text-field for stock column
  stockLabel = new Label("Stock");
  stockLabel.setBounds(36,384,36,38);
  add(stockLabel);
  stockField = new TextField();
  stockField.setBounds(84,384,84,38);
  add(stockField);

  // Adding label & ImgCanvas for item_picture column
  itemPictureLabel = new Label("Item Picture");
  itemPictureLabel.setBounds(216,24,72,24);
  add(itemPictureLabel);
  itemPictureCanvas = new ImgCanvas();
  itemPictureCanvas.setBounds(216,60,480,432);
  add(itemPictureCanvas);

  // Adding Next Row button
  nextRowBtn = new Button("Next Row");
  nextRowBtn.setBounds(60,432,84,48);
  add(nextRowBtn);

  // Adding actionListener for button action events
  nextRowBtn.addActionListener((ActionListener)
          new nextRowBtnActionListener());

  // Adding WindowListener for the main frame to process window events
  addWindowListener((WindowListener) new demo4WindowAdapter());
    }

    private void connectToDBServer() {
  try {
   String psqlDriver = "postgresql.Driver";

   // Register the POSTGRESQL-JDBC driver
   Driver PgsqlDrv = (Driver) Class.forName(psqlDriver).newInstance();

   // Get a connection to the database server
   conn = DriverManager.getConnection(connURL, usr, pwd);

   System.out.println("Driver loaded...and connection established");
  } catch (Exception e) {
   System.out.println("Could not connect to database server....");
   System.out.println(e.getMessage());
  }
    }

    private void executeQuery() {
  // The select statement to be used for querying the item table
  String selectStmt = "SELECT * FROM item";

  try {
   // Create a Statement object and use it to execute the query
   Statement stmt = conn.createStatement();
   queryResults = stmt.executeQuery(selectStmt);

   System.out.println("Query executed...");
  } catch (Exception e) {
   System.out.println("Could not execute query....");
   System.out.println(e.getMessage());
  }
    }


    // Private inner class extending java.awt.Canvas
    // Will be used for displaying the item_picture image
    private class ImgCanvas extends Canvas {
  Image myImage;

  private ImgCanvas() {
   super();
   myImage = null;
  }

  private void setImage(Image img) {
   myImage = img;
  }

  public void paint(Graphics g) {
   if(myImage == null)
    return;
   else
    g.drawImage(myImage, 0, 0, this);
  }
    }

    // Private inner class implementing the ActionListener interface
    // for the 'Next Row' button
    private class nextRowBtnActionListener implements ActionListener {
  // This is the code that will be executed whenever the 'Next Row'
  // button is pressed
  // Here, we get the values of all the columns of the current row
  // and display them
  public void actionPerformed(ActionEvent evt) {
   try {
    if (queryResults.next()) {
     // Getting the values of the item_num, ship_unit
     // unit_price, item_descr & stock columns and displaying them
     itemNumField.setText(queryResults.getString(1));
     itemDescrArea.setText(queryResults.getString(3));
     shipUnitField.setText(queryResults.getString(4));
     unitPriceField.setText(queryResults.getString(5));
     stockField.setText(queryResults.getString(6));

     // Getting the value of the item_picture column and
     // displaying it
     System.err.println("Got oid "+queryResults.getInt(2));
     byte itemPictureArray [] = queryResults.getBytes(2);
     if (itemPictureArray != null) {
      Image img =
Toolkit.getDefaultToolkit().createImage(itemPictureArray);
      itemPictureCanvas.setImage(img);
      itemPictureCanvas.repaint();
     }
    } else {
     System.out.println("No more rows!!");
    }
   } catch (Exception e) {
    System.out.println("Could not display next row...");
    System.out.println(e.getMessage());
   }
  }
    }


    // Private inner class implementing the WindowAdapter interface
    // for the main frame window
    private class demo4WindowAdapter extends WindowAdapter {
  // This is the code that will be executed whenever the frame
  // window is closed using the button in its upper-right corner
  public void windowClosing(WindowEvent evt) {
   setVisible(false); // hide the main frame
   dispose();   // free the system resources
   System.exit(0);  // close the application
  }
    }
}
------END----

Now I start it & attach to the backend with gdb.  After the frame is
up, I can select the next row (the first).  It works as it should.
When I select next (for the second), then I get the following back
trace:

vlad: ps -ef | grep po
    root   272     1  0   Apr 27 ?        0:00 /usr/lib/power/powerd
     bpm   771     1  0 10:45:48 pts/2    0:00 /opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -S 16384 -i -p 5
     bpm   796   771  1 10:53:49 pts/2    0:00 /opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -S 16384 -i -p 5
     bpm   798  1153  0 10:53:53 pts/10   0:00 grep po
vlad: gdb /opt/pgsql/bin/postmaster 796
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.7"...
(no debugging symbols found)...

/home/bpm/development/perl_ext/DBD-Pg-0.91/796: No such file or
directory.
Attaching to program `/opt/pgsql/bin/postmaster', process 796
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libcrypt_i.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)...done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
Symbols already loaded for /usr/lib/libgen.so.1
Symbols already loaded for /usr/lib/libcrypt_i.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libcurses.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/nss_files.so.1
0xff19311c in _so_recv ()
(gdb) bt
#0  0xff19311c in _so_recv ()
#1  0xbb4d4 in pq_recvbuf ()
#2  0xbb710 in pq_getbytes ()
#3  0x13e020 in SocketBackend ()
#4  0x13e124 in ReadCommand ()
#5  0x140434 in PostgresMain ()
#6  0x11161c in DoBackend ()
#7  0x110e78 in BackendStartup ()
#8  0x10fd98 in ServerLoop ()
#9  0x10f6e0 in PostmasterMain ()
#10 0xbca58 in main ()
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x19f180 in AllocSetAlloc ()
(gdb) bt
#0  0x19f180 in AllocSetAlloc ()
#1  0x19fa2c in GlobalMemoryAlloc ()
#2  0x19f7b8 in MemoryContextAlloc ()
#3  0x19fc58 in pstrdup ()
#4  0x1331c4 in inv_open ()
#5  0xb3e18 in lo_open ()
#6  0x199e38 in fmgr_c ()
#7  0x19a46c in fmgr ()
#8  0x13dc44 in HandleFunctionRequest ()
#9  0x14048c in PostgresMain ()
#10 0x11161c in DoBackend ()
#11 0x110e78 in BackendStartup ()
#12 0x10fd98 in ServerLoop ()
#13 0x10f6e0 in PostmasterMain ()
#14 0xbca58 in main ()

######## NEXT EXAMPLE ###############

I stopped/started the postmaster as:
/opt/pgsql/bin/postmaster -o "-d 3 -F -o ${PGSQLHOME}/logs/backend.log
-W 30 -S 16384" \
                          -i -d 3 -p 5432 -D ${PGDATA} >
${PGSQLHOME}/logs/error.log 2>&1 &

Now I ran the examples/blobtest, attached to the backend & got the
following:

vlad: ps -ef | grep po
    root   272     1  0   Apr 27 ?        0:00 /usr/lib/power/powerd
     bpm   815     1  0 11:00:58 pts/2    0:00 /opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 -
     bpm   830   815  0 11:01:37 pts/2    0:00 /opt/pgsql/bin/postmaster
-o -F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 -
     bpm   833  1153  0 11:01:45 pts/10   0:00 grep po
vlad: gdb /opt/pgsql/bin/postmaster 830
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "sparc-sun-solaris2.7"...
(no debugging symbols found)...

/opt/pgsql/logs/830: No such file or directory.
Attaching to program `/opt/pgsql/bin/postmaster', process 830
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libcrypt_i.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)...done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
Symbols already loaded for /usr/lib/libgen.so.1
Symbols already loaded for /usr/lib/libcrypt_i.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libcurses.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/nss_files.so.1
0xff195d88 in _sigsuspend ()
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x19f180 in AllocSetAlloc ()
(gdb) bt
#0  0x19f180 in AllocSetAlloc ()
#1  0x19fa2c in GlobalMemoryAlloc ()
#2  0x19f7b8 in MemoryContextAlloc ()
#3  0x5b69c in btrescan ()
#4  0x199e60 in fmgr_c ()
#5  0x19a46c in fmgr ()
#6  0x4d3a0 in index_rescan ()
#7  0x4cc70 in RelationGetIndexScan ()
#8  0x5b4d0 in btbeginscan ()
#9  0x199e8c in fmgr_c ()
#10 0x19a46c in fmgr ()
#11 0x4d2e4 in index_beginscan ()
#12 0x133624 in inv_seek ()
#13 0xb4070 in lo_lseek ()
#14 0x199e60 in fmgr_c ()
#15 0x19a46c in fmgr ()
#16 0x13dc44 in HandleFunctionRequest ()
#17 0x14048c in PostgresMain ()
#18 0x11161c in DoBackend ()
#19 0x110e78 in BackendStartup ()
#20 0x10fd98 in ServerLoop ()
#21 0x10f6e0 in PostmasterMain ()
#22 0xbca58 in main ()


I looked at src/backend/utils/mmgr/aset.c to see what was going on in
AllocSetAlloc, but I am but a mere mortal.

Thanks.


--
Brian Millett
Enterprise Consulting Group     "Heaven can not exist,
(314) 205-9030                     If the family is not eternal"
bpm@ec-group.com                   F. Ballard Washburn




Thu, 29 Apr 1999 11:40:09 -0500
Brian P Millett <bpm@ec-group.com>
SIGBUS in AllocSetAlloc & jdbc
On Thu, 29 Apr 1999, Brian P Millett wrote:

> Peter, I hope this long and boring message can shed some light on my
> difficulties getting jdbc & postgres6.5b1(current snapshot) to work
> with blobs.  I have NO problem with text, numeric, etc.  Just blobs &
> the LO interface.
> 
> I feel that it is a 64 vs 32 bit memory management problem.

At first glance, the JDBC code looks ok. In fact it is similar to the
ImageViewer example that's included with the source.

Do you get the same problem when using ImageViewer?

>      // Getting the value of the item_picture column and
>      // displaying it
>      System.err.println("Got oid "+queryResults.getInt(2));
>      byte itemPictureArray [] = queryResults.getBytes(2);
>      if (itemPictureArray != null) {
>       Image img =
> Toolkit.getDefaultToolkit().createImage(itemPictureArray);
>       itemPictureCanvas.setImage(img);
>       itemPictureCanvas.repaint();
>      }

Using an array is perfectly valid, and the driver does support this method
of getting an Image from a BLOB.

Tip: The JDBC spec says you should only read a field once. However, with
our driver, this is ok.

I'm not sure about the backend, but the JDBC side looks fine.

Peter

-- 
       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


Thu, 29 Apr 1999 18:44:19 +0100 (GMT)
Peter T Mount <peter@retep.org.uk>
Re: SIGBUS in AllocSetAlloc & jdbc
Peter T Mount wrote:

> On Thu, 29 Apr 1999, Brian P Millett wrote:
>
> > Peter, I hope this long and boring message can shed some light on my
> > difficulties getting jdbc & postgres6.5b1(current snapshot) to work
> > with blobs.  I have NO problem with text, numeric, etc.  Just blobs &
> > the LO interface.
> >
> > I feel that it is a 64 vs 32 bit memory management problem.
>
> At first glance, the JDBC code looks ok. In fact it is similar to the
> ImageViewer example that's included with the source.
>
> Do you get the same problem when using ImageViewer?

No, and yes.

The ImageViewer will give an error that the backend has lost connection after
importing the second image.  The first goes in just fine, it is the second
that causes the problem.  If I stop & restart the ImageViewer, then I can
import a second image.  BUT I can only view one.  When I try to view the
second, I get an error.  The back trace of that error is at the bottom.  It
IS the same as the backtrace for the example I sent you.  Again, the first
time I run ImageViewer, I can import only one image.  When I import a second
image, I get the backtrace (1).  After I stop & start the ImageViewer, there
is one image in the database.  I can import a new image, but when I try to
view the first image, I get backtrace (2).

BACKTRACE (1):
here is the bt:
vlad: ps -ef | grep po
    root   272     1  0   Apr 27 ?        0:00 /usr/lib/power/powerd
     bpm   815     1  0 11:00:58 pts/2    0:00 /opt/pgsql/bin/postmaster -o
-F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 -
     bpm   965  1153  0 13:41:54 pts/10   0:00 grep po
     bpm   961   815  0 13:41:49 pts/2    0:00 /opt/pgsql/bin/postmaster -o
-F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 -
vlad: gdb /opt/pgsql/bin/postmaster 961
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
(no debugging symbols found)...

/home/bpm/compile_area/cvs_pgsql/pgsql.snapshot/961: No such file or
directory.
Attaching to program `/opt/pgsql/bin/postmaster', process 961
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libcrypt_i.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)...done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
Symbols already loaded for /usr/lib/libgen.so.1
Symbols already loaded for /usr/lib/libcrypt_i.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libcurses.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/nss_files.so.1
0xff195d88 in _sigsuspend ()
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0xff145d70 in t_delete ()
(gdb) bt
#0  0xff145d70 in t_delete ()
#1  0xff145490 in _malloc_unlocked ()
#2  0xff145314 in malloc ()
#3  0x19f3a8 in AllocSetAlloc ()
#4  0x19fe48 in PortalHeapMemoryAlloc ()
#5  0x19f7b8 in MemoryContextAlloc ()
#6  0xb28c0 in initStringInfo ()
#7  0x13d4cc in SendFunctionResult ()
#8  0x13dcd4 in HandleFunctionRequest ()
#9  0x14048c in PostgresMain ()
#10 0x11161c in DoBackend ()
#11 0x110e78 in BackendStartup ()
#12 0x10fd98 in ServerLoop ()
#13 0x10f6e0 in PostmasterMain ()
#14 0xbca58 in main ()


BACKTRACE (2):
vlad: ps -ef | grep po
    root   272     1  0   Apr 27 ?        0:00 /usr/lib/power/powerd
     bpm   815     1  0 11:00:58 pts/2    0:00 /opt/pgsql/bin/postmaster -o
-F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 -
     bpm   983  1153  0 14:08:13 pts/10   0:00 grep po
     bpm   981   815  0 14:08:09 pts/2    0:00 /opt/pgsql/bin/postmaster -o
-F -o /opt/pgsql/logs/backend.log -W 30 -S 16384 -
vlad: gdb /opt/pgsql/bin/postmaster 981
GNU gdb 4.17
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
(no debugging symbols found)...

/home/bpm/compile_area/cvs_pgsql/pgsql.snapshot/981: No such file or
directory.
Attaching to program `/opt/pgsql/bin/postmaster', process 981
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libcrypt_i.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...
done.
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcurses.so.1...(no debugging symbols
found)...
done.
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)...done.
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols
found)...
done.
Symbols already loaded for /usr/lib/libgen.so.1
Symbols already loaded for /usr/lib/libcrypt_i.so.1
Symbols already loaded for /usr/lib/libnsl.so.1
Symbols already loaded for /usr/lib/libsocket.so.1
Symbols already loaded for /usr/lib/libdl.so.1
Symbols already loaded for /usr/lib/libm.so.1
Symbols already loaded for /usr/lib/libcurses.so.1
Symbols already loaded for /usr/lib/libc.so.1
Symbols already loaded for /usr/lib/libmp.so.2
Symbols already loaded for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
Symbols already loaded for /usr/lib/nss_files.so.1
0xff195d88 in _sigsuspend ()
(gdb) c
Continuing.

Program received signal SIGBUS, Bus error.
0x19f180 in AllocSetAlloc ()
(gdb) bt
#0  0x19f180 in AllocSetAlloc ()
#1  0x19fa2c in GlobalMemoryAlloc ()
#2  0x19f7b8 in MemoryContextAlloc ()
#3  0x4cc44 in RelationGetIndexScan ()
#4  0x5b4d0 in btbeginscan ()
#5  0x199e8c in fmgr_c ()
#6  0x19a46c in fmgr ()
#7  0x4d2e4 in index_beginscan ()
#8  0x133624 in inv_seek ()
#9  0x133514 in inv_seek ()
#10 0xb4070 in lo_lseek ()
#11 0x199e60 in fmgr_c ()
#12 0x19a46c in fmgr ()
#13 0x13dc44 in HandleFunctionRequest ()
#14 0x14048c in PostgresMain ()
#15 0x11161c in DoBackend ()
#16 0x110e78 in BackendStartup ()
#17 0x10fd98 in ServerLoop ()
#18 0x10f6e0 in PostmasterMain ()
#19 0xbca58 in main ()


--
Brian Millett
Enterprise Consulting Group     "Heaven can not exist,
(314) 205-9030                     If the family is not eternal"
bpm@ec-group.com                   F. Ballard Washburn




Thu, 29 Apr 1999 14:14:49 -0500
Brian P Millett <bpm@ec-group.com>
Re: SIGBUS in AllocSetAlloc & jdbc
> On Thu, 29 Apr 1999, Brian P Millett wrote:
> 
> > Peter, I hope this long and boring message can shed some light on my
> > difficulties getting jdbc & postgres6.5b1(current snapshot) to work
> > with blobs.  I have NO problem with text, numeric, etc.  Just blobs &
> > the LO interface.
> > 
> > I feel that it is a 64 vs 32 bit memory management problem.
> 
> At first glance, the JDBC code looks ok. In fact it is similar to the
> ImageViewer example that's included with the source.
> 
> Do you get the same problem when using ImageViewer?
> 
> >      // Getting the value of the item_picture column and
> >      // displaying it
> >      System.err.println("Got oid "+queryResults.getInt(2));
> >      byte itemPictureArray [] = queryResults.getBytes(2);
> >      if (itemPictureArray != null) {
> >       Image img =
> > Toolkit.getDefaultToolkit().createImage(itemPictureArray);
> >       itemPictureCanvas.setImage(img);
> >       itemPictureCanvas.repaint();
> >      }
> 
> Using an array is perfectly valid, and the driver does support this method
> of getting an Image from a BLOB.

This morning I started to look into this. First, JDBC driver coming
with 6.5b did not compile. The reason was my JDK (JDK 1.1.7 v1 on
LinuxPPC) returns version string as "root:10/14/98-13:50" and
makeVersion expected it started with "1.1". This was easy to fix. So I
went on and tried the ImageViewer sample. It gave me SQL an exception:

java example.ImageViewer jdbc:postgresql:test t-ishii ""
Connecting to Database URL = jdbc:postgresql:test
Exception caught.
java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try rebuilding.
Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try rebuilding.
Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
	at postgresql.Driver.connect(Compiled Code)
	at java.sql.DriverManager.getConnection(Compiled Code)
	at java.sql.DriverManager.getConnection(Compiled Code)
	at example.ImageViewer.<init>(Compiled Code)
	at example.ImageViewer.main(Compiled Code)

I had no idea how to fix this. I gave up to use the 6.5 JDBC driver. I
had to get back to the 6.4 JDBC driver.  This time ImageViewer seemed
to work. I imported 3 images. Worked fine. Then I tried to take a
glance at the first image. I got SIGSEGV on the backend! It happened in
AllocSetAlloc () and seems in the same place as Brian P Millett
mentioned. Next I switched the backend to 6.4.2(+ large object fixes
basically same as 6.5). Worked great!

In summary:

(1) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.5 backend failed
(2) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.4.2 backend worked

So I suspect there is something wrong with the 6.5 backend. I'll look
into this more.

P.S.  Peter, do you have any suggestion to make JDBC driver under JDK
1.1.7?
---
Tatsuo Ishii

Sun, 02 May 1999 21:51:20 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
> This morning I started to look into this. First, JDBC driver coming
> with 6.5b did not compile. The reason was my JDK (JDK 1.1.7 v1 on
> LinuxPPC) returns version string as "root:10/14/98-13:50" and
> makeVersion expected it started with "1.1". This was easy to fix. So I
> went on and tried the ImageViewer sample. It gave me SQL an exception:
> 
> java example.ImageViewer jdbc:postgresql:test t-ishii ""
> Connecting to Database URL = jdbc:postgresql:test
> Exception caught.
> java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try rebuilding.
> Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
> java.sql.SQLException: The postgresql.jar file does not contain the correct JDBC classes for this JVM. Try rebuilding.
> Exception thrown was java.lang.ClassNotFoundException: postgresql.jdbc2.Connection
> 	at postgresql.Driver.connect(Compiled Code)
> 	at java.sql.DriverManager.getConnection(Compiled Code)
> 	at java.sql.DriverManager.getConnection(Compiled Code)
> 	at example.ImageViewer.<init>(Compiled Code)
> 	at example.ImageViewer.main(Compiled Code)
> 
> I had no idea how to fix this. I gave up to use the 6.5 JDBC driver. I
> had to get back to the 6.4 JDBC driver.  This time ImageViewer seemed
> to work. I imported 3 images. Worked fine. Then I tried to take a
> glance at the first image. I got SIGSEGV on the backend! It happened in
> AllocSetAlloc () and seems in the same place as Brian P Millett
> mentioned. Next I switched the backend to 6.4.2(+ large object fixes
> basically same as 6.5). Worked great!
> 
> In summary:
> 
> (1) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.5 backend failed
> (2) 6.5 ImageViewer + 6.4.2 JDBC driver + 6.4.2 backend worked
> 
> So I suspect there is something wrong with the 6.5 backend. I'll look
> into this more.
> 
> P.S.  Peter, do you have any suggestion to make JDBC driver under JDK
> 1.1.7?

So far I couldn't find nothing special with the backend by now. Going
back to the ImageViewer, I think I found possible problem with it. In
my understanding, every lo call should be in single transaction block. 
But ImageViwer seems does not give any "begin" or "end" SQL commands.
I made a small modifications(see below patches) to the ImageViewer and
now it starts to work again with 6.5 backend! I suspect that
difference of palloc() code between 6.4.2 and 6.5 made the problem
opened up.
---
Tatsuo Ishii

*** ImageViewer.java~	Mon Oct 12 11:45:45 1998
--- ImageViewer.java	Sun May  2 23:16:27 1999
***************
*** 390,395 ****
--- 390,396 ----
    {
      try {
        System.out.println("Selecting oid for "+name);
+       stat.executeUpdate("begin");
        ResultSet rs = stat.executeQuery("select imgoid from images where imgname='"+name+"'");
        if(rs!=null) {
  	// Even though there should only be one image, we still have to
***************
*** 402,407 ****
--- 403,409 ----
  	}
        }
        rs.close();
+       stat.executeUpdate("end");
      } catch(SQLException ex) {
        label.setText(ex.toString());
      }

Sun, 02 May 1999 23:52:54 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> So far I couldn't find nothing special with the backend by now. Going
> back to the ImageViewer, I think I found possible problem with it. In
> my understanding, every lo call should be in single transaction block. 
> But ImageViwer seems does not give any "begin" or "end" SQL commands.
> I made a small modifications(see below patches) to the ImageViewer and
> now it starts to work again with 6.5 backend!

Hmm.  The documentation does say somewhere that LO object handles are
only good within a transaction ... so it's amazing this worked reliably
under 6.4.x.

Is there any way we could improve the backend's LO functions to defend
against this sort of misuse, rather than blindly accepting a stale
filehandle?

			regards, tom lane

Sun, 02 May 1999 13:12:10 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
[ I'm cc'ing this to java-linux as this seems to be a problem with the
Linux PPC port - peter ]

On Sun, 2 May 1999, Tatsuo Ishii wrote:

[snip]

> This morning I started to look into this. First, JDBC driver coming
> with 6.5b did not compile. The reason was my JDK (JDK 1.1.7 v1 on
> LinuxPPC) returns version string as "root:10/14/98-13:50" and
> makeVersion expected it started with "1.1". This was easy to fix. So I
> went on and tried the ImageViewer sample. It gave me SQL an exception:

[snip]

> P.S.  Peter, do you have any suggestion to make JDBC driver under JDK
> 1.1.7?

Ah, the first problem I've seen with the JVM version detection. the
postgresql.Driver class does the same thing as makeVersion, and checks the
version string, and when it sees that it starts with 1.1 it sets the base
package to postgresql.j1 otherwise it sets it to postgresql.j2.

The exceptions you are seeing is the JVM complaining it cannot find the
JDK1.2 classes.

As how to fix this, this is tricky. It seems that the version string isn't
that helpful. The JDK documentation says it returns the version of the
JVM, but there seems to be no set format for this. ie, with your version,
it seems to give a date and time that VM was built.

Java-Linux: Is there a way to ensure that the version string is similar to
the ones that Sun produces? At least having the JVM version first, then
reform after that?

The PostgreSQL JDBC driver is developed and tested under Linux (intel)
using 1.1.6 and 1.2b1 JVM's (both blackdown). I use Sun's Win32 1.2 JVM
for testing. The current driver works fine on all three JVM's, so it seems
to be the PPC port that has this problem.

Peter

-- 
       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


Mon, 3 May 1999 11:57:12 +0100 (GMT)
Peter T Mount <peter@retep.org.uk>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
On Sun, 2 May 1999, Tatsuo Ishii wrote:

> So far I couldn't find nothing special with the backend by now. Going
> back to the ImageViewer, I think I found possible problem with it. In
> my understanding, every lo call should be in single transaction block. 
> But ImageViwer seems does not give any "begin" or "end" SQL commands.
> I made a small modifications(see below patches) to the ImageViewer and
> now it starts to work again with 6.5 backend! I suspect that
> difference of palloc() code between 6.4.2 and 6.5 made the problem
> opened up.

This is true, and is probably why it was opened up.

However, with JDBC, you should never issue begin and end statements, as
this can cause the driver to become confused.

The reason is autoCommit. In jdbc, to start a transaction, you should call
the setAutoCommit() method in Connection to say if you want autocommit
(true), or transactions (false). The standard default is true.

> ---
> Tatsuo Ishii
> 
> *** ImageViewer.java~	Mon Oct 12 11:45:45 1998
> --- ImageViewer.java	Sun May  2 23:16:27 1999
> ***************
> *** 390,395 ****
> --- 390,396 ----
>     {
>       try {
>         System.out.println("Selecting oid for "+name);
> +       stat.executeUpdate("begin");
>         ResultSet rs = stat.executeQuery("select imgoid from images where imgname='"+name+"'");
>         if(rs!=null) {
>   	// Even though there should only be one image, we still have to
> ***************
> *** 402,407 ****
> --- 403,409 ----
>   	}
>         }
>         rs.close();
> +       stat.executeUpdate("end");
>       } catch(SQLException ex) {
>         label.setText(ex.toString());
>       }
> 

-- 
       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


Mon, 3 May 1999 12:01:40 +0100 (GMT)
Peter T Mount <peter@retep.org.uk>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
> Hmm.  The documentation does say somewhere that LO object handles are
> only good within a transaction ... so it's amazing this worked reliably
> under 6.4.x.
> 
> Is there any way we could improve the backend's LO functions to defend
> against this sort of misuse, rather than blindly accepting a stale
> filehandle?

It should not be very difficult. We could explicitly close LO
filehandles on commits.

But I'm now not confident on this. From comments in be-fsstubs.c:

>Builtin functions for open/close/read/write operations on large objects.
>These functions operate in the current portal variable context, which
>means the large object descriptors hang around between transactions and
>are not deallocated until explicitly closed, or until the portal is
>closed.

If above is true, LO filehandles should be able to survive between
transactions.

Following data are included in them. My question is: Can these data
survive between transactions? I guess not.

typedef struct LargeObjectDesc
{
	Relation	heap_r;		/* heap relation */
	Relation	index_r;	/* index relation on seqno attribute */
	IndexScanDesc iscan;		/* index scan we're using */
	TupleDesc	hdesc;		/* heap relation tuple desc */
	TupleDesc	idesc;		/* index relation tuple desc */

	[snip]

Mon, 03 May 1999 23:08:54 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
> > Hmm.  The documentation does say somewhere that LO object handles are
> > only good within a transaction ... so it's amazing this worked reliably
> > under 6.4.x.
> > 
> > Is there any way we could improve the backend's LO functions to defend
> > against this sort of misuse, rather than blindly accepting a stale
> > filehandle?
> 
> It should not be very difficult. We could explicitly close LO
> filehandles on commits.
> 
> But I'm now not confident on this. From comments in be-fsstubs.c:
> 
> >Builtin functions for open/close/read/write operations on large objects.
> >These functions operate in the current portal variable context, which
> >means the large object descriptors hang around between transactions and
> >are not deallocated until explicitly closed, or until the portal is
> >closed.
> 
> If above is true, LO filehandles should be able to survive between
> transactions.
> 
> Following data are included in them. My question is: Can these data
> survive between transactions? I guess not.
> 
> typedef struct LargeObjectDesc
> {
> 	Relation	heap_r;		/* heap relation */
> 	Relation	index_r;	/* index relation on seqno attribute */
> 	IndexScanDesc iscan;		/* index scan we're using */
> 	TupleDesc	hdesc;		/* heap relation tuple desc */
> 	TupleDesc	idesc;		/* index relation tuple desc */
> 
> 	[snip]

The answer was yes. Since these data are allocated in
GlobalMemoryContext, they could survive after commit. So next question
is why the backend crashes if LO calls are not in a transaction?

At the commit time _lo_commit() is called under GlobalMemoryContext to
destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be
created under GlobalMemoryContext.  But actually lo_read/lo_write,
they might create IndexScanDesc also, may not be called under the
context since no context switching is made with them(I don't know why
since other LO calls make context switching).  As a result it's
possible that IndexScanDesc might be freed under a wrong context. Too
bad.

This would not happen if lo_seek is done (it's executed under
GlobalMemoryContext) then lo_read/lo_write gets called(they reuse
IndexScanDesc created by inv_seek) *AND* no committing is done before
lo_read/lo_write. This is why we do not observe the backend crash with
ImageViewer running in a transaction.

But I must say other apps may not be as lucky as ImageViewer since
it's not always the case that lo_seek is called prior to
lo_read/lo_write.

[ BTW, ImageViewer seems to make calls to following set of LOs *twice*
to display an image. Why?

lo_open
lo_tell
lo_lseek
lo_lseek
lo_read
lo_close
]

Possible solutions might be:

(1) do a context switching in lo_read/lo_write

(2) ask apps not to make LO calls between transactions

(3) close LOs fd at commit

(2) is the current situation but not very confortable for us. Also for
a certain app this is not a solution as I mentioned above. (3) seems
reasonable but people might be surprised to find their existing apps
won't run any more. Moreover, changings might not be trivial and it
make me nervous since we don't have enough time before 6.5 is
out. With (1) modifications would be minimum, and we can keep the
backward compatibility for apps.  So my conclusion is that (1) is the
best. If there's no objection, I will commit the change for (1).
---
Tatsuo Ishii


Sun, 09 May 1999 12:12:18 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
> The answer was yes. Since these data are allocated in
> GlobalMemoryContext, they could survive after commit. So next question
> is why the backend crashes if LO calls are not in a transaction?
> 
> At the commit time _lo_commit() is called under GlobalMemoryContext to
> destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be
> created under GlobalMemoryContext.  But actually lo_read/lo_write,
> they might create IndexScanDesc also, may not be called under the
> context since no context switching is made with them(I don't know why
> since other LO calls make context switching).  As a result it's
> possible that IndexScanDesc might be freed under a wrong context. Too
> bad.
> 
> This would not happen if lo_seek is done (it's executed under
> GlobalMemoryContext) then lo_read/lo_write gets called(they reuse
> IndexScanDesc created by inv_seek) *AND* no committing is done before
> lo_read/lo_write. This is why we do not observe the backend crash with
> ImageViewer running in a transaction.
> 
> But I must say other apps may not be as lucky as ImageViewer since
> it's not always the case that lo_seek is called prior to
> lo_read/lo_write.
> 
> [ BTW, ImageViewer seems to make calls to following set of LOs *twice*
> to display an image. Why?
> 
> lo_open
> lo_tell
> lo_lseek
> lo_lseek
> lo_read
> lo_close
> ]
> 
> Possible solutions might be:
> 
> (1) do a context switching in lo_read/lo_write
> 
> (2) ask apps not to make LO calls between transactions
> 
> (3) close LOs fd at commit
> 
> (2) is the current situation but not very confortable for us. Also for
> a certain app this is not a solution as I mentioned above. (3) seems
> reasonable but people might be surprised to find their existing apps
> won't run any more. Moreover, changings might not be trivial and it
> make me nervous since we don't have enough time before 6.5 is
> out. With (1) modifications would be minimum, and we can keep the
> backward compatibility for apps.  So my conclusion is that (1) is the
> best. If there's no objection, I will commit the change for (1).

This is all clearly part of the large object mess that we were in before
you fixed large objects.

Do whatever you think is best for the long term.  Large objects were so
terribly fragile in previous releases, we might as well advertise them
again as now working 100% of the time.  If the new behaviour changes
existing apps, that is OK if the new behaviour is superior.  They will
be thrilled to change their apps if the large object system now works
better.

It would be different if the old system worked properly.


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

Sun, 9 May 1999 00:04:17 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc
> This is all clearly part of the large object mess that we were in before
> you fixed large objects.
> 
> Do whatever you think is best for the long term.  Large objects were so
> terribly fragile in previous releases, we might as well advertise them
> again as now working 100% of the time.  If the new behaviour changes
> existing apps, that is OK if the new behaviour is superior.  They will
> be thrilled to change their apps if the large object system now works
> better.
> 
> It would be different if the old system worked properly.

I have changed lo_read/lo_write so that they run under same memory
context as other LO calls.
---
Tatsuo Ishii

Sun, 09 May 1999 23:56:26 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> At the commit time _lo_commit() is called under GlobalMemoryContext to
> destroy IndexScanDesc. So it seems the IndexScanDesc is supposed to be
> created under GlobalMemoryContext.  But actually lo_read/lo_write,
> they might create IndexScanDesc also, may not be called under the
> context since no context switching is made with them(I don't know why
> since other LO calls make context switching).

I was noticing that yesterday (I modified be-fsstubs.c to use properly
allocated filehandles in lo_import and lo_export, and added extra
checking for a valid LO handle --- the old code would coredump if
handed a -1 handle, which is not too cool considering that's what it
would get if an app didn't bother to check for lo_open failure...).
It seemed odd that lo_read and lo_write didn't switch contexts like the
other entry points did.  But I didn't know enough to risk changing it.

> Possible solutions might be:
> (1) do a context switching in lo_read/lo_write

I agree with this, but I worry a little bit about memory leakage,
because anything allocated in GlobalMemoryContext is not going to get
cleaned up automatically.  If lo_read/lo_write call any code that is
sloppy about pfree'ing everything it palloc's, then you'd have a
long-term leakage that would eventually make the backend run out of
memory.  But it'd be easy enough to test for that, if you have a test
app that can run the backend through a lot of LO calls.

			regards, tom lane

Sun, 09 May 1999 11:53:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
> > Possible solutions might be:
> > (1) do a context switching in lo_read/lo_write
> 
> I agree with this, but I worry a little bit about memory leakage,
> because anything allocated in GlobalMemoryContext is not going to get
> cleaned up automatically.  If lo_read/lo_write call any code that is
> sloppy about pfree'ing everything it palloc's, then you'd have a
> long-term leakage that would eventually make the backend run out of
> memory.  But it'd be easy enough to test for that, if you have a test
> app that can run the backend through a lot of LO calls.

Yes, I thought about that too. Maybe we could destroy the
GlobalMemoryContext in lo_close() if no LO descriptor exists any more.
Of course this would not prevent the memory leakage if a user forget
to call lo_close, but it's of the user's responsibility anyway.
---
Tatsuo Ishii

Mon, 10 May 1999 09:58:06 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc 
Tatsuo Ishii wrote:

> > This is all clearly part of the large object mess that we were in before
> > you fixed large objects.
> >
> > Do whatever you think is best for the long term.  Large objects were so
> > terribly fragile in previous releases, we might as well advertise them
> > again as now working 100% of the time.  If the new behaviour changes
> > existing apps, that is OK if the new behaviour is superior.  They will
> > be thrilled to change their apps if the large object system now works
> > better.
> >
> > It would be different if the old system worked properly.
>
> I have changed lo_read/lo_write so that they run under same memory
> context as other LO calls.

Well, for the first time (for me) the blobtest.java now works correctly.

That would be Solaris 2.7, cvs checkout 19990511, jdk1.2.1_02.

Thank you all for the great work.

--
Brian Millett
Enterprise Consulting Group     "Heaven can not exist,
(314) 205-9030                     If the family is not eternal"
bpm@ec-group.com                   F. Ballard Washburn




Tue, 11 May 1999 13:03:11 -0500
Brian P Millett <bpm@ec-group.com>
Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc