Em qua., 23 de jun. de 2021 às 21:51, Tom Lane escreveu:
> Greg Nancarrow writes:
> > On Wed, Jun 23, 2021 at 11:01 PM Tom Lane wrote:
> >> The comment is written in terms of "when can we
> >> skip taking a snapshot", while the test in the code is written for
> >> the inverse condition "when do
Em qua., 23 de jun. de 2021 às 21:45, Greg Nancarrow
escreveu:
> On Wed, Jun 23, 2021 at 11:01 PM Tom Lane wrote:
> >
> >
> > The code is correct as-is; the proposed change would result in taking
> > more snapshots than needed. Perhaps the comment needs revision, since
> > you both misread it.
Greg Nancarrow writes:
> On Wed, Jun 23, 2021 at 11:01 PM Tom Lane wrote:
>> The comment is written in terms of "when can we
>> skip taking a snapshot", while the test in the code is written for
>> the inverse condition "when do we need a snapshot".
> Perhaps that code could have been written as
On Wed, Jun 23, 2021 at 11:01 PM Tom Lane wrote:
>
>
> The code is correct as-is; the proposed change would result in taking
> more snapshots than needed. Perhaps the comment needs revision, since
> you both misread it. The comment is written in terms of "when can we
> skip taking a snapshot", w
Greg Nancarrow writes:
> On Tue, Jun 22, 2021 at 10:56 PM Ranier Vilela wrote:
>> The comments in the function are clear:
>> If expression is mutable OR is a non-read-only function, so need a snapshot.
> I have to agree with you.
> Looks like the "&&" should really be an "||". The explanation in
Em qua., 23 de jun. de 2021 às 03:04, Greg Nancarrow
escreveu:
> On Tue, Jun 22, 2021 at 10:56 PM Ranier Vilela
> wrote:
> >
> > On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> > > The following generates an assertion failure. Quick testing with start
> and
> > > stop as well as the
On Tue, Jun 22, 2021 at 10:56 PM Ranier Vilela wrote:
>
> On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> > The following generates an assertion failure. Quick testing with start and
> > stop as well as the core dump shows it’s failing on the execution of
> > `schema_name := schema_na
On Wed, Jun 23, 2021 at 12:07:11AM -0400, Tom Lane wrote:
> Justin Pryzby writes:
> > This causes the server to crash during FETCH.
>
> > ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
> > BEGIN
> > DECLARE CURSOR
> > server closed the connection unexpectedly
> > This probabl
Justin Pryzby writes:
> This causes the server to crash during FETCH.
> ts=# begin; declare b cursor for VALUES(1); fetch 100 in b;
> BEGIN
> DECLARE CURSOR
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while process
On Tue, Jun 22, 2021 at 01:13:08PM -0400, Tom Lane wrote:
> I wrote:
> > The attached seems to be enough to resolve Jim's example. I'd like
> > to invent a test case that involves a detoast of the simple
> > expression's result, too, to show that transiently pushing a
> > snapshot for the duration
I wrote:
> The attached seems to be enough to resolve Jim's example. I'd like
> to invent a test case that involves a detoast of the simple
> expression's result, too, to show that transiently pushing a
> snapshot for the duration of the expression is not the right fix.
Here we go. This test cas
I wrote:
> Hmm. I think the real issue here is that commit 84f5c2908 did
> not cover the "simple expression" code path in plpgsql. We
> need to re-establish an outer snapshot when the next thing
> that happens after COMMIT is a simple expression, too.
The attached seems to be enough to resolve J
Michael Paquier writes:
> On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
>> The following generates an assertion failure.
> A bisect run points me to the following commit:
> commit 73b06cf893c9d3bb38c11878a12cc29407e78b6c
> Author: Tom Lane
> Date: Fri Nov 22 15:02:18 2019 -0500
>
On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> The following generates an assertion failure. Quick testing with start and
> stop as well as the core dump shows it’s failing on the execution of
> `schema_name := schema_name(i)` immediately after COMMIT, because there’s
no
> active sna
On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote:
> The following generates an assertion failure. Quick testing with start and
> stop as well as the core dump shows it’s failing on the execution of
> `schema_name := schema_name(i)` immediately after COMMIT, because there’s no
> active snap
15 matches
Mail list logo
