Re: powerpc pg_atomic_compare_exchange_u32_impl: error: comparison of integer expressions of different signedness (Re: pgsql: For all ppc compilers, implement compare_exchange and) fetch_add

2020-10-10 Thread Noah Misch
On Fri, Oct 09, 2020 at 03:01:17AM -0700, Noah Misch wrote: > On Fri, Oct 09, 2020 at 11:28:25AM +0200, Christoph Berg wrote: > > pg-cron on powerpc/ppc64/ppc64el is raising this warning inside the > > ppc atomics: > > > > gcc -Wall -Wmissing-prototypes -Wpointer-arith > >

Re: Parallel INSERT (INTO ... SELECT ...)

2020-10-10 Thread Thomas Munro
On Sun, Oct 11, 2020 at 12:55 AM Amit Kapila wrote: > + /* > + * For Parallel INSERT, provided no tuples are returned from workers > + * to gather/leader node, don't add a cost-per-row, as each worker > + * parallelly inserts the tuples that result from its chunk of plan > + * execution. This

Re: Parallel INSERT (INTO ... SELECT ...)

2020-10-10 Thread Amit Kapila
On Sat, Oct 10, 2020 at 5:25 PM Amit Kapila wrote: > > 8. You have made changes related to trigger execution for Gather node, > don't we need similar changes for GatherMerge node? > .. > > 10. Don't we need a change similar to cost_gather in > cost_gather_merge? It seems you have made only

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Tom Lane
Michael Paquier writes: > We are visibly not completely out of the woods yet, jacana is > reporting a compilation error: Nah, I fixed that hours ago (961e07b8c). jacana must not have run again yet. regards, tom lane

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Michael Paquier
On Sat, Oct 10, 2020 at 09:00:27PM +0200, Juan José Santamaría Flecha wrote: > Great, thanks again to everyone who has taken some time to look into this. We are visibly not completely out of the woods yet, jacana is reporting a compilation error:

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Juan José Santamaría Flecha
On Sat, Oct 10, 2020 at 7:43 PM Tom Lane wrote: > > I concur with Michael that it's inappropriate to make an end run around > _dosmaperr() here. If you think that the DEBUG5 logging inside that > is inappropriate, you should propose removing it outright. > > Pushed the rest of this. > Great,

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Tom Lane
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= writes: > If the file does not exist there is no need to call _dosmaperr() and log > the error. I concur with Michael that it's inappropriate to make an end run around _dosmaperr() here. If you think that the DEBUG5 logging inside that is

Re: Make LANGUAGE SQL the default

2020-10-10 Thread Pavel Stehule
so 10. 10. 2020 v 18:14 odesílatel Tom Lane napsal: > Peter Eisentraut writes: > > A sub-patch extracted from the bigger patch in thread "SQL-standard > > function body"[0]: Make LANGUAGE SQL the default in CREATE FUNCTION and > > CREATE PROCEDURE, per SQL standard. > > I'm suspicious of doing

Re: Make LANGUAGE SQL the default

2020-10-10 Thread Tom Lane
Peter Eisentraut writes: > A sub-patch extracted from the bigger patch in thread "SQL-standard > function body"[0]: Make LANGUAGE SQL the default in CREATE FUNCTION and > CREATE PROCEDURE, per SQL standard. I'm suspicious of doing this, mainly because DO does not have that default. I think

Re: Batching page logging during B-tree build

2020-10-10 Thread Andrey Borodin
> 23 сент. 2020 г., в 23:29, Andres Freund написал(а): > > Hi, > > On 2020-09-23 11:19:18 -0700, Peter Geoghegan wrote: >> On Fri, Sep 18, 2020 at 8:39 AM Andrey M. Borodin >> wrote: >>> Here is PoC with porting that same routine to B-tree. It allows to build >>> B-trees ~10% faster on my

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Juan José Santamaría Flecha
On Sat, Oct 10, 2020 at 2:24 PM Michael Paquier wrote: > > - _dosmaperr(GetLastError()); > + DWORD err = GetLastError(); > + > + /* report when not ERROR_SUCCESS */ > + if (err == ERROR_FILE_NOT_FOUND || err == >

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Michael Paquier
On Sat, Oct 10, 2020 at 01:31:21PM +0200, Juan José Santamaría Flecha wrote: > Thanks for taking care of this. I see no problems in the build farm, but > please reach me if I missed something. Thanks for continuing your work on this patch. I see no related failures in the buildfarm. -

Re: [PATCH] Add `truncate` option to subscription commands

2020-10-10 Thread David Christensen
> On Oct 10, 2020, at 12:14 AM, Amit Kapila wrote: > > On Sat, Oct 10, 2020 at 12:24 AM David Christensen > wrote: >> >> -hackers, >> >> Enclosed find a patch to add a “truncate” option to subscription commands. >> >> When adding new tables to a subscription (either via `CREATE

Re: Parallel INSERT (INTO ... SELECT ...)

2020-10-10 Thread Amit Kapila
On Fri, Oct 9, 2020 at 2:39 PM Amit Kapila wrote: > > On Tue, Oct 6, 2020 at 3:08 PM Greg Nancarrow wrote: > > > > On Mon, Oct 5, 2020 at 10:36 PM Dilip Kumar wrote: > > > > Also, I have attached a separate patch (requested by Andres Freund) > > that just allows the underlying SELECT part of

Re: BUG #15858: could not stat file - over 4GB

2020-10-10 Thread Juan José Santamaría Flecha
On Fri, Oct 9, 2020 at 10:22 PM Tom Lane wrote: > Emil Iggland writes: > > I tested the patch at hand, and it performs as expected. Files larger > than 4GB can be imported. > > Thanks for testing! > Thanks for testing! +1 > > I'd been expecting one of our Windows-savvy committers to pick

Make LANGUAGE SQL the default

2020-10-10 Thread Peter Eisentraut
A sub-patch extracted from the bigger patch in thread "SQL-standard function body"[0]: Make LANGUAGE SQL the default in CREATE FUNCTION and CREATE PROCEDURE, per SQL standard. [0]: https://www.postgresql.org/message-id/flat/1c11f1eb-f00c-43b7-799d-2d44132c0...@2ndquadrant.com -- Peter

Re: SQL-standard function body

2020-10-10 Thread Peter Eisentraut
On 2020-09-29 07:42, Michael Paquier wrote: On Mon, Sep 07, 2020 at 08:00:08AM +0200, Peter Eisentraut wrote: Some conflicts have emerged, so here is an updated patch. I have implemented/fixed the inlining of set-returning functions written in the new style, which was previously marked TODO in

Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump.

2020-10-10 Thread movead...@highgo.ca
>I think that the length of the XLOG_SWITCH record is no other than 24 >bytes. Just adding the padding? garbage bytes to that length doesn't >seem the right thing to me. > >If we want pg_waldump to show that length somewhere, it could be shown >at the end of that record explicitly: > >rmgr: XLOG