Hi
make check-world fails,
It is fixed in HEAD.
Regards
Pavel
On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake
wrote:
> On 01/07/2016 12:32 PM, Jim Nasby wrote:
>
>> On 1/7/16 1:49 PM, Josh Berkus wrote:
>>
>>> Yeah, we could also get rid of this conversation:
>>>
>>> "Here's a patch for X, which is on the TODO list"
>>>
>>> "Oh,
Attached please find improved version of the optimizer patch for LIMIT clause.
Now I try to apply this optimization only for non-trivial columns requiring
evaluation.
May be it will be better to take in account cost of this columns evaluation but
right now I just detect non-variable columns.
I looked into Karsten Hilbert's report here
http://www.postgresql.org/message-id/20160108114529.gb22...@hermes.hilbert.loc
of being unable to run pg_upgrade on a database containing the pg_trgm
extension. After some investigation, the problem is explained like this:
1. Karsten had installed
2016-01-08 18:45 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-08 18:33 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2016-01-08 17:42 GMT+01:00 Tom Lane :
>>
>>> Pavel Stehule writes:
>>> > make check-world fails,
2016-01-08 18:33 GMT+01:00 Pavel Stehule :
>
>
> 2016-01-08 17:42 GMT+01:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > make check-world fails,
>> > It is fixed in HEAD.
>>
>> Hmm. Apparently when Peter back-patched f16d52269,
[ redirecting from -docs, which isn't the best place to discuss code fixes ]
Whoever thought this was a good idea:
StaticAssertStmt(NAMEDATALEN <= MAX_LEVENSHTEIN_STRLEN,
"Levenshtein hinting mechanism restricts NAMEDATALEN");
is nuts.
A minimal fix that would not put
On Fri, Jan 8, 2016 at 12:05 PM, Tom Lane wrote:
> Whoever thought this was a good idea:
>
> StaticAssertStmt(NAMEDATALEN <= MAX_LEVENSHTEIN_STRLEN,
> "Levenshtein hinting mechanism restricts NAMEDATALEN");
>
> is nuts.
Then I must be nuts.
> A
On 1/8/16 9:07 AM, Tom Lane wrote:
Dunno about that. While a CF manager doesn't necessarily have to have
a commit bit, I think he/she probably does have to be someone who is known
and respected on the -hackers list. Otherwise, nagging to finish patches
is likely to be ignored or even
Artur Zakirov wrote:
> *** 77,83 typedef struct spell_struct
>
> typedef struct aff_struct
> {
> ! uint32 flag:8,
> type:1,
> flagflags:7,
> issimple:1,
> --- 74,80
>
>
Hi,
some of the C functions in the regression test DB readily crash when
passing NULL input values. The regression tests themselves do not pass
NULL values to them, but when the regression database is used as a basis
for fuzz testing, they cause a lot of noise. Maybe someone can sneak
this
Kevin Grittner wrote:
> People have said that issuing SQL commands directly from a TAP test
> via DBD::Pg is not acceptable for a core feature, and (despite
> assertions to the contrary) I see no way to test this feature with
> existing testing mechanisms. The bigger set of work here, if we
>
On 01/09/2016 12:05 AM, Andreas Seltenreich wrote:
Maybe someone can sneak this patch in?
Exactly this is done by a part of another patch, by Michael Paquier,
that he sent to an off-list thread.
Michael had asked for feedback there, but I didn't have the time to test
the patch. Just from
On 1/8/16, Alvaro Herrera wrote:
> Simon Riggs wrote:
>> On 8 January 2016 at 14:14, Vitaly Burovoy
>> wrote:
>>
>> > What about SET NOT NULL constraints? There is no VALIDATE CONSTRAINT
>> > for
>> > it.
>>
>> Sounds like a useful addition.
>
On 12/31/2015 06:34 PM, Petr Jelinek wrote:
Hi,
I'd like to submit the replication solution which is based on the
pglogical_output [1] module (which is obviously needed for this to
compile).
Hi,
make check gives me
for extra in ../../contrib/pglogical_output contrib/pglogical; do make
Vitaly Burovoy wrote:
> I guess you are talking about the other thread[1].
> I'm not sure I have enough experience in Postgres hacking to start
> working on it right now, but I'll have a look.
> IMO the best way is to raise that topic by a letter with summary what
> troubles are left there (in
On 1/8/16, Simon Riggs wrote:
> On 8 January 2016 at 13:13, Vitaly Burovoy
> wrote:
>
>> On 1/8/16, Simon Riggs wrote:
>> > On 8 January 2016 at 12:49, Vitaly Burovoy
>> > wrote:
>> >
>> >
>> >>
Artur Zakirov wrote:
> Now almost all dictionaries are loaded into PostgreSQL. But the da_dk
> dictionary does not load. I see the following error:
>
> ERROR: invalid regular expression: quantifier operand invalid
> CONTEXT: line 439 of configuration file
>
> 7 янв. 2016 г., в 5:26, Michael Paquier
> написал(а):
>
> On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera
> > wrote:
>> Vladimir Borodin wrote:
>>
>>> There are situations in which vacuuming big btree
On 8 January 2016 at 13:13, Vitaly Burovoy wrote:
> On 1/8/16, Simon Riggs wrote:
> > On 8 January 2016 at 12:49, Vitaly Burovoy
> > wrote:
> >
> >
> >> In Postgres9.1 a new feature was implemented [1] for adding PK and
Vladimir Borodin wrote:
>
> > 7 янв. 2016 г., в 5:26, Michael Paquier
> > написал(а):
> >
> > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera
> > > wrote:
> >> Would you please have a look at Simon's patch,
Hello hackers,
I want to implement a new feature that allows to decrease time when
table is under ExclusiveLock on ALTERing new constraints NOT NULL or
CHECK.
In Postgres9.1 a new feature was implemented [1] for adding PK and
UNIQUE constraints using indexes created concurrently, but constraints
On 8 January 2016 at 12:49, Vitaly Burovoy wrote:
> In Postgres9.1 a new feature was implemented [1] for adding PK and
> UNIQUE constraints using indexes created concurrently, but constraints
> NOT NULL and CHECK still require full seqscan of a table. New CHECK
>
On Thu, Jan 7, 2016 at 6:30 PM, Jeff Janes wrote:
> I don't completely agree with that. I have often wanted to know when
> a specific item was added to the TODO page, and/or its individual edit
> history.
Sure, there might be other things it would be better at. But my
On 1/8/16, Simon Riggs wrote:
> On 8 January 2016 at 12:49, Vitaly Burovoy
> wrote:
>
>
>> In Postgres9.1 a new feature was implemented [1] for adding PK and
>> UNIQUE constraints using indexes created concurrently, but constraints
>> NOT NULL and
On 8 January 2016 at 13:36, Alvaro Herrera wrote:
> Vladimir Borodin wrote:
> >
> > > 7 янв. 2016 г., в 5:26, Michael Paquier
> написал(а):
> > >
> > > On Thu, Jan 7, 2016 at 12:20 AM, Alvaro Herrera
> > >
Joe Conway wrote:
> On 07/30/2015 09:51 AM, Tom Lane wrote:
> > Joe Conway writes:
> >> What about just TYPE then?
> >
> >> SELECT x::TYPE(some_expression) FROM ...
> >> SELECT CAST (x AS TYPE(some_expression)) FROM ...
>
> > The main limitation of this patch is that
Hi,
In add_paths_to_joinrel(), the FDW specific hook GetForeignJoinPaths() is
called. This hook if implemented should add ForeignPaths for pushed down
joins. create_plan_recurse() calls create_scan_plan() on seeing these paths.
create_scan_plan() generates a list of clauses to be applied on scan
Magnus Hagander writes:
> On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake
>> There are quite a few contributing companies that likely have people that
>> could help out with this in an educated fashion but aren't coders.
> Sort of like how they
On 1/8/16, Simon Riggs wrote:
> On 8 January 2016 at 13:13, Vitaly Burovoy
> wrote:
>
>> On 1/8/16, Simon Riggs wrote:
>> > On 8 January 2016 at 12:49, Vitaly Burovoy
>> > wrote:
>> >
>> >
>> >>
Simon Riggs wrote:
> On 8 January 2016 at 13:36, Alvaro Herrera wrote:
> > I would agree except for the observation on toast indexes. I think
> > that's an important enough use case that perhaps we should have both.
>
> The exclusion of toast indexes is something we
Simon Riggs wrote:
> On 8 January 2016 at 14:14, Vitaly Burovoy wrote:
>
> > What about SET NOT NULL constraints? There is no VALIDATE CONSTRAINT for
> > it.
>
> Sounds like a useful addition.
Yes. In order to make it a reality you need to make the NOT NULL
>I suspect you need to create a new CF entry for this patch in CF 2016-01.
Unless I am missing something, there seems to be no entry for this patch
into CF 2016-01 page: https://commitfest.postgresql.org/8/.
Regrettably, we have exceeded the deadline to add the patch into this
commitfest. Is
On Fri, Jan 8, 2016 at 4:07 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Jan 7, 2016 at 10:57 PM, Joshua D. Drake
> >> There are quite a few contributing companies that likely have people
> that
> >> could help out
Simon Riggs wrote:
> I think we could do better still, but this looks like the easiest 80% and
> actually removes code.
>
> The lack of substantial comments on the patch is a problem though - the
> details above should go in the patch. I'll have a go at reworking this for
> you, this time.
Is
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > Blind attempt at a Cygwin fix
> >
> > According to
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=brolga=2016-01-08%2014%3A51%3A27
> >
> > brolga now tries to compile win32security.c,
2016-01-08 17:42 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > make check-world fails,
> > It is fixed in HEAD.
>
> Hmm. Apparently when Peter back-patched f16d52269, he missed the 9.5
> branch :-(. I don't have Python 3.5 here, but blindly
Alvaro Herrera writes:
> Joe Conway wrote:
>> On 07/30/2015 09:51 AM, Tom Lane wrote:
>>> The main limitation of this patch is that it won't work for call sites
>>> that pass pstate == NULL to LookupTypeName. There are a fair number
>>> of them, some of which wouldn't
Pavel Stehule writes:
> make check-world fails,
> It is fixed in HEAD.
Hmm. Apparently when Peter back-patched f16d52269, he missed the 9.5
branch :-(. I don't have Python 3.5 here, but blindly pushed the same
patch into 9.5.
regards, tom lane
Tom Lane wrote:
> Alvaro Herrera writes:
> > Blind attempt at a Cygwin fix
>
> According to
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=brolga=2016-01-08%2014%3A51%3A27
>
> brolga now tries to compile win32security.c, which it evidently was not
> doing
Alvaro Herrera writes:
> Alvaro Herrera wrote:
>> Obviously this wasn't the best idea ever. Andrew suggests on IM to
>> revert this on Cygwin to just do the "isatty" check as originally.
> Here's a proposed patch. Thoughts?
Ugly, but it will hold the fort until
41 matches
Mail list logo