News from Fabien's bleeding edge compiler zoo: apparently GCC 10
20190831 thinks the tsearch test should produce different output than
20190824 did. It looks like the parsing of question marks change...
Indeed, that looks pretty strange.
I can't wait for next week's installment.
I'll rel
On Thu, Sep 5, 2019 at 2:22 PM Tom Lane wrote:
>
> =?UTF-8?Q?Rodrigo_Ram=C3=ADrez_Norambuena?= writes:
> > On Tue, Sep 3, 2019 at 11:06 PM Michael Paquier wrote:
> >> You can do basically the same thing by looking at
> >> pg_stat_activity.backend_start and compare it with the clock
> >> timestam
Alvaro Herrera from 2ndQuadrant writes:
> I've marked https://commitfest.postgresql.org/24/2076/ committed also.
Yeah, I just remembered about doing that, and saw you'd beat me to it.
regards, tom lane
On 2019-Sep-07, Tom Lane wrote:
> I wrote:
> > Or, of course, we could forget the whole thing and switch the output
> > level for these messages to NOTICE instead. I'm not for that, but
> > now that we see what it'll cost us to have them better hidden, we can
> > at least have an informed debate.
I wrote:
> Or, of course, we could forget the whole thing and switch the output
> level for these messages to NOTICE instead. I'm not for that, but
> now that we see what it'll cost us to have them better hidden, we can
> at least have an informed debate.
> Thoughts?
Hearing no comments, I've pus
Alvaro Herrera from 2ndQuadrant writes:
> Marked ready for committer.
Thanks for reviewing. I adopted your doc change suggestions
and pushed it.
regards, tom lane
No, but instead always do an implicit COMMIT after each statement, like
SELECT 1; SELECT 2; (not \;) in psql.
The PostgreSQL document even states that 'Issuing COMMIT when not inside a
transaction does no harm, but it will provoke a warning message.' for a
long time,
but in fact it have side-effect
Now, I'd prefer error in all cases, no doubt about that, which might be
considered a regression. A way around that could be to have a GUC decide
between a strict behavior (error) and the old behavior (warning).
I think it's more better to have a GUC to disable implicit transaction
'block' feat
> Missed them somehow. But I don't think they're quite sufficient. I think
> at least we also need tests that test things like multi-statement
> exec_simple-query() *with* explicit transactions and chaining.
Added a few more tests for that.
> Now, I'd prefer error in all cases, no doubt about that
I made another patch for that.
I don't have much confidence with my English spelling so further
improvements may be needed.
If it is too much a change and potential regression, then I think that the
"and chain" variants should be consistent and just raise warnings.
We don't have an exact a
Hi,
On 2019-09-06 16:54:15 +0900, Michael Paquier wrote:
> On Thu, Sep 05, 2019 at 02:11:35PM -0700, Andres Freund wrote:
> > On 2019-09-05 14:16:11 +0200, Peter Eisentraut wrote:
> >> I'm content with this patch.
> >
> > Would need tests.
>
> The latest patch sends adds coverage for all the new
> Looking at the latest patch, the comment blocks on top of TBLOCK_STARTED
> and TBLOCK_IMPLICIT_INPROGRESS in EndTransactionBlock() need an update
> to mention the difference of behavior with chained transactions. And
> the same comment rework should be done in UserAbortTransactionBlock()
> for T
Should I forget about getting such a patch in?
I am up for implementing alternative solutions if the current
one is considered unacceptable. As I tried to demonstrate
in my last email, previous attempts also failed.
On Tue, Sep 3, 2019 at 12:14 PM Swen Kooij wrote:
>
> I read two previous propos
13 matches
Mail list logo
