On Mon, 4 Jul 2022 15:51:32 +0900
Michael Paquier wrote:
> On Wed, Jun 29, 2022 at 05:29:50PM +0900, Yugo NAGATA wrote:
> > Thank you for reviewing the patch. I attached the updated patch.
>
> Thanks for the new version. I have looked at that again, and the set
> of changes seem fine (including
On Wed, Jun 29, 2022 at 05:29:50PM +0900, Yugo NAGATA wrote:
> Thank you for reviewing the patch. I attached the updated patch.
Thanks for the new version. I have looked at that again, and the set
of changes seem fine (including the change for the alternate output).
So, applied.
--
Michael
sign
Hello Michael-san,
Thank you for reviewing the patch. I attached the updated patch.
On Thu, 16 Jun 2022 17:31:22 +0900
Michael Paquier wrote:
> Looking at the docs of large objects, as of "Client Interfaces", we
> mention that any action must take place in a transaction block.
> Shouldn't we ad
On Thu, Jun 16, 2022 at 03:42:06PM +0900, Yugo NAGATA wrote:
> I am not sure if we should use PreventCommandIfReadOnly in lo_write()
> because there are other public functions that write to catalogs but there
> are not the similar restrictions in such functions. I think it is caller's
> responsibil
On Thu, 2 Jun 2022 07:43:06 +0900
Michael Paquier wrote:
> On Wed, Jun 01, 2022 at 10:15:17AM -0400, Tom Lane wrote:
> > It's always appropriate to consider backwards compatibility, and we
> > frequently don't back-patch a change because of worries about that.
> > However, if someone complains be
On Wed, Jun 01, 2022 at 10:15:17AM -0400, Tom Lane wrote:
> It's always appropriate to consider backwards compatibility, and we
> frequently don't back-patch a change because of worries about that.
> However, if someone complains because we start rejecting this as of
> v15 or v16, I don't think the
Robert Haas writes:
> On Wed, Jun 1, 2022 at 1:29 AM Michael Paquier wrote:
>> Now the LO handling is quite old, and I am not sure if this is worth
>> changing as we have seen no actual complains about that with read-only
>> transactions, even if I agree on that it is inconsistent. That could
>>
On Wed, Jun 1, 2022 at 1:29 AM Michael Paquier wrote:
> Now the LO handling is quite old, and I am not sure if this is worth
> changing as we have seen no actual complains about that with read-only
> transactions, even if I agree on that it is inconsistent. That could
> cause more harm than the c
On Tue, May 31, 2022 at 05:17:42PM -0400, Robert Haas wrote:
> On Tue, May 31, 2022 at 3:49 PM Tom Lane wrote:
>> What I'm wondering about is how far the principle of read-only-ness
>> ought to be expected to go. Should a read-only transaction fail
>> to execute adminpack's pg_file_write(), for e
On Tue, May 31, 2022 at 3:49 PM Tom Lane wrote:
> Yeah. Certainly we'd not want to back-patch this change, in case
> anyone is relying on the current behavior ... but it's hard to argue
> that it's not wrong.
Agreed.
> What I'm wondering about is how far the principle of read-only-ness
> ought
Robert Haas writes:
> On Sat, May 28, 2022 at 5:01 AM Michael Paquier wrote:
>> Well, there is an actual risk to break applications that have worked
>> until now for a behavior that has existed for years with zero
>> complaints on the matter, so I would leave that alone. Saying that, I
>> don't
On Sat, May 28, 2022 at 5:01 AM Michael Paquier wrote:
> Well, there is an actual risk to break applications that have worked
> until now for a behavior that has existed for years with zero
> complaints on the matter, so I would leave that alone. Saying that, I
> don't really disagree with improv
On Fri, May 27, 2022 at 02:02:24PM +0200, Laurenz Albe wrote:
> On Fri, 2022-05-27 at 15:30 +0900, Yugo NAGATA wrote:
>> Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
>> and lo_from_bytea are allowed even in read-only transactions.
>> By using them, pg_largeobject and pg_largeobjec
On Mon, May 30, 2022 at 05:44:18PM +0900, Yugo NAGATA wrote:
> As to the error messages during recovery, I think it is better to improve
> it, because the current messages are emitted by elog() and it seems to imply
> they are internal errors that we don't expected. I attached a updated patch
> for
On Sat, 28 May 2022 18:00:54 +0900
Michael Paquier wrote:
> On Fri, May 27, 2022 at 03:30:28PM +0900, Yugo NAGATA wrote:
> > Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> > and lo_from_bytea are allowed even in read-only transactions.
> > By using them, pg_largeobject and pg_la
On Fri, May 27, 2022 at 03:30:28PM +0900, Yugo NAGATA wrote:
> Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> and lo_from_bytea are allowed even in read-only transactions.
> By using them, pg_largeobject and pg_largeobject_metatable can
> be modified in read-only transactions and
On Fri, 2022-05-27 at 15:30 +0900, Yugo NAGATA wrote:
> Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
> and lo_from_bytea are allowed even in read-only transactions.
> By using them, pg_largeobject and pg_largeobject_metatable can
> be modified in read-only transactions and the eff
Hello,
Currently, lo_creat(e), lo_import, lo_unlink, lowrite, lo_put,
and lo_from_bytea are allowed even in read-only transactions.
By using them, pg_largeobject and pg_largeobject_metatable can
be modified in read-only transactions and the effect remains
after the transaction finished. Is it unac
18 matches
Mail list logo
