If we don't have a backup-end-location, don't claim we've reached it.
This was apparently a typo, which caused recovery to think that it
immediately reached the end of backup, and allowed the database to start
up too early.
Reported by Jeff Janes. Backpatch to 9.2, where this code was introduced.
If we don't have a backup-end-location, don't claim we've reached it.
This was apparently a typo, which caused recovery to think that it
immediately reached the end of backup, and allowed the database to start
up too early.
Reported by Jeff Janes. Backpatch to 9.2, where this code was introduced.
Split out rmgr rm_desc functions into their own files
This is necessary (but not sufficient) to have them compilable outside
of a backend environment.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/1577b46b7c81e490cf5c8f0e90d0e5d0c09b5414
Modified Files
---
Peter Eisentraut wrote:
> Refactor flex and bison make rules
>
> Numerous flex and bison make rules have appeared in the source tree
> over time, and they are all virtually identical, so we can replace
> them by pattern rules with some variables for customization.
Okapi has been failing sporadica
On 11/28/2012 02:14 PM, Alvaro Herrera wrote:
Peter Eisentraut wrote:
Refactor flex and bison make rules
Numerous flex and bison make rules have appeared in the source tree
over time, and they are all virtually identical, so we can replace
them by pattern rules with some variables for customiz
Andrew Dunstan writes:
> On 11/28/2012 02:14 PM, Alvaro Herrera wrote:
>> Okapi has been failing sporadically on ecpg, and I wonder if it's
>> related to this change.
> Well, it looks like the make is broken and missing a clear dependency
> requirement. I think we need to ask Jeremy to turn off
On 11/28/12 6:01 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 11/28/2012 02:14 PM, Alvaro Herrera wrote:
>>> Okapi has been failing sporadically on ecpg, and I wonder if it's
>>> related to this change.
>
>> Well, it looks like the make is broken and missing a clear dependency
>> requireme
On 11/28/2012 06:01 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/28/2012 02:14 PM, Alvaro Herrera wrote:
Okapi has been failing sporadically on ecpg, and I wonder if it's
related to this change.
Well, it looks like the make is broken and missing a clear dependency
requirement. I think we
Peter Eisentraut writes:
> On 11/28/12 6:01 PM, Tom Lane wrote:
>> I wonder whether adding another .NOTPARALLEL directive would be a better
>> idea than insisting people get hold of patched versions.
> We could put
> ifeq ($(MAKE_VERSION),3.82)
> .NOTPARALLEL:
> endif
> into Makefile.global.
I d
On 11/28/2012 06:19 PM, Tom Lane wrote:
Peter Eisentraut writes:
On 11/28/12 6:01 PM, Tom Lane wrote:
I wonder whether adding another .NOTPARALLEL directive would be a better
idea than insisting people get hold of patched versions.
We could put
ifeq ($(MAKE_VERSION),3.82)
.NOTPARALLEL:
endif
Andrew Dunstan writes:
> On 11/28/2012 06:19 PM, Tom Lane wrote:
>> It appears to me that the case that okapi is hitting is specific to the
>> ecpg preprocessor build rules, and indeed specific to the case where
>> preproc.c needs to be rebuilt. A .NOTPARALLEL in ecpg/preproc/Makefile
>> would pr
Fix assorted bugs in CREATE/DROP INDEX CONCURRENTLY.
Commit 8cb53654dbdb4c386369eb988062d0bbb6de725e, which introduced DROP
INDEX CONCURRENTLY, managed to break CREATE INDEX CONCURRENTLY via a poor
choice of catalog state representation. The pg_index state for an index
that's reached the final pr
Suppress parallel build in interfaces/ecpg/preproc/.
This is to see if it will stop intermittent build failures on buildfarm
member okapi. We know that gmake 3.82 has some problems with sometimes
not honoring dependencies in parallel builds, and it seems likely that
this is more of the same. Sin
13 matches
Mail list logo
