(2018/03/28 13:25), Tom Lane wrote:
Andres Freund writes:
There's also a few of that annoying postgres_fdw thing. Some of my
critters hit that regularly :(. We need to figure out what's going on
there.
I plan to work on this after the commitfest.
Yeah, really. I've made several sustained a
On 2018-03-27 23:40:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Note there appear to be some independent failures?
>
> It looks to me like the hard failures from this patch are all on your JIT
> critters. There are a bunch of random failures from Simon's commit,
> but I think those are
On Wed, Mar 28, 2018 at 3:18 PM, Tom Lane wrote:
> Andres Freund writes:
>> The one I noticed was:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=treepie&dt=2018-03-28%2002%3A43%3A00
>> ...
>> which probably is just collation related and will stably fail?
>
> Yeah, magpie is still sho
Andres Freund writes:
> The one I noticed was:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=treepie&dt=2018-03-28%2002%3A43%3A00
> ...
> which probably is just collation related and will stably fail?
Yeah, magpie is still showing that after the latest commits.
A bit of COLLATE "C" mi
Andres Freund writes:
> There's also a few of that annoying postgres_fdw thing. Some of my
> critters hit that regularly :(. We need to figure out what's going on
> there.
Yeah, really. I've made several sustained attempts to reproduce that
locally, on every machine I have, without success.
It'
On 2018-03-27 23:40:25 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Note there appear to be some independent failures?
>
> It looks to me like the hard failures from this patch are all on your JIT
> critters.
The one I noticed was:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tr
Hi,
On 2018-03-27 18:10:31 -0700, Andres Freund wrote:
> K, not 100% sure I'll get it done today, I'm neck deep looking at
> something else. But if not, I'll surely get it done tomorrow morning
> PST.
I've pushed a somewhat hurried fix. It passes all the tests here, but
normally I would've let i
Andres Freund writes:
> Note there appear to be some independent failures?
It looks to me like the hard failures from this patch are all on your JIT
critters. There are a bunch of random failures from Simon's commit,
but I think those are just timing, per <31021.1522185...@sss.pgh.pa.us>.
Hi,
On 2018-03-28 11:37:49 +1030, Andrew Dunstan wrote:
> Please do.
K, not 100% sure I'll get it done today, I'm neck deep looking at
something else. But if not, I'll surely get it done tomorrow morning
PST.
Note there appear to be some independent failures?
> I guess I need to do some enabl
On Wed, Mar 28, 2018 at 11:30 AM, Andres Freund wrote:
> Hi,
>
> On 2018-03-28 00:56:10 +, Andrew Dunstan wrote:
>> Fast ALTER TABLE ADD COLUMN with a non-NULL default
>
>> src/backend/executor/execExprInterp.c | 2 +-
>
> I bet this'll break JITed tuple deforming... We'll have to emit
Hi,
On 2018-03-28 00:56:10 +, Andrew Dunstan wrote:
> Fast ALTER TABLE ADD COLUMN with a non-NULL default
> src/backend/executor/execExprInterp.c | 2 +-
I bet this'll break JITed tuple deforming... We'll have to emit a call
to the new slot missingattrs function, instead of using mems
Fast ALTER TABLE ADD COLUMN with a non-NULL default
Currently adding a column to a table with a non-NULL default results in
a rewrite of the table. For large tables this can be both expensive and
disruptive. This patch removes the need for the rewrite as long as the
default value is not volatile.
12 matches
Mail list logo