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
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 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
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 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
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 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 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:
>>
>>
>>
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
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
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
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
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 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 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 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 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
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 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
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 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
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
> "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
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.
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 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 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
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
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
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
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
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_
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 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
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
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
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
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
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
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
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/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 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
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
44 matches
Mail list logo
