> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> ... So there seems
> >> to be a real risk of having a cached copy of one of the pages of a user
> >> index while pg_upgrade is overwriting the index file with new data...
>
> > Oh, I see. That would be a problem.
>
> OK, then what do you think of the idea of changing pg_upgrade to use
> a standalone backend, so that no postmaster is running while it runs?
> That'd eliminate the shared-memory-cache issue and also prevent
> accidental interference from other clients.
>
> There's an awk script in there already that processes the pg_dump
> script, so maybe we could change it to look for \connect commands
> and replace them by re-executions of the backend.
That is risky. How do we know what flags to pass to the stand-alone
backend? In most cases, there is not a backend running after a initdb.
In fact, you can't have postmaster running during initdb. I recommend
they be told in the instructions, and after the pg_upgrade finished to
print something reminding them to start and stop the postmaster.
Because each backend flushes dirty pages on exit, after each psql
finishes, it has already updated the files with dirty pages, so
starting/stopping postmaster will not cause the replaced tables to be
modified, and then the cache will be empty.
> BTW, do you think it's really necessary for the awk script to remove
> COPY commands? There shouldn't be any unwanted copies in there in
> the first place, if the user made the dump with -s per instructions...
But we don't know that they did that. Maybe they found pg_upgrade
_after_ they performed the pg_dump. Very likely.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026