Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

+myextra = (int *) malloc(sizeof(int)); Please consider not casting malloc(). See http://c-faq.com/malloc/mallocnocast.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

On 03/22/2014 04:00 PM, Tom Lane wrote: That argument is entirely bogus, as it considers only one possible way in which the call could be wrong; a way that is of very low probability in PG usage, since we include stdlib.h in our core headers. Besides which, as noted in the page itself, most

Re: [HACKERS] Review: plpgsql.extra_warnings, plpgsql.extra_errors

On 03/22/2014 04:00 PM, Tom Lane wrote: On the other side, coding with the explicit cast helps guard against far more dangerous coding errors, which the compiler will*not* help you with. What if myextra is actually of type int64 *? Indeed, neither gcc -Wall -Wextra -std=c89 -pedantic nor clang

[HACKERS] Keepalive-related socket options under FreeBSD 9, 10

Since upgrading FreeBSD from 8 to 9, I've noticed the following messages showing up in logs when a connection with pgAdmin3 is made: LOG: getsockopt(TCP_KEEPCNT) failed: Protocol not available STATEMENT: SELECT setting FROM pg_settings WHERE name IN ('autovacuum', 'track_counts') LOG:

Re: [HACKERS] How to use Makefile - pgxs without gcc -O2 ?

On 07/08/2014 17:53, geohas wrote: make CFLAGS=-O0 was it. now gdb doesn't print Value optimized out. If you're using GCC 4.8 or later, consider using it with -Og for that kind of builds. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] [PATCH] Add STRICT to some regression test C functions.

On 01/09/2016 12:05 AM, Andreas Seltenreich wrote: Maybe someone can sneak this patch in? Exactly this is done by a part of another patch, by Michael Paquier, that he sent to an off-list thread. Michael had asked for feedback there, but I didn't have the time to test the patch. Just from

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 21:13, Tom Lane wrote: I'd love to see a fix for its brain damage around function pointer typedef formatting, too. Show me a few examples and I'll look into it. I'm excited about this too, not least because it suggests that maybe bsdindent isn't quite as opaque as it appears.

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 21:13, Tom Lane wrote: Assuming this patch withstands more careful review, we will need to think about project policy for how/when to apply such fixes. I discovered yesterday that Bruce Evans had done the fix for sizeof in their fork of indent(1) in 2004 (r125623 [1]). The core

Re: [HACKERS] A couple of cosmetic changes around shared memory code

On 2016-05-16 21:40, Piotr Stefaniak wrote: Hello, while investigating the shm_mq code and its testing module I made some cosmetic improvements there. You can see them in the attached diff file. Revised patch attached. commit 3ff1afa84e4bc22f153c876e2f0588327a8a004e Author: Piotr Stefaniak

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-27 08:13, Piotr Stefaniak wrote: I'm trying to see if FreeBSD indent can successfully do pg_bsd_indent's job. So far I had to fix one thing, which is not adding a space after a cast operator, for which they added no option to turn it off. Currently I'm fighting one other bug, but I

Re: [HACKERS] Releasing in September

