Re: Asymmetric partition-wise JOIN

2019年8月24日(土) 7:02 Thomas Munro : > > On Fri, Aug 23, 2019 at 4:05 AM Kohei KaiGai wrote: > > We can consider the table join ptable X t1 above is equivalent to: > > (ptable_p0 + ptable_p1 + ptable_p2) X t1 > > = (ptable_p0 X t1) + (ptable_p1 X t1) + (ptable_p2 X t1) > > It returns an equivalent

Re: using explicit_bzero

On 2019-08-14 05:00, Michael Paquier wrote: > On Tue, Aug 13, 2019 at 10:30:39AM +0200, Peter Eisentraut wrote: >> Another patch, to attempt to fix the Windows build. > > I have not been able to test the compilation, but the changes look > good on this side. Rebased patch, no functionality change

Re: POC: Cleaning up orphaned files using undo logs

On Fri, Aug 23, 2019 at 2:04 AM Thomas Munro wrote: > 2. Strict self-update-only: We could update it as part of > transaction cleanup. That is, when you commit or abort, probably at > some time when your transaction is still advertised as running, you go > and update your own transaction header

Re: mingw32 floating point diff

> I poked at this a bit more. I can reproduce the problem by using > -mfpmath=387 on dromedary's host (fairly old 32-bit macOS); although > I also get half a dozen *other* failures in the core regression tests, > mostly around detection of float overflow. So I'm not quite sure that > this is comp

Re: POC: Cleaning up orphaned files using undo logs

