On Wed, May 09, 2018 at 02:01:26PM +0900, Amit Langote wrote:
> On 2018/05/09 11:31, David Rowley wrote:
>> On 9 May 2018 at 14:29, Amit Langote wrote:
>>> On 2018/05/09 11:20, Michael Paquier wrote:
While looking at this code, is there any reason to not make
gen_partprune_steps static?
On 2018/05/09 11:31, David Rowley wrote:
> On 9 May 2018 at 14:29, Amit Langote wrote:
>> On 2018/05/09 11:20, Michael Paquier wrote:
>>> While looking at this code, is there any reason to not make
>>> gen_partprune_steps static? This is only used in partprune.c for now,
>>> so the intention is t
Hi David.
Thanks for addressing my comments.
On 2018/05/07 15:00, David Rowley wrote:
> v2 patch is attached.
Looks good to me.
Thanks,
Amit
On Tue, May 8, 2018 at 5:27 PM, Robert Haas wrote:
> On Mon, May 7, 2018 at 11:34 PM, Amit Kapila wrote:
>> I think we can cover InitPlan and Subplans that can be parallelized in
>> a separate section "Parallel Subplans" or some other heading. I think
>> as of now we have enabled parallel subpla
Thanks for reviewing again.
On 9 May 2018 at 01:32, Justin Pryzby wrote:
> On Mon, May 07, 2018 at 06:00:59PM +1200, David Rowley wrote:
>> Many thanks for reviewing this.
>
> 2nd round - from the minimalist department:
>
> +partitions which cannot possibly contain any matching records.
> may
From: Robert Haas [mailto:robertmh...@gmail.com]
> That's not my experience. I agree that plan caching isn't important
> for long-running queries, but I think it *is* potentially important
> for fast queries with fast planning time. Even when the planning time
> is fast, it can be a significant p
On 9 May 2018 at 14:29, Amit Langote wrote:
> On 2018/05/09 11:20, Michael Paquier wrote:
>> While looking at this code, is there any reason to not make
>> gen_partprune_steps static? This is only used in partprune.c for now,
>> so the intention is to make it available for future patches?
>
> Yea
On 2018/05/09 11:20, Michael Paquier wrote:
> While looking at this code, is there any reason to not make
> gen_partprune_steps static? This is only used in partprune.c for now,
> so the intention is to make it available for future patches?
Yeah, making it static might be a good idea. I had made
(2018/05/03 9:29), Robert Haas wrote:
On Wed, May 2, 2018 at 7:06 AM, Etsuro Fujita
wrote:
Here is a small patch to remove a no-longer-needed cast in
postgresBeginForeignInsert().
Committed.
Thanks!
Best regards,
Etsuro Fujita
On Tue, May 08, 2018 at 07:05:46PM -0300, Alvaro Herrera wrote:
> The reason for this crash is that gen_partprune_steps_internal() is
> unable to generate any steps for the clause -- which is natural, since
> the operator is not in a btree opclass. There are various callers
> of gen_partprune_step
Hi.
On 2018/05/09 7:05, Alvaro Herrera wrote:
> So I found that this query also crashed (using your rig),
>
> create table coercepart (a varchar) partition by list (a);
> create table coercepart_ab partition of coercepart for values in ('ab');
> create table coercepart_bc partition of coercepart
On Wed, May 09, 2018 at 09:04:04AM +0900, Tatsuo Ishii wrote:
> I have simulated the idea and I wonder how to implement the query
> result cache on the streaming standby servers because no DML/DDL are
> executed on standby servers, that makes it impossible to invalidate
> the query cache. Probably
> On 07/05/18 05:47, Tom Lane wrote:
>> Tatsuo Ishii writes:
>>> Does anybody think having in-memory query result cache in core is a
>>> good idea?
>> No.
>
> Agreed.
>
> You could probably write an extension for that, though. I think the
> planner hook and custom scans give you enough flexibili
On 8 May 2018 at 16:15, Oleksandr Shulgin wrote:
> Hi Hackers,
>
> I didn't find the original discussion which led to introduction of the
> client-side set of keepalive parameters back in [1].
>
> The issue I'm facing is that it doesn't seem to be possible to set these
> parameters from the enviro
So I found that this query also crashed (using your rig),
create table coercepart (a varchar) partition by list (a);
create table coercepart_ab partition of coercepart for values in ('ab');
create table coercepart_bc partition of coercepart for values in ('bc');
create table coercepart_cd partitio
Moin,
On Tue, May 8, 2018 5:03 pm, Peter Eisentraut wrote:
> On 5/8/18 16:51, Tom Lane wrote:
>> Peter Eisentraut writes:
>>> On 5/8/18 13:57, Andrew Dunstan wrote:
+ # take executable files that file(1) thinks are perl files
+ find . -type f -perm -100 -exec file {} \; -print |
On Wed, May 9, 2018 at 1:15 AM, Robert Haas wrote:
> On Tue, May 8, 2018 at 12:10 AM, Thomas Munro
> wrote:
>> It's not a scan, it's not a join and it's not an aggregation so I
>> think it needs to be in a new as the same level as those
>> others. It's a different kind of thing.
>
> I'm a littl
On 5/8/18 16:51, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 5/8/18 13:57, Andrew Dunstan wrote:
>>> + # take executable files that file(1) thinks are perl files
>>> + find . -type f -perm -100 -exec file {} \; -print |
>>> + egrep -i ':.*perl[0-9]*\>' |
>
>> How portable is that?
>
>
Peter Eisentraut writes:
> On 5/8/18 13:57, Andrew Dunstan wrote:
>> +# take executable files that file(1) thinks are perl files
>> +find . -type f -perm -100 -exec file {} \; -print |
>> +egrep -i ':.*perl[0-9]*\>' |
> How portable is that?
Well, it's the same code that's in pgperlt
> On 7 May 2018, at 20:04, Robert Haas wrote:
>
> But what happens if a transaction starts on node A at time T0 but
> first touches node B at a much later time T1, such that T1 - T0 >
> global_snapshot_defer_time?
>
Such transaction will get "global snapshot too old" error.
In principle such
Resurrecting this old thread ...
I decided it'd be interesting to re-examine where initdb's runtime
is going, seeing that we just got done with a lot of bootstrap data
restructuring. I stuck some timing code into initdb, and got
results like this:
creating directory /home/postgres/testversion/da
On 5/8/18 13:57, Andrew Dunstan wrote:
> + # take executable files that file(1) thinks are perl files
> + find . -type f -perm -100 -exec file {} \; -print |
> + egrep -i ':.*perl[0-9]*\>' |
How portable is that?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL
Teodor Sigaev writes:
> Thanks for your idea, patch is attached
Looks mostly fine from here. A couple nitpicks:
* s/translable/translatable/
* Personally I'd try harder to make the lookup table constant, that is
+ static const struct
+ {
+ enum jbvTypetype;
+
Hello,
Fabien COELHO wrote:
> > Looking over the diff, I find that this patch tries to do too much and
> > needs to be split up.
>
> Yep, I agree that it would help the reviewing process. On the other hand I
> have bad memories about maintaining dependent patches which interfere
> significantly.
Hello Alvaro,
I think that I'll have time for a round of review in the first half of July.
Providing a rebased patch before then would be nice.
Note that even in the absence of a rebased patch, you can apply to an
older checkout if you have some limited window of time for a review.
Yes, su
Here's a small patch to add a script to call perlcritic, in the same way
that we have a script to call perltidy. Is also includes a perlcriticrc
file containing a policy to allow octal constants with leading zeros.
That's the only core severity 5 policy we are currently no in compliance
with.
W
Andrew,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 05/08/2018 01:18 PM, Stephen Frost wrote:
> > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> >> On 05/08/2018 12:51 PM, Stephen Frost wrote:
> >>> * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> >>> There'
On 05/08/2018 01:18 PM, Stephen Frost wrote:
> Andrew,
>
> * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
>> On 05/08/2018 12:51 PM, Stephen Frost wrote:
>>> * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
>>> There's not much point adding the ',' unless you're also putting the
Andrew,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 05/08/2018 12:51 PM, Stephen Frost wrote:
> > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> > There's not much point adding the ',' unless you're also putting the
> > ');' on the next line, is there..?
>
> No, not
On 05/08/2018 12:51 PM, Stephen Frost wrote:
> Greetings,
>
> * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
>> On 05/08/2018 10:06 AM, Andrew Dunstan wrote:
>>> { find . -type f -a \( -name
>>> '*.pl' -o -name '*.pm' \) -print; find . -type f -perm -100
>>> -exec file {
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
>
> > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> >
> > > - 'XLogRecPtr'=> 'pg_lsn');
> > > + 'XLogRecPtr'=> 'pg_lsn',);
> >
> > There's not much point adding the ',' unless
Stephen Frost wrote:
> * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
>
> > - 'XLogRecPtr'=> 'pg_lsn');
> > + 'XLogRecPtr'=> 'pg_lsn',);
>
> There's not much point adding the ',' unless you're also putting the
> ');' on the next line, is there..?
>
> Or is th
On 05/08/2018 11:49 AM, Vladimir Sitnikov wrote:
I have work loads that I can repeat, so I can help with testing.
That would be great.
Do you think you could use DTrace to capture the trace?
For instance, https://github.com/vlsi/pgsqlstat/blob/pgsqlio/pgsqlio
DTrace or BPF would be ok.
Bes
Greetings,
* Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote:
> On 05/08/2018 10:06 AM, Andrew Dunstan wrote:
> > { find . -type f -a \( -name
> > '*.pl' -o -name '*.pm' \) -print; find . -type f -perm -100
> > -exec file {} \; -print | egrep -i
> > ':.*perl[0-
Michael Paquier wrote:
> So the problem appears when an expression needs to use
> COERCION_PATH_ARRAYCOERCE for a type coercion from one type to another,
> which requires an execution state to be able to build the list of
> elements. The clause matching happens at planning state, so while there
>
On 05/08/2018 10:06 AM, Andrew Dunstan wrote:
> { find . -type f -a \( -name
> '*.pl' -o -name '*.pm' \) -print; find . -type f -perm -100
> -exec file {} \; -print | egrep -i
> ':.*perl[0-9]*\>' | cut -d: -f1; } | sort -u |
> xargs perlcriti
On 5/8/18 11:39, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
>> Yes. there are separate settings for the three types of brackets. Here's
>> what happens if we restrict the vertical tightness settings to parentheses.
>>
>> I think that's an unambiguous improvement.
>
> LGTM.
Yes, that looks b
On 5/8/18 11:31, Tom Lane wrote:
> Paul Howells writes:
>> Has there been or is there any current effort to implement SQL:2011
>> valid-time support in Postgres?
>
> Searching the archives, I can only find "valid-time" appearing in these
> threads related to temporal query processing:
>
> https:
1) Does this really pass muster from the translatability standpoint?
I doubt it.
Huh, I missed that.
I think you want the callers to look like
if (!JsonbExtractScalar(&in->root, &v) || v.type != jbvNumeric)
cannotCastJsonbValue(v.type, "double precision");
where the su
>I have work loads that I can repeat, so I can help with testing.
That would be great.
Do you think you could use DTrace to capture the trace?
For instance, https://github.com/vlsi/pgsqlstat/blob/pgsqlio/pgsqlio
Vladimir
On 05/08/2018 11:35 AM, Vladimir Sitnikov wrote:
Oh, looks like I'm inventing another kind of bicycle :-(
Do you think you could capture a trace or two from a more-or-less
representative application/database?
Discussion of algorithms makes little sense as we all lack traces to
compare/validate
Andrew Dunstan wrote:
> Yes. there are separate settings for the three types of brackets. Here's
> what happens if we restrict the vertical tightness settings to parentheses.
>
> I think that's an unambiguous improvement.
LGTM.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
Post
> Oh, looks like I'm inventing another kind of bicycle :-(
Do you think you could capture a trace or two from a more-or-less
representative application/database?
Discussion of algorithms makes little sense as we all lack traces to
compare/validate.
Vladimir
Paul Howells writes:
> Has there been or is there any current effort to implement SQL:2011
> valid-time support in Postgres?
Searching the archives, I can only find "valid-time" appearing in these
threads related to temporal query processing:
https://www.postgresql.org/message-id/flat/2007021000
Andrew Gierth wrote:
> > "Andreas" == Andreas Karlsson writes:
>
> Andreas> It would be a pain if the SQL committee started using MAP for
> Andreas> something.
>
> They already did - MAP is a non-reserved keyword in sql2016, used at
> least with . Can't see any obvious
> conflict with use
I wrote:
> 1) Does this really pass muster from the translatability standpoint?
> I doubt it.
After further thought about that, it seems that what we typically don't
try to translate is SQL-standard type names, that is, error messages
along the line of "blah blah blah type %s" are considered fine.
On 08.05.2018 17:15, Peter Eisentraut wrote:
On 5/8/18 09:19, Chapman Flack wrote:
On 05/08/2018 08:57 AM, Ildar Musin wrote:
select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
I wonder how efficient an implementation would be possible
strictly as a function, without grammar changes?
Peter Eisentraut writes:
> On 5/8/18 10:18, Alvaro Herrera wrote:
>> How would you invoke it? It seems you'd be forced to use EXECUTE in a
>> plpgsql function, or a C function.
> Yes, I was thinking about a C function.
The thing actually implementing MAP would presumably be in C,
so this doesn'
Hello All,
I am sure this has been discussed somewhere but I have not found anything
specific in the archives.
Has there been or is there any current effort to implement SQL:2011
valid-time support in Postgres? I understand that there has been some
efforts to implement some valid-time support bu
Alvaro Herrera wrote:
> Robert Haas wrote:
> > On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund wrote:
> > >> > 2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad
> > >> > file
> > >> > descriptor
> > >>
> > >> I can confirm this bug exists in single-user mode.
> > >
> > > I'm not
On 5/8/18 10:18, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>> On 5/8/18 09:19, Chapman Flack wrote:
>>> On 05/08/2018 08:57 AM, Ildar Musin wrote:
select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
>>>
>>> I wonder how efficient an implementation would be possible strictly
>>> as
> "Andreas" == Andreas Karlsson writes:
Andreas> It would be a pain if the SQL committee started using MAP for
Andreas> something.
They already did - MAP is a non-reserved keyword in sql2016, used at
least with . Can't see any obvious
conflict with use in expressions, but I haven't checked
Robert Haas wrote:
> On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund wrote:
> >> > 2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad file
> >> > descriptor
> >>
> >> I can confirm this bug exists in single-user mode.
> >
> > I'm not sure we need to do anything about this, personal
Robert Haas writes:
> On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund wrote:
>> I'm not sure we need to do anything about this, personally. This seems
>> like a fairly rare thing to do in a mode that's definitely not intended
>> to be general purpose.
> Mmmph. I don't really think it's possible
Teodor Sigaev writes:
> Does anybody have an objections to patch?
1) Does this really pass muster from the translatability standpoint?
I doubt it. I'd expect the translation of "cannot cast jsonb string
to int4" to use a translated equivalent of "string", but this code will
not do that. You can
On 05/08/2018 02:49 PM, Ildar Musin wrote:
The main point of this patch was about convenience; the performance
thing came out later just as a side effect :) Many users are familiar
with "map/reduce/filter" concept that many languages (not only
functional ones) utilized. And my though was that it
2018-05-08 16:21 GMT+03:00 Robert Haas :
>
> On Mon, May 7, 2018 at 12:54 PM, Юрий Соколов
wrote:
> >> Even if we have that, or something with similar effects, it's still
> >> desirable to avoid bumping the usage count multiple times for accesses
> >> that happen close together in time. I don't r
Peter Eisentraut wrote:
> On 5/8/18 09:19, Chapman Flack wrote:
> > On 05/08/2018 08:57 AM, Ildar Musin wrote:
> >>
> >> select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
> >
> > I wonder how efficient an implementation would be possible strictly
> > as a function, without grammar changes?
>
On 5/8/18 09:19, Chapman Flack wrote:
> On 05/08/2018 08:57 AM, Ildar Musin wrote:
>>
>> select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
>
> I wonder how efficient an implementation would be possible strictly
> as a function, without grammar changes?
Yeah, you can pass a function to another
On 05/08/2018 08:31 AM, David Steele wrote:
> On 5/8/18 8:11 AM, Stephen Frost wrote:
>> Greetings,
>>
>> * Michael Paquier (mich...@paquier.xyz) wrote:
>>> On Sun, May 06, 2018 at 09:14:06PM -0400, Stephen Frost wrote:
While I appreciate the support, I'm not sure that you're actually
a
2018-05-08 3:46 GMT-03:00 Michael Paquier :
> While hacking on an extension, I have finished by doing things similar
> to guc_malloc & friends for the allocation of a GUC parameter for malloc
> portability. While that's not really a big deal to copy/paste this
> code, I am wondering if it would ma
How about "cannot cast jsonb $json_type to $sql_type" where $json_type
is the type inside the jsonb (e.g. string, number, boolean, array,
object)?
Yes, that sounds pretty good.
Does anybody have an objections to patch?
--
Teodor Sigaev E-mail: teo...@sigaev.r
On 05/08/2018 09:19 AM, Chapman Flack wrote:
>
> While PostgreSQL certainly has extensions to and divergences from
> standard SQL syntax, some historical and some recent, it seems like
> there ought to be a highish bar for adding new ones; or, looking at it
> another way, has this feature been pro
On Thu, Mar 29, 2018 at 5:51 PM, Andres Freund wrote:
>> > 2018-03-06 13:20:24.391 GMT [14869] ERROR: epoll_ctl() failed: Bad file
>> > descriptor
>>
>> I can confirm this bug exists in single-user mode.
>
> I'm not sure we need to do anything about this, personally. This seems
> like a fairly ra
On Mon, May 07, 2018 at 06:00:59PM +1200, David Rowley wrote:
> Many thanks for reviewing this.
2nd round - from the minimalist department:
+partitions which cannot possibly contain any matching records.
maybe: partitions which cannot match any records.
+
+Partition pruning done durin
On Mon, May 7, 2018 at 12:54 PM, Юрий Соколов wrote:
>> Even if we have that, or something with similar effects, it's still
>> desirable to avoid bumping the usage count multiple times for accesses
>> that happen close together in time. I don't really agree with Yura
>> Sokolov's proposal for how
On 05/08/2018 08:57 AM, Ildar Musin wrote:
>
> select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
I wonder how efficient an implementation would be possible strictly
as a function, without grammar changes?
While PostgreSQL certainly has extensions to and divergences from
standard SQL syntax,
On Tue, May 8, 2018 at 12:10 AM, Thomas Munro
wrote:
> It's not a scan, it's not a join and it's not an aggregation so I
> think it needs to be in a new as the same level as those
> others. It's a different kind of thing.
I'm a little skeptical about that idea because I'm not sure it's
really i
On 08.05.2018 15:49, Ildar Musin wrote:
select map (pow(x, 2) - 1 for x in array[1,2,3]);
Sorry, the example should be:
select map (pow(2, x) - 1 for x in array[1,2,3,4,5]);
?column?
---
{1,3,7,15,31}
(1 row)
--
Ildar Musin
i.mu...@postgrespro.ru
Hello Tom, Ashutosh,
On 07.05.2018 18:16, Tom Lane wrote:
Ashutosh Bapat writes:
Is there a way we can improve unnest() and array_agg() to match
the performance you have specified by let's say optimizing the
cases specially when those two are used together. Identifying that
may be some work, b
On 5/8/18 8:11 AM, Stephen Frost wrote:
> Greetings,
>
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Sun, May 06, 2018 at 09:14:06PM -0400, Stephen Frost wrote:
>>> While I appreciate the support, I'm not sure that you're actually
>>> agreeing with me.. I was arguing that braces should b
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, May 06, 2018 at 09:14:06PM -0400, Stephen Frost wrote:
> > While I appreciate the support, I'm not sure that you're actually
> > agreeing with me.. I was arguing that braces should be on their own
> > line and therefore there wou
On Mon, May 7, 2018 at 11:34 PM, Amit Kapila wrote:
> Is this correct? See below example:
That's not a counterexample to what I wrote. When parallelism is
used, the InitPlan has to be attached to a parallel-restricted node,
and it is: Gather. It's true that in the serial plan it's attached to
On 5/6/18 12:13, Andrew Dunstan wrote:
> Essentially it adds some vertical whitespace to structures so that the
> enclosing braces etc appear on their own lines. A very typical change
> looks like this:
>
> - { code => $code,
> + {
> + code => $code,
On Mon, May 7, 2018 at 2:32 PM, Pavel Stehule wrote:
> For interactive application only for one subset of queries the plan cache is
> interesting.
>
> @1 There are long queries - the planning time is not significant (although
> can be high), and then plan cache is not important
> @2 there are fast
On 05.05.2018 00:54, Merlin Moncure wrote:
On Fri, May 4, 2018 at 2:25 PM, Robert Haas wrote:
On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote:
If we are breaking 1:1 backend:session relationship, what controls
would we have to manage resource consumption?
I mean, if you have a large
> "Ekta" == Ekta Khanna writes:
Ekta> Hello PGSQL Hackers,
Ekta> We have come across the following issue on Postgres
Ekta> REL_10_STABLE. Below is the repro:
[...]
Ekta> In the plan, we see that planner merges the quals from FROM
Ekta> clause and the WHERE clause in the same RESTRICTI
3rd iteration ; thanks for bearing with me.
On Tue, May 08, 2018 at 12:35:00PM +0300, Alexander Korotkov wrote:
> Hi, Justin!
>
> Thank you for revising documentation patch.
>
> On Mon, May 7, 2018 at 7:55 PM, Justin Pryzby wrote:
+In order to detect stale index statistics, the number
Hello PGSQL Hackers,
We have come across the following issue on Postgres REL_10_STABLE. Below is
the repro:
CREATE TABLE foo (a int, b text); INSERT INTO foo values(1, '3'); SELECT *
FROM (SELECT * FROM foo WHERE length(b)=8)x WHERE to_date(x.b,'MMDD') >
'2018-05-04';
ERROR: source string too
Fabien COELHO wrote:
> I think that I'll have time for a round of review in the first half of July.
> Providing a rebased patch before then would be nice.
Note that even in the absence of a rebased patch, you can apply to an
older checkout if you have some limited window of time for a review.
Lo
> "Aleksandr" == Aleksandr Parfenov writes:
>> From an implementation point of view your patch is obviously broken
>> in many ways (starting with not checking varattno anywhere, and not
>> actually checking anywhere if the expression is volatile).
Aleksandr> The actual checking if the ex
Hello Andrew,
Thank you for the review of the patch.
On Fri, 04 May 2018 08:37:31 +0100
Andrew Gierth wrote:
> From an implementation point of view your patch is obviously broken in
> many ways (starting with not checking varattno anywhere, and not
> actually checking anywhere if the expression
On Tue, May 08, 2018 at 04:07:41PM +0900, Amit Langote wrote:
> I have to agree to go with this conservative approach for now. Although
> we might be able to evaluate the array elements by applying the coercion
> specified by ArrayCoerceExpr, let's save that as an improvement to be
> pursued later
Hi, Justin!
Thank you for revising documentation patch.
On Mon, May 7, 2018 at 7:55 PM, Justin Pryzby wrote:
> On Mon, May 07, 2018 at 07:26:25PM +0300, Alexander Korotkov wrote:
> > Hi!
> >
> > I've revised docs and comments, and also made some fixes in the code.
> > See the attached patchset.
Hello Pavel,
08.05.2018 11:19, Pavlo Golub wrote:
Cool idea.
- Why are you using x86 version of MSYS2?
We build PostgresPro for x86 and x64 so I choose to use x86 version as a
common denominator to run the same script in 32-bit Windows.
(When running on 64-bit Windows any (x86/x64) version of P
Greetings, Alexander.
You wrote 08.05.2018, 9:42:
> 25.04.2018 11:45, insaf.k wrote:
>
> I've done some research regarding compiling in Windows. I
> am not sure in what way I should compile the extension.
> AFAIK, Visual Studio is not POSIX compliant and so I'll have
>
Hi Hackers,
I didn't find the original discussion which led to introduction of the
client-side set of keepalive parameters back in [1].
The issue I'm facing is that it doesn't seem to be possible to set these
parameters from the environment variables. The block of option
definitions[2] added for
On Tue, May 1, 2018 at 5:00 PM, Etsuro Fujita
wrote:
> (2018/04/27 14:40), Ashutosh Bapat wrote:
>>
>> Here's updated patch set.
>
>
> Thanks for updating the patch! Here are my review comments on patch
> 0003-postgres_fdw-child-join-with-ConvertRowtypeExprs-cau.patch:
>
> * This assertion in dep
Thank you Marina for the report and Michael for following up.
On 2018/05/07 16:56, Michael Paquier wrote:
> On Mon, May 07, 2018 at 10:37:10AM +0900, Michael Paquier wrote:
>> On Fri, May 04, 2018 at 12:32:23PM +0300, Marina Polyakova wrote:
>>> I got a similar server crash as in [1] on the master
89 matches
Mail list logo
