Simon Riggs <simon@2ndQuadrant.com> writes:
> Specifically, should I remove the parts of the HS patch that refresh
> those files?
Yes. This was the last part that I was afraid might have insurmountable
problems. There are some bits yet to do but they're in the nature of
crank-turning, I believe. I think it's a good bet the flat files will
be gone before the next commitfest starts.
BTW, one of the to-do bits is to find another way to initialize the
XID wrap limit at database start. Right now that's set up as a
side-effect of scanning pg_database to create the flat DB file.
The idea I had about it was to store the current wrap limit in
checkpoint WAL records and use the most recent checkpoint's value
as the initial limit. Can you tell me what you're doing about the
wrap limit in HS and whether that solution would be an issue for you?
>> I suspect that
>> this means some things are actively broken during InitPostgres's
>> initial
>> transaction --- for example, if it happens to try to take a lock that
>> completes a deadlock cycle, the deadlock won't be detected because the
>> lock timeout SIGALRM interrupt will never occur. Another example is
>> that SI inval messaging isn't working during InitPostgres either.
> Are we doing anything in the initial transaction that *could* deadlock,
Sure --- we have to take locks to examine system catalogs. Pretty weak
locks mind you, but there's certainly a potential there if someone else
is doing something like a VACUUM FULL on the catalogs.
> or cause an SI inval message?
I don't think InitPostgres could *cause* a SI inval, I was more worried
about whether it would fail to respond to them. The worst case result
is probably a failure of the InitPostgres transaction to notice someone
else's relfilenode reassignment on a system catalog, which would end
up with a "failed to open file" kind of error. Again, the probabilities
aren't very high, but they appear nonzero.
regards, tom lane