This kind of reports is the exact reason you should never install the OS in
a different language than english. you could have at least googled for the
exact phrase "controllo di integrita fallito" to see how other people
have solved it.
On Mon, 12 Mar 2018 at 14:50 Enzo Diletti wrote:
> A de
Hi,
On Sat, Apr 07, 2018 at 08:57:03AM +0200, Magnus Hagander wrote:
> On Sat, Apr 7, 2018 at 6:26 AM, Andres Freund wrote:
> > If it's not obvious: This isn't ready, should be reverted, cleaned up,
> > and re-submitted for v12.
>
> While I do think that it's still definitely fixable in time for
John Naylor wrote:
> On 4/6/18, Tom Lane wrote:
>
> > I don't think there's any great need to incorporate this into your patch
> > set. As far as I'm concerned, v14 is ready as-is, and I'll just apply
> > this over the top of it. (Note that I'll probably smash the whole thing
> > to one commit
Andres Freund wrote:
> Hi,
>
> On 2018-04-07 15:49:54 +1200, David Rowley wrote:
> > Right, I suggest we wait and see if all members go green again as a
> > result of 40e42e1024c, and if they're happy then we could maybe leave
> > it as is with the 2 alternatives output files.
>
> At least the fi
Pavel Stehule wrote:
> so we can to have
>
> \pset format xxx
>
> and set of local possibly changed defaults
>
> \pset csv_fieldsep ,
> \pset csv_tuplesonly on
> \pset unaligned_fieldsep |
> \pset unaligned_tuplesonly off
tuples_only (\t) is a single setting that is currently used by a
On 2018-04-06 20:08, Alexander Korotkov wrote:
[0001-Covering-v15.patch]
After some more testing I notice there is also a down-side/slow-down to
this patch that is not so bad but more than negligible, and I don't
think it has been mentioned (but I may have missed something in this
thread t
2018-04-07 13:55 GMT+02:00 Daniel Verite :
> Pavel Stehule wrote:
>
> > so we can to have
> >
> > \pset format xxx
> >
> > and set of local possibly changed defaults
> >
> > \pset csv_fieldsep ,
> > \pset csv_tuplesonly on
> > \pset unaligned_fieldsep |
> > \pset unaligned_tuplesonly off
>
Peter Eisentraut wrote:
> Another thought: Isn't CSV just the same as unaligned output plus some
> quoting? Could we add a quote character setting and then define --csv
> to be quote-character = " and fieldsep = , ?
Plus footer set to off. So --csv would be like
\pset format unaligned
\p
Amit Langote wrote:
> See if the attached makes it any better.
>
> Now I know we don't have the runtime pruning in yet, but since the
> proposed patch would extend its functionality I have included its
> description in the comment.
Thanks!
I edited it as attached, to 1. avoid mentioning functio
Tom Lane wrote:
> I've always felt that the pg_foo_fn.h business was a kluge, and would
> be happy to get rid of it. But one could also argue that it would be
> a good design, if we adopted it uniformly instead of haphazardly.
> But that'd require more code churn, and there's no longer a lot to b
Thank you!
create unique index ${t}uniqueinclude_idx on $t using btree (c1, c2)
include (c3, c4);
or for HEAD, just:
create unique index ${t}unique_idx on $t using btree (c1, c2);
-- explain analyze select c1, c2 from nt0___1 where c1 < 1
-- explain analyze select c1, c2
On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers wrote:
> On 2018-04-06 20:08, Alexander Korotkov wrote:
>
>>
>> [0001-Covering-v15.patch]
>>
>>
> After some more testing I notice there is also a down-side/slow-down to
> this patch that is not so bad but more than negligible, and I don't think
> it h
On Sat, Apr 07, 2018 at 09:25:44AM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
>> I've always felt that the pg_foo_fn.h business was a kluge, and would
>> be happy to get rid of it. But one could also argue that it would be
>> a good design, if we adopted it uniformly instead of haphazardly.
>>
On 8 April 2018 at 00:23, Alvaro Herrera wrote:
> I edited it as attached, to 1. avoid mentioning functionality that
> doesn't yet exist, and 2. avoid excessive internal detail (we want a
> high-level overview here), which from experience gets outdated pretty
> quickly.
It's not exactly wrong but
On 2018-04-07 14:27, Alexander Korotkov wrote:
On Sat, Apr 7, 2018 at 2:57 PM, Erik Rijkers wrote:
On 2018-04-06 20:08, Alexander Korotkov wrote:
[0001-Covering-v15.patch]
After some more testing I notice there is also a down-side/slow-down
to
this patch that is not so bad but more than ne
This is the same one you already committed right? Not a further one on top
of that?
That said,+1 for not bothering to back patch it.
/Magnus
On Sat, Apr 7, 2018, 00:39 Andres Freund wrote:
> Hi,
>
> As Daniel pointed out in:
> https://postgr.es/m/fb948276-7b32-4b77-83e6-d00167f8e...@yesql.se
David Rowley wrote:
> It's not exactly wrong but:
>
> + * are turned into a set of "pruning steps", which are then executed to
> + * produce a set of RTIs of partitions whose bounds satisfy the constraints
> in
> + * the step. Partitions not in the set are said to have been pruned.
>
> It's on
On 8 April 2018 at 01:18, Alvaro Herrera wrote:
> Amit had it as "indexes" also in his original. I wanted to avoid using
> the "indexes" word alone, whose meaning is so overloaded.
hmm, good point.
> How about this?
> "... which are then executed to produce a set of partitions (as indexes
> of
Isaac Morland wrote:
> OK, mostly trying to avoid commenting because I doubt I have much to add.
> But. If I ask for CSV and don't specify any overrides, I expect to get
> "C"omma separated values, not some other character. More specifically, if I
> say --csv I expect to get files that are
I didn't like rel.h being included in itup.h. Do you really need a
Relation as argument to index_truncate_tuple? It looks to me like you
could pass the tupledesc instead; indnatts could be passed as a separate
argument instead of IndexRelationGetNumberOfAttributes.
--
Álvaro Herrera
David Rowley wrote:
> On 8 April 2018 at 01:18, Alvaro Herrera wrote:
> > Amit had it as "indexes" also in his original. I wanted to avoid using
> > the "indexes" word alone, whose meaning is so overloaded.
>
> hmm, good point.
>
> > How about this?
> > "... which are then executed to produce a
Daniel Verite wrote:
> The output might still differ compared to COPY in that line endings
> depend on the client-side OS. There's also the minor issue
> of a single \ by itself on a line, which gets quoted by COPY
> and not by psql.
I meant \. or backslash followed by period.
This sequen
I didn't like rel.h being included in itup.h. Do you really need a
Relation as argument to index_truncate_tuple? It looks to me like you
could pass the tupledesc instead; indnatts could be passed as a separate
argument instead of IndexRelationGetNumberOfAttributes.
Hm, okay, I understand why,
Hi,
On 04/07/2018 04:45 AM, David Rowley wrote:
Ok, so I've gone and done this.
PartitionPruning has become PartitionPruneState
PartitionRelPruning has become PartitionPruningData
I've changed pointers to PartitionPruneStates to be named prunestate,
sometimes having the node prefix; as_, ma_,
Alvaro Herrera writes:
> John Naylor wrote:
>> Commit 9fdb675fc added a symbol to pg_opfamily.h
>> where there were none before, so I went ahead and wrapped it with an
>> EXPOSE_TO_CLIENT_CODE macro.
> Actually, after pushing that, I was thinking maybe it's better to remove
> that #define from th
On Fri, Apr 6, 2018 at 11:40 PM, Alexander Kuzmenkov <
a.kuzmen...@postgrespro.ru> wrote:
> On 06.04.2018 20:26, Tomas Vondra wrote:
>
>> I personally am OK with reducing the scope of the patch like this. It's
>> still beneficial for the common ORDER BY + LIMIT case, which is good. I
>> don't thin
On Sat, Apr 7, 2018 at 4:56 PM, Alexander Korotkov <
a.korot...@postgrespro.ru> wrote:
> On Fri, Apr 6, 2018 at 11:40 PM, Alexander Kuzmenkov <
> a.kuzmen...@postgrespro.ru> wrote:
>
>> On 06.04.2018 20:26, Tomas Vondra wrote:
>>
>>> I personally am OK with reducing the scope of the patch like thi
On Sun, Apr 1, 2018 at 06:07:55PM +0200, Tomas Vondra wrote:
> Hi,
>
> The attached patch version modifies how the non-MCV selectivity is
> computed, along the lines explained in the previous message.
>
> The comments in statext_clauselist_selectivity() explain it in far more
> detail, but we th
Thanks to everyone, pushed
Alexander Korotkov wrote:
On Fri, Mar 2, 2018 at 6:57 AM, Thomas Munro
mailto:thomas.mu...@enterprisedb.com>>
wrote:
My thought experiments about pseudo-pages and avoiding the split stuff
were not intended to get the patch kicked out. I thought for a while
Tom Lane wrote:
> Alvaro Herrera writes:
> > John Naylor wrote:
> >> Commit 9fdb675fc added a symbol to pg_opfamily.h
> >> where there were none before, so I went ahead and wrapped it with an
> >> EXPOSE_TO_CLIENT_CODE macro.
>
> > Actually, after pushing that, I was thinking maybe it's better to
Hello,
I notice Parallel append is not listed on Parallel Plans documentation :
https://www.postgresql.org/docs/devel/static/parallel-plans.html
If you agree I can add it to Open Items.
Thanks,
--
Adrien NAYRAT
signature.asc
Description: OpenPGP digital signature
by this patch. Revised version is attached.
Fine, patch got several rounds of review in all its parts. Is any places
which should be improved before commit?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
On Sat, Apr 7, 2018 at 9:08 AM, Andres Freund wrote:
> Hi Tom, All,
>
> On 2018-04-06 14:19:02 +0530, amul sul wrote:
>> Thanks for the reminder -- fixed in the attached version.
>
> Tom, this seems to be the best approach for fixing the visibility issues
> around this. I've spent a good chunk of
> On 6 April 2018 at 18:55, Teodor Sigaev wrote:
>
>
> Dmitry Dolgov wrote:
>>>
>>> On 6 April 2018 at 16:25, Teodor Sigaev wrote:
>>> 1) I don't like jsonb_all_to_tsvector too.. What if we will accept new
>>> variant to index? Let me suggest:
>>>
>>> tsvector jsonb_to_tsvector([regclass,] jsonb,
On 04/07/2018 04:37 PM, Teodor Sigaev wrote:
>> by this patch. Revised version is attached.
>
> Fine, patch got several rounds of review in all its parts. Is any
> places which should be improved before commit?
>
I personally feel rather uneasy about committing it, TBH.
While I don't see any o
See workable sketch for parsing jsonb flags and new worker variant.
Yep, thanks for the sketch. Here is the new version of patch, does it look
close to what you have in mind?
Patch looks good except error messaging, you took it directly from
sketch where I didn't spend time for it. Please, im
amul sul wrote:
> On Sat, Apr 7, 2018 at 9:08 AM, Andres Freund wrote:
> >> +test: partition-key-update-1
> >> +test: partition-key-update-2
> >> +test: partition-key-update-3
> >
> > Can you give these more descriptive names please (or further combine them)?
>
> As I explained above further com
> On Mar 21, 2018, at 10:59 PM, Amit Langote
> wrote:
>
> Hi David.
>
> On 2018/03/21 23:31, David Steele wrote:
>> Hi Amit,
>>
>> On 3/6/18 9:44 AM, David Steele wrote:
>>> On 3/2/18 2:27 AM, Amit Langote wrote:
On 2018/03/02 15:58, Andres Freund wrote:
> On 2018-02-02 17:00:24 -050
Hi,
On 2018-04-07 10:14:49 +0200, Michael Banck wrote:
> Can the pg_verify_checksums command be kept at least, please?
>
> AFAICT this one is not contentious, the code is isolated, it's really
> useful, orthogonal to online checksum activation and argueably could've
> been committed as a separat
On 2018-04-07 08:13:23 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > I've also attempted to fix rhinoceros's failure I remarked upon a couple
> > hours ago in
> > https://postgr.es/m/20180406210330.wmqw42wqgiick...@alap3.anarazel.de
>
> And this, too. I was unsure if this was because we
On Wed, Mar 28, 2018 at 6:38 PM, Alvaro Herrera
wrote:
> Teodor Sigaev wrote:
> > > BTW, patch had conflicts with master. Please, find rebased version
> attached.
> >
> > Despite by patch conflist patch looks commitable, has anybody objections
> to
> > commit it?
> >
> > Patch recieved several r
Alexander Korotkov writes:
> On Wed, Mar 28, 2018 at 6:38 PM, Alvaro Herrera
> wrote:
>> Can we have a recap on what the patch *does*?
> Ggeneral idea hasn't been changed much since first email.
> Incremental sort gives benefit when you need to sort your dataset
> by some list of columns while y
Hello Stephen,
Here's that review.
Thanks for the review.
+
+
+ \cset [prefix] or
+ \gset [prefix]
+
Seems like this should really be moved down below the section for
'\set'.
Dunno.
I put them there because it is in alphabetical order (for cset at least)
and bec
> On 7 April 2018 at 17:09, Teodor Sigaev wrote:
>>> See workable sketch for parsing jsonb flags and new worker variant.
>>
>>
>> Yep, thanks for the sketch. Here is the new version of patch, does it look
>> close to what you have in mind?
>
>
> Patch looks good except error messaging, you took it
On 2018-04-07 12:06:52 -0400, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Wed, Mar 28, 2018 at 6:38 PM, Alvaro Herrera
> > wrote:
> >> Can we have a recap on what the patch *does*?
>
> > Ggeneral idea hasn't been changed much since first email.
> > Incremental sort gives benefit when you
Hi,
On 2018-04-07 12:57:53 +, Magnus Hagander wrote:
> This is the same one you already committed right? Not a further one on top
> of that?
Yes, I pushed a few hours later.
> That said,+1 for not bothering to back patch it.
I did ;). I was more wondering about whether to backpatch the AB
I dunno, how would you estimate whether this is actually a win or not?
I don't think our model of sort costs is anywhere near refined enough
or accurate enough to reliably predict whether this is better than
just doing it in one step. Even if the cost model is good, it's not
going to be better th
Hi,
On 2018-04-07 08:57:03 +0200, Magnus Hagander wrote:
> Note however that I'm sans-laptop until Sunday, so I will revert it then or
> possibly Monday.
I'll deactive the isolationtester tests until then. They've been
intermittently broken for days now and prevent other tests from being
exercise
On Sat, Apr 7, 2018 at 5:37 PM, Teodor Sigaev wrote:
> by this patch. Revised version is attached.
>>
>
> Fine, patch got several rounds of review in all its parts. Is any places
> which should be improved before commit?
Also I found that after planner changes of Alexander Kuzmenkov, increment
Teodor Sigaev writes:
>> I dunno, how would you estimate whether this is actually a win or not?
>> I don't think our model of sort costs is anywhere near refined enough
>> or accurate enough to reliably predict whether this is better than
>> just doing it in one step. Even if the cost model is go
David Rowley writes:
> It's certainly possible to do more here. I'm uncertain what needs to
> be done in regards to cached plan invalidation, but we'd certainly
> need to ensure cached plans are invalidated whenever the attnotnull is
> changed.
They already are; any change at all in a pg_class o
Hi Stephen,
On 4/6/18 10:22 PM, Stephen Frost wrote:
>
> * David Steele (da...@pgmasters.net) wrote:
>> On 4/6/18 6:04 PM, David Steele wrote:
>>> On 4/6/18 3:02 PM, Stephen Frost wrote:
- Further discussion in the commit messages
>>>
>>> Agreed, these need some more work. I'm happy to
On 6 April 2018 at 17:22, Bruce Momjian wrote:
> On Fri, Apr 6, 2018 at 09:21:54AM +0100, Simon Riggs wrote:
>> On 5 April 2018 at 21:02, Bruce Momjian wrote:
>> > Simon, you have three committers in this thread suggesting this patch be
>> > reverted. Are you just going to barrel ahead with the
On Sat, Apr 7, 2018 at 06:19:19PM +0100, Simon Riggs wrote:
> Now I can see some people are annoyed, so I'm happy to apologize if
> I've done things that weren't understood or caused annoyance. Time is
> short at end of CF and tempers fray for us all.
>
> If Tom or Andres still feel that their co
On Sat, Apr 7, 2018 at 5:48 AM, Teodor Sigaev wrote:
> On close look, bts_btentry.ip_posid is not used anymore, I change
> bts_btentry type to BlockNumber. As result, BTEntrySame() is removed.
That seems like a good idea.
> I'm not very happy with massive usage of
> ItemPointerGetBlockNumberNoCh
Simon Riggs writes:
> On 6 April 2018 at 17:22, Bruce Momjian wrote:
>> My point was that people didn't ask you to work harder on fixing the
>> patch, but in reverting it. You can work harder on fixing things in the
>> hope they change their minds, but again, that isn't addressing their
>> reque
Hi,
On 2018-04-07 13:45:21 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On 6 April 2018 at 17:22, Bruce Momjian wrote:
> >> My point was that people didn't ask you to work harder on fixing the
> >> patch, but in reverting it. You can work harder on fixing things in the
> >> hope they change
On 7 April 2018 at 15:12, Bruce Momjian wrote:
> Uh, where are we on this patch? It isn't going to make it into PG 11?
> Feature development for this has been going on for years.
Unfortunately, I think there's no way that this will be ready for
PG11. So far, I have only read parts of the patch,
Hi,
On 2018-04-07 13:33:53 -0400, Bruce Momjian wrote:
> To summarize how I see this patch, we have this workflow at the top of
> the TODO list (which I think Simon helped with or suggested):
>
> Desirability -> Design -> Implement -> Test -> Review -> Commit
>
> I think the MERGE patch sp
Thank you, pushed with some editorization
Dmitry Dolgov wrote:
On 7 April 2018 at 17:09, Teodor Sigaev wrote:
See workable sketch for parsing jsonb flags and new worker variant.
Yep, thanks for the sketch. Here is the new version of patch, does it look
close to what you have in mind?
Pat
Andres Freund writes:
> As Daniel pointed out in:
> https://postgr.es/m/fb948276-7b32-4b77-83e6-d00167f8e...@yesql.se the
> pg_atomic_flag fallback implementation is broken. That has gone
> unnoticed because the fallback implementation wasn't testable until now:
> ...
> The attached fixes the bug
Hi,
sqlsmith found a query that triggers the following assertion in master
as of 039eb6e92f:
TRAP: FailedAssertion("!(subpath->parallel_safe)", File: "pathnode.c", Line:
1813)
Backtrace and recipe against the regression database below.
regards,
Andreas
#0 __GI_raise (sig=sig@entry=6) at ../s
On 2018-04-07 14:07:05 -0400, Tom Lane wrote:
> Andres Freund writes:
> > As Daniel pointed out in:
> > https://postgr.es/m/fb948276-7b32-4b77-83e6-d00167f8e...@yesql.se the
> > pg_atomic_flag fallback implementation is broken. That has gone
> > unnoticed because the fallback implementation wasn'
Andres Freund writes:
> On 2018-04-07 14:07:05 -0400, Tom Lane wrote:
>> TRAP: UnalignedPointer("(((uintptr_t) ((uintptr_t)(ptr)) + ((sizeof(*ptr)) -
>> 1)) & ~((uintptr_t) ((sizeof(*ptr)) - 1))) != (uintptr_t)(ptr)", File:
>> "../../../src/include/port/atomics.h", Line: 177)
> Yea, I just saw
Hi,
On 2018-04-07 14:23:38 -0400, Tom Lane wrote:
> I think I'd just drop those asserts altogether. The hardware is in charge
> of complaining about misaligned pointers.
Well, the problem is that some atomics operations on some platforms do
not fail for unaligned pointers, they just loose their
Hi,
testing with master at 039eb6e92f yielded another query triggering an
assertion. Backtrace and query against the regression database below.
regards,
Andreas
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x7f25474cf42a in __GI_abort () at abort.c:89
#2 0x
On Sat, Apr 7, 2018 at 06:52:42PM +0100, Dean Rasheed wrote:
> On 7 April 2018 at 15:12, Bruce Momjian wrote:
> > Uh, where are we on this patch? It isn't going to make it into PG 11?
> > Feature development for this has been going on for years.
>
> Unfortunately, I think there's no way that th
Andreas Seltenreich wrote:
> Hi,
>
> sqlsmith found a query that triggers the following assertion in master
> as of 039eb6e92f:
>
> TRAP: FailedAssertion("!(subpath->parallel_safe)", File: "pathnode.c", Line:
> 1813)
>
> Backtrace and recipe against the regression database below.
Uh, that's pr
Alvaro Herrera writes:
> Andreas Seltenreich wrote:
>> sqlsmith found a query that triggers the following assertion in master
>> as of 039eb6e92f:
>> TRAP: FailedAssertion("!(subpath->parallel_safe)", File: "pathnode.c", Line:
>> 1813)
> Uh, that's pretty strange -- that patch did not touch the
Tom Lane writes:
> Alvaro Herrera writes:
>> Andreas Seltenreich wrote:
>>> as of 039eb6e92f:
>>> TRAP: FailedAssertion("!(subpath->parallel_safe)", File: "pathnode.c",
>>> Line: 1813)
>
>> Uh, that's pretty strange -- that patch did not touch the planner at
>> all, and the relcache.c changes are
Hi,
sqlsmith triggered an assertion with the following MERGE statement
against the regression database. Testing was done with master at
039eb6e92f. Backtrace below.
regards,
Andreas
MERGE INTO public.pagg_tab_ml_p3 as target_0
USING public.hash_i4_heap as ref_0
ON target_0.b = ref_0.seqno
WHEN
Hi,
the following query triggers a segfault for me when run against the
regression database. Testing was done with master at 039eb6e92f.
Backtrace below.
regards,
Andreas
select
case when pg_catalog.lastval() <
pg_catalog.pg_stat_get_bgwriter_maxwritten_clean() then case when
pg_catalog.cir
Hi,
On 2018-04-07 21:28:39 +0200, Andreas Seltenreich wrote:
> the following query triggers a segfault for me when run against the
> regression database. Testing was done with master at 039eb6e92f.
> Backtrace below.
Andrew, that looks like it's in your area?
> Core was generated by `postgres:
Andres Freund wrote:
> On 2018-04-07 08:13:23 -0300, Alvaro Herrera wrote:
> > Andres Freund wrote:
> > > I've also attempted to fix rhinoceros's failure I remarked upon a couple
> > > hours ago in
> > > https://postgr.es/m/20180406210330.wmqw42wqgiick...@alap3.anarazel.de
> >
> > And this, too.
Thanks to everyone, pushed.
Peter Geoghegan wrote:
On Sat, Apr 7, 2018 at 5:48 AM, Teodor Sigaev wrote:
On close look, bts_btentry.ip_posid is not used anymore, I change
bts_btentry type to BlockNumber. As result, BTEntrySame() is removed.
That seems like a good idea.
I'm not very happy
På lørdag 07. april 2018 kl. 22:02:08, skrev Teodor Sigaev mailto:teo...@sigaev.ru>>:
Thanks to everyone, pushed.
Rock!
--
Andreas Joseph Krogh
On Sat, Apr 7, 2018 at 1:02 PM, Teodor Sigaev wrote:
> Thanks to everyone, pushed.
I'll keep an eye on the buildfarm, since it's late in Russia.
--
Peter Geoghegan
I'll keep an eye on the buildfarm, since it's late in Russia.
Thank you very much! Now 23:10 MSK and I'll be able to follow during
approximately hour.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
On 2018-04-06 09:41:07 +0530, Amit Kapila wrote:
> >> Won't the same question applies to the similar usage in
> >> EvalPlanQualFetch and heap_lock_updated_tuple_rec.
> >
> > I don't think so?
> >
> >
> >> In EvalPlanQualFetch, we consider such a tuple to be deleted and will
> >> silently miss/skip
On 2018-04-07 20:13:36 +0530, amul sul wrote:
> Attached is the patch does the renaming of this tests -- need to apply
> to the top of v10 patch[1].
These indeed are a bit too long, so I went with the numbers. I've
pushed the patch now. Two changes:
- I've added one more error patch to EvalPlanQ
On 2018-04-07 23:02:08 +0300, Teodor Sigaev wrote:
> Thanks to everyone, pushed.
Marked CF entry as committed.
Greetings,
Andres Freund
On 2018-04-06 19:25:20 -0400, Robert Haas wrote:
> On Thu, Apr 5, 2018 at 6:21 AM, Etsuro Fujita
> wrote:
> > Attached is an updated version of the patch set plus the patch in [1]. Patch
> > 0003_foreign-routing-fdwapi-6.patch can be applied on top of patch
> > 0001_postgres-fdw-refactoring-6.patc
On Sun, Apr 8, 2018 at 5:37 AM, Andres Freund wrote:
> On 2018-04-06 19:25:20 -0400, Robert Haas wrote:
>> On Thu, Apr 5, 2018 at 6:21 AM, Etsuro Fujita
>> wrote:
>> > Attached is an updated version of the patch set plus the patch in [1].
>> > Patch
>> > 0003_foreign-routing-fdwapi-6.patch can b
On 04/07/2018 07:52 PM, Dean Rasheed wrote:
> On 7 April 2018 at 15:12, Bruce Momjian wrote:
>> Uh, where are we on this patch? It isn't going to make it into PG 11?
>> Feature development for this has been going on for years.
>
> Unfortunately, I think there's no way that this will be ready fo
Thank you, I looked to buildfarm and completely forget about commitfest site
Andres Freund wrote:
On 2018-04-07 23:02:08 +0300, Teodor Sigaev wrote:
Thanks to everyone, pushed.
Marked CF entry as committed.
Greetings,
Andres Freund
--
Teodor Sigaev E-mail: teo...@sig
> "Teodor" == Teodor Sigaev writes:
>> I'll keep an eye on the buildfarm, since it's late in Russia.
Teodor> Thank you very much! Now 23:10 MSK and I'll be able to follow
Teodor> during approximately hour.
Support for testing amcaninclude via
pg_indexam_has_property(oid,'can_include') s
I wrote:
> My gripe about
> this as it stands is mainly that it seems like it's going to do
> a lot of catalog-lookup work twice over, at least in cases that
> have both DISTINCT and GROUP BY --- or is that too small a set to
> worry about?
I convinced myself that that was a silly objection, and s
On Sat, Apr 7, 2018 at 1:52 PM, Andrew Gierth
wrote:
> Support for testing amcaninclude via
> pg_indexam_has_property(oid,'can_include') seems to be missing?
>
> Also the return values of pg_index_column_has_property for included
> columns seem a bit dubious... should probably be returning NULL fo
On 04/07/2018 06:23 PM, Tom Lane wrote:
> Teodor Sigaev writes:
>>> I dunno, how would you estimate whether this is actually a win or not?
>>> I don't think our model of sort costs is anywhere near refined enough
>>> or accurate enough to reliably predict whether this is better than
>>> just doing
Support for testing amcaninclude via
pg_indexam_has_property(oid,'can_include') seems to be missing?
Also the return values of pg_index_column_has_property for included
columns seem a bit dubious... should probably be returning NULL for most
properties except 'returnable'.
Damn, you right, it's
> "Teodor" == Teodor Sigaev writes:
>> Support for testing amcaninclude via
>> pg_indexam_has_property(oid,'can_include') seems to be missing?
>>
>> Also the return values of pg_index_column_has_property for included
>> columns seem a bit dubious... should probably be returning NULL for
I pushed this patch -- 0001, 0002 and 0003 only. I did not include
anything from 0004 and 0005; I didn't even get to the point of reading
them, so that I could focus on the first part.
I did not find anything to complain about. I made a few adjustments and
asked David to supply a paragraph for p
On 8 April 2018 at 08:55, Tom Lane wrote:
> regression=# create table t1 (a int,b int, c int, d int, primary key(a,b));
> CREATE TABLE
> regression=# explain verbose select distinct * from t1 order by a,c,b;
> server closed the connection unexpectedly
> This probably means the server termi
On 8 April 2018 at 09:13, Alvaro Herrera wrote:
> I pushed this patch -- 0001, 0002 and 0003 only. I did not include
> anything from 0004 and 0005; I didn't even get to the point of reading
> them, so that I could focus on the first part.
Oh great! Thank you for working on this and pushing it, e
David,
* David Steele (da...@pgmasters.net) wrote:
> On 4/6/18 10:22 PM, Stephen Frost wrote:
> > * David Steele (da...@pgmasters.net) wrote:
> >> On 4/6/18 6:04 PM, David Steele wrote:
> >>> On 4/6/18 3:02 PM, Stephen Frost wrote:
>
> - Further discussion in the commit messages
> >>>
>
On 4/7/18 5:49 PM, Stephen Frost wrote:
> * David Steele (da...@pgmasters.net) wrote:
>>
>> OK, one last review. I did't make any code changes, but I improved some
>> comments, added documentation and fixed a test.
>
> Thanks! I took those and then added a bit more commentary around the
> umask(
Stephen Frost writes:
> Time to watch the buildfarm,
That didn't take long.
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2018-04-07%2021%3A50%3A02
(I'm really starting to get a bit upset at the amount of stuff that's
being pushed in on the very last day.)
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Time to watch the buildfarm,
>
> That didn't take long.
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2018-04-07%2021%3A50%3A02
Yes, I'm taking a look at it.
Thanks!
Stephen
signature.asc
Des
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2018-04-07%2021%3A50%3A02
> Yes, I'm taking a look at it.
Since other animals are coming back successfully, my first suspicion
lights on culicidae's use of EXEC_
Hi,
It's common that half the buildfarm has reported back before a single
windows buildfarm animal reports. And if they report a failure one often
has to wait for hours for the next run.
It'd be awesome if somebody could set up a windows animal that runs
frequently (i.e. checks for build needed e
1 - 100 of 119 matches
Mail list logo