On Wed, Aug 21, 2019 at 4:34 PM Robert Haas wrote: > ReleaseResourcesAndProcessUndo() is only supposed to be called after > AbortTransaction(), and the additional steps it performs -- > AtCleanup_Portals() and AtEOXact_Snapshot() or alternatively > AtSubCleanup_Portals -- are taken from Cleanup(Su

Re: "ago" times on buildfarm status page

On 8/21/19 10:52 AM, Andrew Dunstan wrote: >> >> The Javscript could also be made to update the "ago" part every minute, >> and show the absoulte time as a tooltip, which is what pretty much every >> other website does. >> > > The code for the page is here: >

Re: mingw32 floating point diff

Emre Hasegeli writes: > I couldn't test if it helps, but another solution may be is to rip out > pg_hypot() in favour of the libc implementation. This was discussed > in detail as part of "Improve geometric types" thread. Hm ... the problem we're trying to fix here is platform-varying results. S

Re: Re: Email to hackers for test coverage

>Hi Movead, >Please add that to commitfest. Thanks and I just do it, it is https://commitfest.postgresql.org/24/2258/ -- Movead Li

Re: Why overhead of SPI is so large?

On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote: > pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik < > k.knizh...@postgrespro.ru> napsal: > > > > > > > On 22.08.2019 18:56, Pavel Stehule wrote: > > > > > > > > čt 22. 8. 2019 v 17:51 odesílatel Konstantin Knizhnik < > > k.knizh.

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

On Fri, Aug 23, 2019 at 10:04:13PM -0400, Stephen Frost wrote: > > Well, I think they might do that to reduce encryption overhead. I think > > tests have shown that is not an issue, but we will need to test further. > > I seriously doubt that's why and I don't think there's actually much > value

Re: Why overhead of SPI is so large?

so 24. 8. 2019 v 18:01 odesílatel David Fetter napsal: > On Fri, Aug 23, 2019 at 11:10:28AM +0200, Pavel Stehule wrote: > > pá 23. 8. 2019 v 11:05 odesílatel Konstantin Knizhnik < > > k.knizh...@postgrespro.ru> napsal: > > > > > > > > > > > On 22.08.2019 18:56, Pavel Stehule wrote: > > > > > > >

Re: assertion at postmaster start

I wrote: > Andres Freund writes: >> On 2019-06-15 12:09:50 -0400, Alvaro Herrera wrote: >>> Once in a blue moon I get this assertion failure on server start: >>> TRAP: FailedAssertion("!(AbortStartTime == 0)", Archivo: >>> "/pgsql/source/master/src/backend/postmaster/postmaster.c", Linea: 2957)

Re: [PATCH] Make configuration file "include" directive handling more robust

Ian Barwick writes: > On 7/17/19 5:34 PM, Kyotaro Horiguchi wrote:> Hello. >>> I don't think this is new to 12. > No, though I'm not sure how much this would be seen as a bugfix > and how far back it would be sensible to patch. I think this is worth considering as a bugfix; although I'm afraid w

LLVM breakage on seawasp

Hi, llvmjit_inline.cpp:177:55: error: ‘make_unique’ is not a member of ‘llvm’ std::unique_ptr globalsToInline = llvm::make_unique(); That's because they just moved to C++14 and replaced their own llvm::make_unique<> with std::make_unique<>: https://github.com/llvm-mirror/llvm/commit/114087caa6

Re: LLVM breakage on seawasp

Hi, On August 24, 2019 1:08:11 PM PDT, Thomas Munro wrote: >Hi, > >llvmjit_inline.cpp:177:55: error: ‘make_unique’ is not a member of >‘llvm’ > std::unique_ptr globalsToInline = >llvm::make_unique(); > >That's because they just moved to C++14 and replaced their own >llvm::make_unique<> with std:

Re: assertion at postmaster start

I wrote: > I think what this demonstrates is that that Assert is just wrong: > we *can* reach PM_RUN with the flag still set, so we should do > StartupStatus = STARTUP_NOT_RUNNING; > FatalError = false; > - Assert(AbortStartTime == 0);

Re: LLVM breakage on seawasp

Andres Freund writes: > On August 24, 2019 1:08:11 PM PDT, Thomas Munro > wrote: >> That's because they just moved to C++14 and replaced their own >> llvm::make_unique<> with std::make_unique<>: >> https://github.com/llvm-mirror/llvm/commit/114087caa6f95b526861c3af94b3093d9444c57b >> Perhaps we'

Re: LLVM breakage on seawasp

Hi, On August 24, 2019 1:57:56 PM PDT, Tom Lane wrote: >Andres Freund writes: >> On August 24, 2019 1:08:11 PM PDT, Thomas Munro > wrote: >>> That's because they just moved to C++14 and replaced their own >>> llvm::make_unique<> with std::make_unique<>: >>> >https://github.com/llvm-mirror/llvm/c

Re: LLVM breakage on seawasp

On Sun, Aug 25, 2019 at 8:24 AM Andres Freund wrote: > On August 24, 2019 1:08:11 PM PDT, Thomas Munro > wrote: > >Perhaps we'll need some macrology to select between llvm and std > >versions? I am guessing we can't decree that PostgreSQL's minimum C++ > >level is C++14 and simply change it to

Re: LLVM breakage on seawasp

Andres Freund writes: > On August 24, 2019 1:57:56 PM PDT, Tom Lane wrote: >> So we're depending on APIs that upstream doesn't think are stable? > Seawasp iirc builds against the development branch of llvm, which explains > why we see failures there. Does that address what you are concerned ab

Re: LLVM breakage on seawasp

Hi, On August 24, 2019 2:37:55 PM PDT, Tom Lane wrote: >Andres Freund writes: >> On August 24, 2019 1:57:56 PM PDT, Tom Lane >wrote: >>> So we're depending on APIs that upstream doesn't think are stable? > >> Seawasp iirc builds against the development branch of llvm, which >explains why we se

Re: LLVM breakage on seawasp

Hi, On 2019-08-25 09:15:35 +1200, Thomas Munro wrote: > On Sun, Aug 25, 2019 at 8:24 AM Andres Freund wrote: > > On August 24, 2019 1:08:11 PM PDT, Thomas Munro > > wrote: > > >Perhaps we'll need some macrology to select between llvm and std > > >versions? I am guessing we can't decree that Po

Re: LLVM breakage on seawasp

Andres Freund writes: > On August 24, 2019 2:37:55 PM PDT, Tom Lane wrote: >> I know it's the development branch. The question is whether this >> breakage is something *they* ought to be fixing. If not, I'm >> worried that we're too much in bed with implementation details >> of LLVM that we sho

Re: Optimize single tuple fetch from nbtree index

> Hello, > welcome to hackers with your first patch) Thank you. > Though, I got interested in the comment inconsistency you have found. > I added debug message into this code branch of the patch and was able to > see it in regression.diffs after 'make check': > Speaking of your patch, it seems t

pg11.5: ExecHashJoinNewBatch: glibc detected...double free or corruption (!prev)

Core was generated by `postgres: telsasoft ts 10.100.2.162(33500) SELECT '. Program terminated with signal 6, Aborted. #0 0x0039ff6325e5 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); Missing separate debuginf

Re: LLVM breakage on seawasp

On Sun, Aug 25, 2019 at 9:46 AM Andres Freund wrote: > > Maybe we should just use std::unique_ptr's constructor, ie give it new > > ImportMayTy() instead of using make_unique(), even though that's not > > cool C++ these days? > > Yea, wfm. do you want to make it so? Done. -- Thomas Munro https:

Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free or corruption (!prev)

On Sat, Aug 24, 2019 at 7:25 PM Justin Pryzby wrote: > Merlin: what OS are you running on and what postgres package, or was it > compiled locally ? I was reminded of this issue from last year, which also appeared to involve BufFileClose() and a double-free: https://postgr.es/m/87y3hmee19@new