On 01/26/2016 02:09 AM, Peter Eisentraut wrote: > On 1/25/16 2:48 AM, Torsten Zühlsdorff wrote: >> In FreeBSD for example there is an online tool for review >> (http://review.freebsd.org) which was opened to public. There you can >> review any code, left comments in the parts you wanted, submit

Re: [HACKERS] Proposal: Trigonometric functions in degrees

On 01/31/2016 01:23 PM, Michael Paquier wrote: Per IEEE 754, division by 0 for a double results in Nan or +/-Inf, so that's actually correct. I didn't know that. I guess that in practice that is OK and the case is closed. Interestingly to me, that assumption appears to rely on the C

Re: [HACKERS] Proposal: Trigonometric functions in degrees

These changes from 65abaab547a5758b0d6d92df4af1663bb47d545f - result = sign * cosd_q1(arg1) / sind_q1(arg1); + result = sign * ((cosd_q1(arg1) / sind_q1(arg1)) / cot_45); and - result = sign * sind_q1(arg1) / cosd_q1(arg1); + result = sign * ((sind_q1(arg1) / cosd_q1(arg1)) / tan_45); both

Re: [HACKERS] [COMMITTERS] pgsql: Allow Pin/UnpinBuffer to operate in a lockfree manner.

On 2016-04-12 07:00, Andres Freund wrote: On 2016-04-12 00:32:13 -0400, Tom Lane wrote: I wrote: This commit has broken buildfarm member gaur, and no doubt pademelon will be equally unhappy once it catches up to HEAD. Spoke too soon, actually: pademelon did not get as far as initdb. cc:

[HACKERS] Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c

Hi, using sqlsmith and UBSan I have found these two division by zero errors: src/backend/optimizer/plan/planner.c:4846 /* Convert absolute # of tuples to a fraction; no need to clamp */ if (tuple_fraction >= 1.0) { tuple_fraction /= best_path->rows;

Re: [HACKERS] Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c

On 2016-03-26 19:29, Piotr Stefaniak wrote: I'm not saying this is necessarily a bug since the whole function deals with floats, but perhaps it's interesting to note that ndistinct can be 0 in src/backend/utils/adt/selfuncs.c:estimate_hash_bucketsize: On the exact same note, something like

Re: [HACKERS] Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c

I'm not saying this is necessarily a bug since the whole function deals with floats, but perhaps it's interesting to note that ndistinct can be 0 in src/backend/utils/adt/selfuncs.c:estimate_hash_bucketsize: /* * Initial estimate of bucketsize fraction is 1/nbuckets as long as

Re: [HACKERS] AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

On 2016-03-27 16:40, Tom Lane wrote: Hm. I would argue that it should have rejected CAST(NULL AS ANYARRAY). That's a pseudotype and so there should never be an actual value of that type, not even a null value. I'm a little confused about what you mean here. I thought reject was exactly

[HACKERS] AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

Hi, using sqlsmith I found a way to induce an AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval() for assert-enabled builds. It boils down to creating a function and calling it like this: CREATE FUNCTION bad_argument_assert(anyarray, integer) RETURNS anyarray

[HACKERS] Small fix: avoid passing null pointers to memcpy()

Hello, from running the regression test suite (including TAP tests) and also sqlsmith, I've got a couple of places where UBSan reported calls to memcpy() with null pointer passed as either source or destination. Patch attached. diff --git a/contrib/pgcrypto/px.c b/contrib/pgcrypto/px.c index

Re: [HACKERS] Two division by 0 errors in optimizer/plan/planner.c and optimizer/path/costsize.c

On 2016-03-28 11:33, Aleksander Alekseev wrote: Hello, Piotr. Thanks for report. But I'm having some difficulties reproducing issues you described. Oh, if you want backtraces then either set a conditional breakpoint or add your own Assert like I did. Also it would be a good idea to

Re: [HACKERS] A couple of cosmetic changes around shared memory code

On 2016-05-17 19:05, Tom Lane wrote: Michael Paquier <michael.paqu...@gmail.com> writes: On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak <postg...@piotr-stefaniak.me> wrote: -toc_bytes = offsetof(shm_toc, toc_entry) +nentry * sizeof(shm_toc_entry) +toc_bytes = offs

[HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

Hello, I think I've managed to improve pg_bsd_indent's handling of two types of cases. The first are like in this example: - hashp = (HTAB *) DynaHashAlloc(sizeof(HTAB) + strlen(tabname) +1); + hashp = (HTAB *) DynaHashAlloc(sizeof(HTAB) + strlen(tabname) + 1); Pristine

[HACKERS] A couple of cosmetic changes around shared memory code

Hello, while investigating the shm_mq code and its testing module I made some cosmetic improvements there. You can see them in the attached diff file. commit 0e202cb6e0eca2e7fb3e1353b550f3d2ace9680e Author: Piotr Stefaniak <postg...@piotr-stefaniak.me> Date: Thu Apr 28 18:36:16 2016

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

Added a fix for src/backend/storage/ipc/shm_mq.c:shm_mq_receive. commit 936c7268b61460deb201b9e6bbfb60ab5258ec87 Author: Piotr Stefaniak <postg...@piotr-stefaniak.me> Date: Thu Apr 28 18:35:43 2016 +0200 Don't pass null pointers to functions that require the pointers to be non null.

Re: [HACKERS] [BUGS] Breakage with VACUUM ANALYSE + partitions

On 2016-05-05 09:32, Fabien COELHO wrote: I note that C99 specifically mentions this as something a compiler might warn about: [...] Indeed. Neither gcc nor clang emit such warnings... but they might some day, which would be a blow for my suggestion! For what it's worth, newer versions of

Re: [HACKERS] Small fix: avoid passing null pointers to memcpy()

On 2016-04-03 09:24, Piotr Stefaniak wrote: from running the regression test suite (including TAP tests) and also sqlsmith, I've got a couple of places where UBSan reported calls to memcpy() with null pointer passed as either source or destination. Patch attached. Patch updated. Since

Re: [HACKERS] More parallel-query fun

On 2016-06-16 20:14, Tom Lane wrote: As of HEAD you can exercise quite a lot of parallel query behavior by running the regression tests with these settings applied: force_parallel_mode = regress max_parallel_workers_per_gather = 2-- this is default at the moment min_parallel_relation_size =

Re: [HACKERS] A couple of cosmetic changes around shared memory code

On 2016-06-29 18:58, Robert Haas wrote: This code predates be7558162acc5578d0b2cf0c8d4c76b6076ce352, prior to which proc_exit(0) forced an immediate, unconditional restart. It's true that, given that commit, changing this code to do proc_exit(0) instead of proc_exit(1) would be harmless.

Re: [HACKERS] pg_bsd_indent - improvements around offsetof and sizeof

On 2016-05-25 21:13, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, May 22, 2016 at 4:16 PM, Piotr Stefaniak >> <postg...@piotr-stefaniak.me> wrote: >>> I think I've managed to improve pg_bsd_indent's handling of two types of >>

Re: [HACKERS] [GENERAL] C++ port of Postgres

On 2016-08-16 18:33, Robert Haas wrote: > It wouldn't be that much work to maintain, either: we'd > just set up some buildfarm members that compiled using C++ and when > they turned red, we'd go fix it. I think that there exist subtle differences between C and C++ that without compile-time

Re: [HACKERS] Possible spelling fixes

On 2017-02-06 10:40, Heikki Linnakangas wrote: > On 02/06/2017 04:50 AM, Josh Soref wrote: >> NUL-terminated -> NULL-terminated > > When we're talking about NUL-terminated strings, NUL refers to the NUL > ASCII character. NULL usually refers to a NULL pointer. We're probably > not consistent

[HACKERS] pg_bsd_indent: implement -lps ("leave preprocessor space")

Hello, this is a patch that Andres asked me for. It makes pg_bsd_indent leave preprocessor space alone, as in this example: #if 0 # if 0 # if 0 # error # endif # endif #else # line 7 #endif diff -ur pg_bsd_indent/args.c pg_bsd_indent_patched/args.c --- pg_bsd_indent/args.c

Re: [HACKERS] Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

On 2016-08-19 23:55, Tom Lane wrote: > I think you are failing to understand Heikki's point. There is no way > we are committing the change depicted above, because (1) it will mask more > bugs than it fixes; (2) it's an enormously expensive way to fix anything; > and (3) it will effectively

Re: [HACKERS] Re: PROPOSAL: make PostgreSQL sanitizers-friendly (and prevent information disclosure)

On 2016-08-18 20:02, Heikki Linnakangas wrote: > On 03/22/2016 03:27 PM, Aleksander Alekseev wrote: >> diff --git a/src/backend/utils/mmgr/aset.c >> b/src/backend/utils/mmgr/aset.c >> index d26991e..46ab8a2 100644 >> --- a/src/backend/utils/mmgr/aset.c >> +++ b/src/backend/utils/mmgr/aset.c >> @@

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

On 2016-09-28 00:02, Andres Freund wrote: > On 2015-09-07 17:05:10 +0100, Greg Stark wrote: >> I feel like I remember hearing about this before but I can't find any >> mention of it in my mail archives. It seems pretty simple to add >> support for LLVM's Address Sanitizer (asan) by using the hooks

[HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

First I'll describe my setup just to give you some context. If anyone would like to discuss my ideas or propose their own ideas for discussion, let's do so on -ADMIN or -GENERAL. I have multiple production database clusters which I want to make backups of. Restoring from plain dumps takes too

[HACKERS] The error message "sorry, too many clients already" is imprecise

I recently started getting the "sorry, too many clients already" error. There are currently four places that can generate it, but fortunately log_error_verbosity was set to verbose so I was able to see that in this case the warning was generated by proc.c:InitProcess(). But it's still not much,

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On 2017-08-18 20:51, Robert Haas wrote: > On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak > <postg...@piotr-stefaniak.me> wrote: >> On 2017-08-17 11:24, Simon Riggs wrote: >>> Your suggestion of "furthest" is already the default behaviour. >>> &

Re: [HACKERS] recovery_target_time = 'now' is not an error but still impractical setting

On 2017-08-17 11:24, Simon Riggs wrote: > Your suggestion of "furthest" is already the default behaviour. > > Why are you using 'now'? Why would you want to pick a randomly > selected end time? The idea in both cases was to stop the recovery in order to prevent the standby from selecting new

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-05-17 20:31, Tom Lane wrote: > Piotr Stefaniak <postg...@piotr-stefaniak.me> writes: >> On 2017-05-17 19:16, Alvaro Herrera wrote: >>> We have someone who has studied the BSD indent code and even sent us >>> patches to fix quite a few bugs, but we've large

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

On 2017-05-17 19:16, Alvaro Herrera wrote: > Tom Lane wrote: > >> Changing the pgindent rule for such cases sounds kind of promising, >> but will anyone pursue it? > > We have someone who has studied the BSD indent code and even sent us > patches to fix quite a few bugs, but we've largely

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

On 2017-05-17 17:55, Peter Eisentraut wrote: > On 5/17/17 10:14, Tom Lane wrote: >> What I was concerned about was that pgindent will reindent the second >> line so that it's impossible to tell whether the spacing is correct. > > pgindent moving string continuations to the left is a completely >

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-05-17 22:11, Tom Lane wrote: > Piotr Stefaniak <postg...@piotr-stefaniak.me> writes: >> The third significant issue I kept in my mind was to shift some >> work-arounds from pgindent to indent. > > Yeah, I was wondering about that too. > >> When I use m

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-05-22 01:50, Tom Lane wrote: > Being lazy, I just wiped my copy and re-cloned, but it still seems the > same as before ... last commit on the pass3 branch is from Mar 4. > What branch should I be paying attention to? Sorry for the trouble, this is because I interactively git-rebased it in

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-05-21 03:00, Tom Lane wrote: > I wrote: >> Also, I found two places where an overlength comment line is simply busted >> altogether --- notice that a character is missing at the split point: > > I found the cause of that: you need to apply this patch: > > --- freebsd_indent/pr_comment.c~

Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.

On 2017-05-18 18:13, Tom Lane wrote: > Piotr Stefaniak <postg...@piotr-stefaniak.me> writes: >> That, I assume, would be me. Coincidentally, I'm about to push my fixes >> upstream (FreeBSD). Before that happens, my changes can be obtained from >> https://github.com/pste

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-05-17 23:46, Tom Lane wrote: > I hacked around that by putting back a detab/entab step at the end > using the existing subroutines in pgindent. That about halved the > size of the diff, but it's still too big to post. Much of what > I'm seeing with this version is randomly different

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-06-13 18:22, Tom Lane wrote: > The Makefile is still BSD-ish of course, but I think > we'll just agree to disagree there. For compiling indent under Linux I use bmake(1). I have no problem with including a Makefile for GNU Make in my repository. As I understand it, there will be a copy

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-06-13 22:23, Tom Lane wrote: > I could not find any places where reverting this change made the > results worse, so I'm unclear on why you made it. I must admit I'm a bit confused about why it's not fixed yet, but I'll have to analyze that later this week. But the idea was to convince

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On 2017-06-16 21:56, Tom Lane wrote: > One other thing I'd like to do while we're changing this stuff is > to get rid of the need for entab/detab. Right now, after doing > all the other work, my copy of pgindent is running the code through > detab and then entab so as to match the old decisions

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On 2017-06-16 20:11, Tom Lane wrote: > Andres Freund writes: >> On 2017-06-16 13:44:30 -0400, Bruce Momjian wrote: >>> Yes, it is all about <80 column output. The current pgindent does >>> everything possible to accomplish that --- the question is whether we >>> want uglier

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On 2017-06-17 00:02, Tom Lane wrote: > Piotr Stefaniak <postg...@piotr-stefaniak.me> writes: >> On 2017-06-16 21:56, Tom Lane wrote: >>> Unless Piotr objects, I propose to add another switch to bsdindent >>> that selects this behavior, and then we can drop entab

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On 2017-06-17 21:55, Tom Lane wrote: > I spent some time looking into this. I reverted your commits > 198457848ae5c86bec3336a9437dd5aa30f480c2 (Replace err.h functions with > standard C equivalents) and fb10acb040b90bdcbad09defd303363db29257d1 > (Remove inclusion of sys/cdefs.h) locally and tried

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

>>> * the comments get formatted differently for -ts4 than -ts8 Still haven't put any thought into it, so I still don't know what to do here. >>> * extra spacing getting inserted for fairly long labels I think the fix is as easy as not producing the space. I committed that. >>> * some enum

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-06-14 19:31, Tom Lane wrote: > Does that test case pass for you? No, I broke it recently. Sorry. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

On 2017-06-14 17:05, Bruce Momjian wrote: > On Wed, Jun 14, 2017 at 10:38:40AM -0400, Tom Lane wrote: >> btw, I was slightly amused to notice that this version still calls itself >> >> $ indent -V >> pg_bsd_indent 1.3 >> >> Don't know what you plan to do with that program name, but we certainly >>

Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)

> * const unsigned(*TABLE_index)[2]; > * OffsetNumber(*findChildPtr) (GinBtree, Page, BlockNumber, OffsetNumber); > * an overlength comment line is simply busted altogether Fixed and pushed to my github repository. Note that indent won't wrap long lines like links or paths anymore. But obviously

Re: [HACKERS] SQL/JSON in PostgreSQL

On 2017-02-28 20:08, Oleg Bartunov wrote: > Attached patch is an implementation of SQL/JSON data model from SQL-2016 > standard (ISO/IEC 9075-2:2016(E)) I've faintly started looking into this. > We created repository for reviewing (ask for write access) - >