2016-07-06 5:17 GMT+02:00 Peter Eisentraut :
> On 7/2/16 12:40 AM, Pavel Stehule wrote:
>
>> So ANSI SQL conform implementation of JSON support is still possible in
>> Postgres.
>>
>
> It is possible, but in this case I think it's not worth it. Our built-in
> stuff is significantly simpler and mo
On Tue, Jul 5, 2016 at 8:48 PM, Tom Lane wrote:
> Unfortunately the way I did (1) only works on systems with pmap; I'm not
> sure how to make it more portable.
I did a similar(ish) test which is admittedly not as exhaustive as
using pmap. I instrumented check_stack_depth() itself to keep track of
On 7/2/16 12:40 AM, Pavel Stehule wrote:
So ANSI SQL conform implementation of JSON support is still possible in
Postgres.
It is possible, but in this case I think it's not worth it. Our
built-in stuff is significantly simpler and more powerful and already in
widespread use.
It is worth ke
On 7/1/16 10:42 PM, Andreas Karlsson wrote:
On 07/01/2016 07:31 PM, Andres Freund wrote:
Yeah, but since when has the SQL standard adopted any existing
implementation's spelling of a feature? It seems to be politically
impossible.
Especially if nobody really lobbies on part of postgresql.
Ha
On 7/4/16 12:44 AM, Thomas Munro wrote:
ISO/IEC PDTR 19075-5 (Row Pattern Recognition) has also reached stage
30.60. Does anyone know what that one is about? Maybe something like
MATCH_RECOGNIZE in Oracle?
That's exactly what that is.
--
Peter Eisentraut http://www.2ndQuadrant.c
Robert wrote:
> I think there should probably be a test for
> all_visible_according_to_vm at the beginning of that so that we don't
> add more visibility map checks for pages where we already know the VM
> bit can't possibly be set.
Yes, that looks like a good idea after more screening of this co
Hi all,
I just bumped into a couple of things in visibilitymap.c:
- visibilitymap_clear clears all bits of a visibility map, its header
comment mentions the contrary
- The header of visibilitymap.c mentions correctly "a bit" when
referring to setting them, but when clearing, it should say that all
On 2016/07/02 0:32, Robert Haas wrote:
On Wed, Jun 29, 2016 at 1:38 AM, Ashutosh Bapat
wrote:
On Tue, Jun 28, 2016 at 12:52 PM, Etsuro Fujita
wrote:
Please find attached an updated version.
This looks good to me. Regression tests pass.
Committed. Thanks to Etsuro Fujita for the patch a
On Tue, Jul 5, 2016 at 6:02 PM, Kyotaro HORIGUCHI
wrote:
> Agreed. Grep'ing "system" in the source tree, I see no more place
> where needs the same fix.
Same conclusion here. I have added this stuff to the official patch tracker:
https://commitfest.postgresql.org/10/663/
I can as well produce pat
Hari,
> The queue can gets full in the case where the leader is processing is slow
> than the worker is producing tuples. In those scenarios, the worker waits
> until the the queue gets empty to place the new satisfied record.The worker
> gets awaken whenever the leader finishes reading the data f
Hi all,
Attached patch fixes the typo in jsonb.c
Please find it.
Regards,
--
Masahiko Sawada
diff --git a/src/backend/utils/adt/jsonb.c b/src/backend/utils/adt/jsonb.c
index 256ef80..ab46823 100644
--- a/src/backend/utils/adt/jsonb.c
+++ b/src/backend/utils/adt/jsonb.c
@@ -1849,7 +1849,7 @@ json
On Wed, Jul 6, 2016 at 10:57 AM, Tatsuo Ishii wrote:
> Hi,
>
> Does anybody know what will happen if tuple queue is full, which is
> used by the parallel leader and workers? In my understanding memory
> used for the queue is a dynamic shared memory and it could be full.
The queue can gets full in
Hi,
Does anybody know what will happen if tuple queue is full, which is
used by the parallel leader and workers? In my understanding memory
used for the queue is a dynamic shared memory and it could be full.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_
Peter Geoghegan writes:
> On Tue, Jul 5, 2016 at 12:00 PM, Robert Haas wrote:
>> I think that it is not worth mentioning specifically for
>> temp_file_limit; to me that seems to be a hole with no bottom. We'll
>> end up arguing about which GUCs should mention it specifically and
>> there will be
On Tue, Jul 5, 2016 at 12:58 PM, Tom Lane wrote:
> Perhaps we could change the wording of temp_file_limit's description
> from "space that a session can use" to "space that a process can use"
> to help clarify this?
That's all that I was looking for, really.
--
Peter Geoghegan
--
Sent via pg
Robert Haas writes:
> On Tue, Jul 5, 2016 at 11:54 AM, Tom Lane wrote:
>> I'm pretty nervous about reducing that materially without any
>> investigation into how much of the slop we actually use.
> To me it seems like using anything based on stack_rlimit/2 is pretty
> risky for the reason that y
CharSyam wrote:
> Yes, Some typos problems, It is hard to figure them out.
> But in this patch, guranteed is just misspelling of guaranteed.
I agree with Robert: the sentence as a whole makes no sense:
* We need to check all possible distances, so reset Lpos
* to guarant
On Tue, Jul 5, 2016 at 11:54 AM, Robert Haas wrote:
> On Sat, Jul 2, 2016 at 12:17 PM, CharSyam wrote:
> > I fixed typos. and attached patch for this.
> > Thanks.
> >
> > I only changed comments only in src/backend/utils/adt/tsvector_op.c
>
> Well, that's definitely a typo. However, typo or no
On Tue, Jul 5, 2016 at 11:54 AM, Tom Lane wrote:
> Greg Stark writes:
>> Poking at NetBSD kernel source it looks like the default ulimit -s
>> depends on the architecture and ranges from 512k to 16M. Postgres
>> insists on max_stack_depth being STACK_DEPTH_SLOP -- ie 512kB -- less
>> than the uli
On Tue, Jul 5, 2016 at 12:00 PM, Robert Haas wrote:
> I think that it is not worth mentioning specifically for
> temp_file_limit; to me that seems to be a hole with no bottom. We'll
> end up arguing about which GUCs should mention it specifically and
> there will be no end to it.
I don't think t
On Tue, Jul 5, 2016 at 1:58 PM, Peter Geoghegan wrote:
> On Tue, Jul 5, 2016 at 7:45 AM, Robert Haas wrote:
>> Since Peter doesn't seem in a hurry to produce a patch for this issue,
>> I wrote one. It is attached. I'll commit this in a day or two if
>> nobody objects.
>
> Sorry about the delay.
> "Joshua" == Joshua D Drake writes:
Joshua> Is it intentional that insert and delete are allowed and select
Joshua> is not or is it an oversight?
Just an artifact of SELECT being fully reserved (needed for (SELECT ...)
syntax to work right) while INSERT and DELETE are unreserved.
--
And
Hey,
For grins while writing up an example on RLS for a client I tried the
following:
policy=# create role insert;
CREATE ROLE
policy=# create role select;
ERROR: syntax error at or near "select"
LINE 1: create role select;
^
policy=# create role delete;
CREATE ROLE
Is i
On Tue, Jul 5, 2016 at 7:45 AM, Robert Haas wrote:
> Since Peter doesn't seem in a hurry to produce a patch for this issue,
> I wrote one. It is attached. I'll commit this in a day or two if
> nobody objects.
Sorry about the delay.
Your patch seems reasonable, but I thought we'd also want to c
Yes, Some typos problems, It is hard to figure them out.
But in this patch, guranteed is just misspelling of guaranteed.
Thanks.
2016-07-06 0:54 GMT+09:00 Robert Haas :
> On Sat, Jul 2, 2016 at 12:17 PM, CharSyam wrote:
> > I fixed typos. and attached patch for this.
> > Thanks.
> >
> > I only
On Sat, Jul 2, 2016 at 12:17 PM, CharSyam wrote:
> I fixed typos. and attached patch for this.
> Thanks.
>
> I only changed comments only in src/backend/utils/adt/tsvector_op.c
Well, that's definitely a typo. However, typo or no typo, it's hard
for me to figure out with any certainty what that s
Greg Stark writes:
> Poking at NetBSD kernel source it looks like the default ulimit -s
> depends on the architecture and ranges from 512k to 16M. Postgres
> insists on max_stack_depth being STACK_DEPTH_SLOP -- ie 512kB -- less
> than the ulimit setting making it impossible to start up on
> archit
On Wed, Jun 29, 2016 at 11:00 AM, Amit Khandekar wrote:
> We may also want to consider handling abstract events such as
> "tuples-are-available-at-plan-node-X".
>
> One benefit is : we can combine this with batch processing. For e.g. in case
> of an Append node containing foreign scans, its parent
On Fri, Jul 1, 2016 at 10:20 PM, Amit Kapila wrote:
Right, something like that. I think Andres actually wants something
like this in 9.6, and I'm inclined to think it might be a good idea,
too. I think there should probably be a test for
all_visible_according_to_vm at the beg
On Tue, Jun 21, 2016 at 8:15 AM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 11:01 PM, Tom Lane wrote:
>> Peter Geoghegan writes:
>>> On Wed, May 18, 2016 at 3:40 AM, Robert Haas wrote:
What I'm tempted to do is trying to document that, as a point of
policy, parallel query in 9.6 use
On Mon, Jul 4, 2016 at 5:44 PM, Masahiko Sawada wrote:
> On Sat, Jul 2, 2016 at 12:34 PM, Amit Kapila wrote:
>> On Fri, Jul 1, 2016 at 7:52 PM, Masahiko Sawada
>> wrote:
>>> On Fri, Jul 1, 2016 at 11:12 AM, Amit Kapila
>>> wrote:
Why do you think IndexOnlyScan will return wrong resu
On Sun, Jul 3, 2016 at 6:46 PM, Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> On Sun, Jul 3, 2016 at 1:14 PM, Tom Lane wrote:
You mentioned that you'll be on vacation for much of July. If you like,
I will take this open item off your hands, since I'll be around and can
de
On 07/05/2016 11:13 AM, Victor Wagner wrote:
On Fri, 1 Jul 2016 02:27:03 +0200
Andreas Karlsson wrote:
0003-Remove-OpenSSL-1.1-deprecation-warnings.patch
Silence all warnings. This commit changes more things and is not
necessary for getting PostgreSQL to build against 1.1.
This patch breaks
Poking at NetBSD kernel source it looks like the default ulimit -s
depends on the architecture and ranges from 512k to 16M. Postgres
insists on max_stack_depth being STACK_DEPTH_SLOP -- ie 512kB -- less
than the ulimit setting making it impossible to start up on
architectures with a default of 512k
Here is a patch with updated WAL behavior.
I'm not certain about MAXALIGN for size of appended tuple. Currently
if anyone calls PageIndexTupleOverwrite() with unalligned tuple it
will ereport(ERROR).
I suspect that it should allign size instead.
Also I suspect that PageIndexTupleOverwrite() shoul
Hello,
Thanks to emails, we have achieved what we wanted. This is what we’ve done:
Compilation (for 32 bit version, initdb with locale=C):
CFLAGS="-mx32 -fexcess-precision=standard -O2"
CXXFLAGS="-mx32"
configure --without-zlib --disable-float8-byval --without-readline
--host=x86_64-linux-gnux3
On Tue, Jul 5, 2016 at 5:22 AM, Andreas 'ads' Scherbaum <
adsm...@wars-nicht.de> wrote:
> On 05.07.2016 04:33, David G. Johnston wrote:
>
>> On Mon, Jul 4, 2016 at 8:39 PM, Andreas 'ads' Scherbaum
>> mailto:adsm...@wars-nicht.de>>wrote:
>>
>> On 04.07.2016 18:37, Pavel Stehule wrote:
>>
>>
>>
On 05.07.2016 04:33, David G. Johnston wrote:
On Mon, Jul 4, 2016 at 8:39 PM, Andreas 'ads' Scherbaum
mailto:adsm...@wars-nicht.de>>wrote:
On 04.07.2016 18:37, Pavel Stehule wrote:
I don't know if the name "strict" is best, but the name
"validate" is
not good too. C
On 05.07.2016 06:05, Pavel Stehule wrote:
2016-07-05 2:39 GMT+02:00 Andreas 'ads' Scherbaum mailto:adsm...@wars-nicht.de>>:
On 04.07.2016 18:37, Pavel Stehule wrote:
I don't know if the name "strict" is best, but the name
"validate" is
not good too. Current to_dat
On Fri, 1 Jul 2016 02:27:03 +0200
Andreas Karlsson wrote:
> 0003-Remove-OpenSSL-1.1-deprecation-warnings.patch
>
> Silence all warnings. This commit changes more things and is not
> necessary for getting PostgreSQL to build against 1.1.
This patch breaks feature, which exists in PostgreSQL si
Hello,
At Tue, 5 Jul 2016 13:44:08 +0900, Michael Paquier
wrote in
> On Mon, Jul 4, 2016 at 4:44 PM, Michael Paquier
> wrote:
> > And as is the command built for zic.exe in Install.pm, no? $target is
> > normally an absolute path per the call of Install().
>
> Attached is the patch I have in
On Tue, Jul 5, 2016 at 10:06 AM, Michael Paquier
wrote:
> On Mon, Jul 4, 2016 at 12:54 PM, Michael Paquier
> wrote:
> > As I am coming back into that, I would as well suggest do the
> > following, that the current set of patches is clearly missing:
> > - Put the HMAC infrastructure stuff of pgcr
Andreas Karlsson wrote:
> On 07/04/2016 10:55 PM, Pavel Stehule wrote:
>> 2016-07-04 22:15 GMT+02:00 Andreas Karlsson wrote:
>>> I do not see a clear conclusion in the linked threads. For example
>>> Bruce calls it a bug in one of the emails
>>> (https://www.postgresql.org/message-id/201107200103.p
On Mon, Jul 4, 2016 at 12:54 PM, Michael Paquier
wrote:
> As I am coming back into that, I would as well suggest do the
> following, that the current set of patches is clearly missing:
> - Put the HMAC infrastructure stuff of pgcrypto into src/common/. It
> is a bit a shame to not reuse what is cu
44 matches
Mail list logo
