"insaf.k" wrote:
I am trying to build PG from source, in MS Windows using MSYS2 and
MinGW-w64. I've tried to build PG 10.0 as wells as 10.3.
I've done configuring like this
./configure --prefix="/d/pg10/"
And when I do "make" or "make world", I'm getting
On Thu, May 3, 2018 at 4:48 PM, Tom Lane wrote:
> Thomas Munro writes:
>> On Thu, May 3, 2018 at 4:04 PM, Tom Lane wrote:
>>> It strikes me also that, at least for debugging purposes, it's seriously
>>> awful that you can't
Thomas Munro writes:
> On Thu, May 3, 2018 at 4:04 PM, Tom Lane wrote:
>> It strikes me also that, at least for debugging purposes, it's seriously
>> awful that you can't tell from outside what result this function got.
> I don't think *broken*
On Thu, May 3, 2018 at 4:04 PM, Tom Lane wrote:
> I wrote:
>> Andrew Gierth writes:
>>> Isn't there a hidden assumption about endianness there?
Right, thanks.
>> Yeah, I was wondering about that too, but does anyone actually run
>> ARMs
I wrote:
> Andrew Gierth writes:
>> Isn't there a hidden assumption about endianness there?
> Yeah, I was wondering about that too, but does anyone actually run
> ARMs big-endian?
After a bit more thought ... we could remove the magic constant,
along with any
Thanks for your confirm Aleksander!
Also I am thinking of how to deal with complex
data structure like map, list, or set. I guess one possible
solution is to get raw data bytes for these data structure?
Otherwise it could be hard to wrap into a Datum.
2018-05-02 8:38 GMT-07:00 Aleksander Alekseev
Andrew Gierth writes:
> "Thomas" == Thomas Munro writes:
> + uint64 data = 42;
> Isn't there a hidden assumption about endianness there?
Yeah, I was wondering about that too, but does anyone actually run
ARMs
> "Thomas" == Thomas Munro writes:
+ uint64 data = 42;
Isn't there a hidden assumption about endianness there?
--
Andrew (irc:RhodiumToad)
On Wednesday, May 2, 2018, Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Wed, May 2, 2018 at 9:28 AM, Alvaro Herrera
> wrote:
> > > I admit I am more concerned about the possibility of bugs than I am
> > > about providing a
Robert Haas wrote:
> On Wed, May 2, 2018 at 9:28 AM, Alvaro Herrera
> wrote:
> > I admit I am more concerned about the possibility of bugs than I am
> > about providing a performance-related tool.
>
> I agree that if partition pruning has bugs, somebody might want to
>
>
> Sorry, but comparing lines at that state is just bullshit.
I totally disagree, proportions will be same in any case.
Most of the comments of converted tests are missing.
>
Add 100-500 lines? ok.
You detect like a third of the things that the old configure
> detected.
>
I tried to use
On 2018-05-03 09:42:49 +0900, Yuriy Zhuravlev wrote:
> 2018-05-03 9:32 GMT+09:00 Andres Freund :
> > Given that you don't have feature parity this just seems like trolling.
> >
>
> I have. I have some lacks with .po generation and documentation but all!
> other features same,
On Wed, May 2, 2018 at 9:28 AM, Alvaro Herrera wrote:
> I admit I am more concerned about the possibility of bugs than I am
> about providing a performance-related tool.
I agree that if partition pruning has bugs, somebody might want to
turn it off. On the other hand,
2018-05-03 9:32 GMT+09:00 Andres Freund :
> On 2018-05-03 09:29:32 +0900, Yuriy Zhuravlev wrote:
> > >
> > > I don't think that unsubstantiated hyperbole is the right way to
> > > approach the task of convincing the community to adopt the approach
> > > you prefer.
> >
> >
> >
On 2018-05-03 09:29:32 +0900, Yuriy Zhuravlev wrote:
> >
> > I don't think that unsubstantiated hyperbole is the right way to
> > approach the task of convincing the community to adopt the approach
> > you prefer.
>
>
> It's not a hyperbole it's fact and I even talked about it on conference.
>
>
> I don't think that unsubstantiated hyperbole is the right way to
> approach the task of convincing the community to adopt the approach
> you prefer.
It's not a hyperbole it's fact and I even talked about it on conference.
You should just compare all my cmake files with Makefile+.in+.m4 (and
On Wed, May 2, 2018 at 3:21 PM, Tom Lane wrote:
> Is there a reason why this record count needs to be int64 rather than
> plain int, and if so what? This code is not exactly well documented,
> but it looks to me like the number of records should be bounded by
> NBuffers,
On Wed, May 02, 2018 at 07:03:21PM -0400, Tom Lane wrote:
> It's only ~100 bytes per stack level. I think under normal loads
> nobody would notice. If you're worried about cross-transaction
> memory consumption, our various caches tend to be a lot worse.
Perhaps, that's one reason why people
On Thu, May 03, 2018 at 09:03:15AM +1200, Thomas Munro wrote:
> On Thu, May 3, 2018 at 8:01 AM, Tom Lane wrote:
> Build succeeded.
> 0 Warning(s)
> 0 Error(s)
>
> Huzzah!
Great work. This has been some time...
--
Michael
signature.asc
Description: PGP signature
On 3 May 2018 at 11:38, David G. Johnston wrote:
> Maybe "Partition Filtering" (I'm disliking selection, I'm thinking we must
> always select partitions)
I don't see why "Filtering" is any different from pruning, they both
imply removing something that was once there.
On Wed, May 2, 2018 at 4:06 PM, David Rowley
wrote:
> On 1 May 2018 at 21:44, Amit Langote
> wrote:
> > About the patch in general, it seems like the newly added documentation
> > talks about "Partition Pruning" as something that
On Thu, May 3, 2018 at 10:08 AM, Tom Lane wrote:
> I don't have any way to test this, but it looks plausible, so pushed.
>
> (I note you forgot to run autoheader, btw.)
Thanks!
--
Thomas Munro
http://www.enterprisedb.com
On 1 May 2018 at 21:44, Amit Langote wrote:
> About the patch in general, it seems like the newly added documentation
> talks about "Partition Pruning" as something that *replaces* constraint
> exclusion. But, I think "Partition Pruning" is not the thing that
>
Michael Paquier writes:
> With connection poolers letting the connections to the server be around
> for a long time, wouldn't it be an issue to let this much memory live
> longer than the transaction context? The deeper the stack, the more
> memory consumed, hence the more
On Wed, May 02, 2018 at 05:20:37PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > Yes, that was the idea. Here is an adjusted patch.
>
> Looks OK to me as far as the leak issue goes. I have no opinion on
> whether this is adequate in respect to
On Wed, May 2, 2018 at 5:44 PM, Robert Haas wrote:
> I don't think that unsubstantiated hyperbole is the right way to
> approach the task of convincing the community to adopt the approach
> you prefer. I don't see that any compelling evidence has been
> presented that a
Andres Freund writes:
> Now you could argue that we could just rewrite to non-recursive
> make. But that'd be nearly as much work as migrating to another
> buildsystem.
I'm sure it'd be a significant amount of work ... but it wouldn't require
redesigning any configuration or
Thomas Munro writes:
> On Thu, May 3, 2018 at 2:30 AM, Tom Lane wrote:
>> Do you really need the pg_crc32c_armv8_choose_dummy global variable?
> True. Of course I needed an interesting length too...
I don't have any way to test this, but it
On 2018-05-02 23:43:50 +0200, Hartmut Holzgraefe wrote:
> On 02.05.2018 17:44, Robert Haas wrote:
> > But having parallel make work better and more efficiently
> > and with fewer hard-to-diagnose failure modes would definitely be
> > nice.
>
> that's especially a thing I haven't seen in "our"
On 02.05.2018 17:44, Robert Haas wrote:
But having parallel make work better and more efficiently
and with fewer hard-to-diagnose failure modes would definitely be
nice.
that's especially a thing I haven't seen in "our" environment,
this was an area where autotools and cmake didn't really
Peter Eisentraut writes:
> Yes, that was the idea. Here is an adjusted patch.
Looks OK to me as far as the leak issue goes. I have no opinion on
whether this is adequate in respect to cleanup-after-error problems.
regards, tom lane
Thomas Munro writes:
> One more problem. whelk builds against Python 3.6 and says:
> c:\users\pgbf\appdata\local\programs\python\python36-32\include\pyconfig.h(174):
> warning C4142: benign redefinition of type
> (src/pl/plpython/plpy_elog.c)
>
On Thu, May 3, 2018 at 8:01 AM, Tom Lane wrote:
> Seems reasonable to me. Pushed, we'll see what the buildfarm thinks.
Build succeeded.
0 Warning(s)
0 Error(s)
Huzzah!
One more problem. whelk builds against Python 3.6 and says:
On 5/2/18 12:30, Tom Lane wrote:
> I'm not particularly. It seems impossible that _SPI_stack could grow
> faster than the machine's actual stack, which would mean (on typical
> setups) that you couldn't get more than perhaps 10MB of _SPI_stack
> before hitting a stack-overflow error. That's a
Thomas Munro writes:
> The only remaining warnings on those machines now come from the fact
> that our port_win32.h and Perl's XSUB.h both want to define macros to
> define macros for libc functions like mkdir etc. plperl.h already
> seems to deal with other
I've been going through compiler warnings from the buildfarm, and
I notice jacana is unhappy about this:
/* First line of the file is a record count. */
if (fscanf(file, "<<" INT64_FORMAT ">>\n", _elements) != 1)
It's entirely correct to complain, because we only guarantee that
On Wed, May 2, 2018 at 11:48 AM, Tom Lane wrote:
> tl;dr: we lack buildfarm coverage of CATCACHE_FORCE_RELEASE.
> This is probably bad. It might be okay to just add that to
> prion's configuration;
Will do that pronto.
cheers
andre
--
Andrew Dunstan
>If somebody produced a trace showing the buffer lookups in order
To get things moving, I've created a DTrace script that captures buffer
reads:
https://github.com/vlsi/pgsqlstat/blob/pgsqlio/pgsqlio
Is it something that can be used to capture live traces?
Sample output can be seen here:
On Wed, May 2, 2018 at 11:06 AM, Tom Lane wrote:
>> -1 from me. What about the case where only some tuples are massive?
>
> Well, what about it? If there are just a few wide tuples, then the peak
> memory consumption will depend on how many of those happen to be in memory
>
On Wed, May 2, 2018 at 10:43 AM, Heikki Linnakangas wrote:
> I'm not sure what you could derive that from, to make it less arbitrary. At
> the moment, I'm thinking of just doing something like this:
>
> /*
> * Minimum amount of memory reserved to hold the sorted tuples in
> *
On Wed, May 2, 2018 at 10:43 AM, Heikki Linnakangas wrote:
> Independently of this, perhaps we should put in special case in
> dumptuples(), so that it would never create a run with fewer than maxTapes
> tuples. The rationale is that you'll need to hold that many tuples in memory
On 02/05/18 19:41, Tom Lane wrote:
Robert Haas writes:
On Wed, May 2, 2018 at 11:38 AM, Heikki Linnakangas wrote:
To fix, I propose that we change the above so that we always subtract
tapeSpace, but if there is less than e.g. 32 kB of memory left after
-hackers,
Who is coordinating GSOC this year?
Thanks,
JD
--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc
PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
* Unless otherwise
On Wed, May 2, 2018 at 8:38 AM, Heikki Linnakangas wrote:
> With a small work_mem values, maxTapes is always 6, so tapeSpace is 48 kB.
> With a small enough work_mem, 84 kB or below in this test case, there is not
> enough memory left at this point, so we don't subtract
Peter Eisentraut writes:
> These two items are now outstanding:
>
> On 4/10/18 07:33, Dagfinn Ilmari Mannsåker wrote:
>> 2) jsonb scalar values are passed to the plperl function wrapped in not
>>one, but _two_ layers of references
>
> I don't understand this
Peter Eisentraut writes:
> On 5/1/18 11:42, Tom Lane wrote:
>> Peter Eisentraut writes:
>> That seems like an odd way to approach this. Why not just remove the
>> reset of _SPI_stack and _SPI_stack_depth, so as to subtract code
On Tue, May 1, 2018 at 6:37 PM, Peter Geoghegan wrote:
> This seems to be an old idea.
I'm not too surprised ... this area has been well-studied.
> I've always had a problem with the 8GB/16GB upper limit on the size of
> shared_buffers. Not because it's wrong, but because it's not
Hi!
Thank you for your attention on this subject. It's definitely right,
that documentation needs to be revised in these places.
On Wed, May 2, 2018 at 6:43 PM, Justin Pryzby wrote:
> index eabe2a9..e305de9 100644
> --- a/doc/src/sgml/config.sgml
> +++
On Wed, May 2, 2018 at 8:46 AM, Robert Haas wrote:
> On Wed, May 2, 2018 at 11:38 AM, Heikki Linnakangas wrote:
>> To fix, I propose that we change the above so that we always subtract
>> tapeSpace, but if there is less than e.g. 32 kB of memory left after
On 5/2/18 02:26, Amit Langote wrote:
> You're right. I think that's what you were also saying on the other
> thread, in reply to which I directed you to this thread. I very clearly
> missed that BEFORE ROW triggers are still disallowed.
fixed
--
Peter Eisentraut
Amit Langote writes:
> On 2018/05/02 0:33, Tom Lane wrote:
>> Amit Langote writes:
>>> While playing around with a -DCATCACHE_FORCE_RELEASE build, I noticed that
>>> stats_ext test failed with errors for multiple statements that
On Wed, May 2, 2018 at 11:38 AM, Heikki Linnakangas wrote:
> To fix, I propose that we change the above so that we always subtract
> tapeSpace, but if there is less than e.g. 32 kB of memory left after that
> (including, if it went below 0), then we bump availMem back up to 32
On Wed, May 2, 2018 at 11:43 AM, Justin Pryzby wrote:
> 2nd attempt
That looks like good English to me. I can't vouch for whether it's
technically correct.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Tue, May 1, 2018 at 8:12 PM, Yuriy Zhuravlev wrote:
>> That indeed would be an improvement, but maybe we could fix that specific
>> pain point without having to throw away twenty years worth of work?
>
> Indeed! Only a few thousands of lines of code can generate the whole
Hello Charles,
> Can I assume the data in thrift is always send inside a struct?
Sure!
> I think this question also valid for protobuf?
Right, pg_protobuf assumes that data is always a message which is an
equivalent of Thrift's struct.
--
Best regards,
Aleksander Alekseev
signature.asc
Hi,
On 05/02/2018 05:22 PM, Robert Haas wrote:
> On Tue, May 1, 2018 at 4:57 PM, Andres Freund wrote:
>> Robert, you added this as an open item. I don't think it's clear that
>> there's a bug here, and even less clear that it's something new for
>> v11. Am I understanding
On Tue, May 1, 2018 at 4:57 PM, Andres Freund wrote:
> Robert, you added this as an open item. I don't think it's clear that
> there's a bug here, and even less clear that it's something new for
> v11. Am I understanding that right? Should we close this open item?
Yeah, I
On Tue, May 1, 2018 at 10:30 PM, Justin Pryzby wrote:
> -When no tuples were deleted from the heap, B-tree indexes might still
> -be scanned during VACUUM cleanup stage by two
> -reasons. The first reason is that B-tree index contains deleted
>
On 23/04/18 14:17, John Naylor wrote:
I noticed one in the SPI docs and tried to look for more. The attached
patch is an attempt at removing the remaining references. The original
SPI example returned a uint64 as a signed int8 SQL type, so I'm not
sure if I handled that correctly.
Committed,
On 02.05.2018 16:22, Tom Lane wrote:
(-D? really?)
it's worse ... "cmake -L" only produces a alphabetically sorted list
of known -D settings, just listing the names without description.
That's so far behind from what
./configure --help
produces.
(And don't get me started on cmake-gui.
"David G. Johnston" writes:
> On Tue, May 1, 2018 at 12:08 PM, Robert Haas wrote:
>> That's probably true, but making dev, test, and production boxes
>> similar is generally good practice and users can do as much or as
>> little of it as they
Thomas Munro writes:
> Ahh, OpenSSL's armcap.c shows how to do this. You need to
> siglongjmp() out of there. Here's a patch that does it that way.
> Isn't this better?
Do you really need the pg_crc32c_armv8_choose_dummy global variable?
That seems pretty ugly.
On 30/04/18 22:00, Peter Geoghegan wrote:
On Mon, Apr 30, 2018 at 10:18 AM, Heikki Linnakangas wrote:
Perhaps that would be OK, if it was properly commented. But it's not
actually hard to make BufFileSize() work on shared files, too, so I think we
should do that.
I agree
Geoff Winkless writes:
> Being blunt, unless I've missed the point all the arguments I've read so
> far for cmake seem to be advantages for the developers, not the users. As
> developers who put in your time you are of course entitled to make your
> lives easier but I'm just
On Wed, May 2, 2018 at 1:07 AM, Amit Langote
wrote:
> Hi David.
>
> On 2018/05/02 8:18, David Rowley wrote:
> > On 1 May 2018 at 21:44, Amit Langote
> wrote:
> >
> > I re-read the patch and it still looks fine to me. I'm sure it
Robert Haas wrote:
> On Tue, Apr 24, 2018 at 5:59 PM, Alvaro Herrera
> wrote:
> > Constraint
> > exclusion was pretty easy to get wrong, hence the need for a separate
> > section, and I suppose the new partition pruning may be prey to the same
> > problems, so it seems
On Wed, May 2, 2018 at 11:56 AM, Amit Langote
wrote:
> But one could very well argue that BEFORE ROW triggers on the
> parent should run before performing the tuple routing and not be cloned to
> individual partitions, in which case the result would not have been
On 4/28/18, Tom Lane wrote:
> John Naylor writes:
>> Solution #1 - As alluded to in [1], turn the conversions into
>> pg_proc.dat and pg_conversion.dat entries. Teach genbki.pl to parse
>> pg_wchar.h to map conversion names to numbers.
>> Pros:
>> -likely
> On 2 May 2018 at 13:10, Michael Paquier wrote:
> On Wed, May 02, 2018 at 12:22:34PM +0200, Dmitry Dolgov wrote:
>> Recently I've heard people complaining that Postgres doesn't expose any
>> statistics about how many full page writes happened during some time
>> frame.
>
>
On Thu, Apr 5, 2018 at 12:00 AM, Thomas Munro
wrote:
> ... trying to figure out how to detect the instruction portably using SIGILL
> ...
Ahh, OpenSSL's armcap.c shows how to do this. You need to
siglongjmp() out of there. Here's a patch that does it that way.
On Wed, May 02, 2018 at 12:22:34PM +0200, Dmitry Dolgov wrote:
> Recently I've heard people complaining that Postgres doesn't expose any
> statistics about how many full page writes happened during some time
> frame.
pg_waldump --stats?
> I guess it can be implemented in a more effective and
(2018/05/02 15:45), Etsuro Fujita wrote:
(2018/05/02 10:10), Amit Langote wrote:
On 2018/05/02 6:09, Andres Freund wrote:
On 2018-05-01 13:41:32 -0400, Robert Haas wrote:
Committed.
Here is a small patch to remove a no-longer-needed cast in
postgresBeginForeignInsert().
Best regards,
On Wed, 2 May 2018 at 00:57, Yuriy Zhuravlev wrote:
> Hello Geoff!
>
> About cmake:
> 1. You can still use the binary build for your system.
> 2. You can still build Postgres from source and with old gcc, you need
> only install cmake (it's very easy) Only most modern
Hi,
Recently I've heard people complaining that Postgres doesn't expose any
statistics about how many full page writes happened during some time frame.
Indeed, I couldn't find any easy way to do so, and judging from my
understanding of xloginsert.c it actually can be done per database with the
Hi David.
On 2018/05/02 8:18, David Rowley wrote:
> On 1 May 2018 at 21:44, Amit Langote wrote:
>> About the patch in general, it seems like the newly added documentation
>> talks about "Partition Pruning" as something that *replaces* constraint
>> exclusion. But,
On 1 May 2018 at 21:04, Tom Lane wrote:
> I've pushed this patch into the 9.5 branch, so it should be possible to
> spin dory up on that branch now.
Thanks Tom!
Thanks everyone else for your input on the issue!
Regards, Haroon
--
Haroon
> On 2 May 2018, at 05:58, Peter Eisentraut
> wrote:
>
> On 5/1/18 12:27, Stas Kelvich wrote:
>> Clock-SI is described in [5] and here I provide a small overview, which
>> supposedly should be enough to catch the idea. Assume that each node runs
>> Commit
>>
On 05/01/2018 10:57 PM, Andres Freund wrote:
> Robert, you added this as an open item. I don't think it's clear that
> there's a bug here, and even less clear that it's something new for
> v11. Am I understanding that right? Should we close this open item?
Hi,
FIY this change is related to
02.05.2018 01:37, Peter Geoghegan пишет:
> On Tue, May 1, 2018 at 11:58 AM, Robert Haas wrote:
>> I agree that double-counting correlated accesses is a a problem, and I
>> agree that we probably want to do something about it. I am skeptical
>> that using wall-clock time is
(2018/05/02 10:10), Amit Langote wrote:
On 2018/05/02 6:09, Andres Freund wrote:
On 2018-05-01 13:41:32 -0400, Robert Haas wrote:
Committed.
Thank you.
Thanks for committing, Robert!
There's still an open items entry for this thread - has that been
resolved by this commit
Afaik, yes.
On 2018/05/02 14:17, Ashutosh Bapat wrote:
> On Tue, May 1, 2018 at 5:20 PM, Peter Eisentraut
> wrote:
>> On 4/26/18 05:03, Amit Langote wrote:
>>> On 2018/04/26 13:01, David Rowley wrote:
The attached small patch removes the mention that partitioned tables
On Wed, May 02, 2018 at 01:38:22PM +0900, Amit Langote wrote:
> Perhaps, I'm just repeating what's already been said, but I think it might
> be better to have the word "partitioned" in the message.
That's what Peter is pointing to upthread and what the v1 of upthread
was doing. I would tend to
82 matches
Mail list logo