| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
| Subject: | Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation. |
| Date: | 2013-03-21 20:27:25 |
| Message-ID: | m2r4j8jy6q.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Hmm. Just to be sure I used maintainer-clean and another initdb
> and now I don't see it. If I see it again I'll get a stack trace,
> but for now it's not throwing the error.
It happened to me way too many times to have to do maintainer-clean for
reasons I didn't understand, and I've been told that when it happens,
you have to look at the how the build is done.
It might be useful to talk some more about those strange cases where we
have to maintainer-clean our local copy for things to get back to normal
so that we are able to fix the build scripts down the road.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2013-03-21 23:44:41 | pgsql: Redo postgres_fdw's planner code so it can handle parameterized |
| Previous Message | Kevin Grittner | 2013-03-21 18:15:59 | Re: [COMMITTERS] pgsql: Fix "element <@ range" cost estimation. |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2013-03-21 22:12:24 | Re: Single-argument variant for array_length and friends? |
| Previous Message | Peter Geoghegan | 2013-03-21 19:32:24 | Re: Should commit_delay be PGC_SIGHUP? |