Re: [HACKERS] Re: SIGBUS in AllocSetAlloc & jdbc - Mailing list pgsql-hackers

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