"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
>> I think we're probably better off to just forcibly remove the init file
>> during post-recovery cleanup. The easiest place to do this might be
>> BuildFlatFiles, which has to scan pg_database anyway .
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
> I think we're probably better off to just forcibly remove the init file
> during post-recovery cleanup. The easiest place to do this might be
> BuildFlatFiles, which has to scan pg_database anyway ...
Patch enclosed.
Clean apply to HEAD, make
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
>> I don't think this works.
> Surely you are pointing out a bug, no?
> If a backend did crash, the init file would be wrong and we'd get
> exactly the same wrong relfilenode errors we got after that PI
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Enclose a patch for new WAL records for relcache invalidation.
>
> I don't think this works. RelationCacheInitFileInvalidate is executed
> post-commit, which means that there's a window between comm
On Wed, 2006-11-01 at 12:05 -0500, Tom Lane wrote:
> I think we're probably better off to just forcibly remove the init file
> during post-recovery cleanup. The easiest place to do this might be
> BuildFlatFiles, which has to scan pg_database anyway ...
Presumably not rebuilding it, since we can
