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) -
> https://github.com/postgrespro/sqljson/
On 2017-08-18 20:51, Robert Haas wrote:
> On Fri, Aug 18, 2017 at 4:39 AM, Piotr Stefaniak
> wrote:
>> On 2017-08-17 11:24, Simon Riggs wrote:
>>> Your suggestion of "furthest" is already the default behaviour.
>>>
>>> Why are you using 'no
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 time
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 long
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, be
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
On 2017-06-17 00:02, Tom Lane wrote:
> Piotr Stefaniak 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, removing
>>> another im
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 code to do it.
>
>> F
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 ab
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
>>
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
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
inde
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 of
>>> * 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 decl
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
> * 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 i
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~
On 2017-05-18 18:13, Tom Lane wrote:
> Piotr Stefaniak 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/pstef/freebsd_indent and tested
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 decis
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
> t
On 2017-05-17 22:11, Tom Lane wrote:
> Piotr Stefaniak 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 my indent as the base
>> f
On 2017-05-17 20:31, Tom Lane wrote:
> Piotr Stefaniak 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 largely ignored his efforts
>
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 ignored
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
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 about
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
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 disabl
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
>> @@ -
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 diagno
On 2016-05-25 21:13, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 22, 2016 at 4:16 PM, Piotr Stefaniak
>> wrote:
>>> I think I've managed to improve pg_bsd_indent's handling of two types of
>>> cases.
>
>> Wow, that seems
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 =
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. Howeve
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
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 o
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 f
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.
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 pg_bsd_inde
On 2016-05-17 19:05, Tom Lane wrote:
Michael Paquier writes:
On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak
wrote:
-toc_bytes = offsetof(shm_toc, toc_entry) +nentry * sizeof(shm_toc_entry)
+toc_bytes = offsetof(shm_toc, toc_entry) + nentry * sizeof(shm_toc_entry
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
Date: Thu Apr 28 18:36:16 2016 +0200
Cosmetic improvements
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 cla
Added a fix for src/backend/storage/ipc/shm_mq.c:shm_mq_receive.
commit 936c7268b61460deb201b9e6bbfb60ab5258ec87
Author: Piotr Stefaniak
Date: Thu Apr 28 18:35:43 2016 +0200
Don't pass null pointers to functions that require the pointers to be non null.
diff --git a/contrib/pgcrypto
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
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: "buf
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
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 include
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 what's
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, some
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
LANGUAG
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 t
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;
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
impleme
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 int
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 d
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
On 07/08/2014 17:53, geohas wrote:
> make CFLAGS=-O0 was it.
>
> now gdb doesn't print .
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 subscription:
http://www.
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: getsockop
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 "cl
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 in our core headers. Besides
which, as noted in the page itself, most modern compi
> +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
59 matches
Mail list logo