Denis Perchine <[EMAIL PROTECTED]> writes:
>> lo_import and lo_export always execute in a transaction, just like any
>> other backend operation. There is no need to force them to be done in
>> a transaction block. If you're not clear about this, perhaps you need
>> to review the difference betwe
> > First of all it will not break lo_creat, lo_unlink for sure.
>
> lo_creat depends on inv_create followed by inv_close; your patch
> proposed to disable both of those outside transaction blocks.
> lo_unlink depends on inv_drop, which ditto. Your patch therefore
> restricts lo_creat and lo_unli
Denis Perchine <[EMAIL PROTECTED]> writes:
> First of all it will not break lo_creat, lo_unlink for sure.
lo_creat depends on inv_create followed by inv_close; your patch
proposed to disable both of those outside transaction blocks.
lo_unlink depends on inv_drop, which ditto. Your patch therefor
> > On Saturday 20 January 2001 10:05, you wrote:
> > > I just wanted to confirm that this patch was applied.
> >
> > Yes, it is. But the following patch is not applied. But I sure that it is
> > neccessary, otherwise we will get really strange errors (see discussion
> > in the thread).
> >
> > ht
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can people comment on the following patch that Dennis says is needed?
I object strongly. As given, this would break lo_creat, lo_unlink,
lo_import, and lo_export --- none of which need to be in a transaction
block --- not to mention possibly causing gr
Hi,
> OK, Denis, can you run the regression tests with your patch and see what
> is going on?
>
> > Bruce Momjian writes:
> > > Applied. Thanks. I know it is a pain to generate a new patch against
> > > the release.
> >
> > Regression tests opr_sanity and sanity_check are now failing.
This was
