Re: moonjelly vs tsearch

2019-09-07 Thread Fabien COELHO
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

Re: [PATCH] Connection time for \conninfo

2019-09-07 Thread Rodrigo Ramírez Norambuena
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 > >>

Re: Change ereport level for QueuePartitionConstraintValidation

2019-09-07 Thread Tom Lane
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

Re: Change ereport level for QueuePartitionConstraintValidation

2019-09-07 Thread Alvaro Herrera from 2ndQuadrant
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

Re: Change ereport level for QueuePartitionConstraintValidation

2019-09-07 Thread Tom Lane
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

Re: Python versions (was Re: RHEL 8.0 build)

2019-09-07 Thread Tom Lane 
Peter Eisentraut  writes:
>>> [ patch to search for python, then python3, then python2 ]

> Committed with some documentation updates.

> I only backpatched to PG10, because before that the handling of absolute
> paths vs nonabsolute paths is a bit murky and

Re: SQL-spec incompatibilities in similar_escape() and related stuff

2019-09-07 Thread Tom Lane
Alvaro Herrera from 2ndQuadrant writes: > Marked ready for committer. Thanks for reviewing. I adopted your doc change suggestions and pushed it. regards, tom lane

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread fn ln
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

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread Fabien COELHO
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'

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread fn ln
> 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

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread Fabien COELHO
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

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread Andres Freund
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

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread fn ln
> 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

Re: Patch to add hook to copydir()

2019-09-07 Thread Swen Kooij
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

Re: BUG #15977: Inconsistent behavior in chained transactions

2019-09-07 Thread Fabien COELHO
Hello, I do think the fact that COMMIT in multi-statement implicit transaction has some usecase, is an argument for just implementing it properly... Like Peter, I would also keep an ERROR for now, as we could always relax that later on. I can agree with both warning and error, but for me