Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On Tue, Jun 13, 2017 at 11:14:02AM -0400, Robert Haas wrote: > Also, I think that if we did it that way, it would be significantly > harder to debug. Right now, if something goes boom, you can look at > the old and new clusters and figure out what doesn't match, but if > pg_upgrade renumbered

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On Tue, Jun 13, 2017 at 9:37 AM, Tom Lane wrote: > In the long run, it would certainly be cleaner if pg_upgrade dropped > the force-the-relfilenode-assignment approach and instead remapped > relfilenodes from old cluster to new. But I think it's just for > cleanliness rather

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Robert Haas writes: > The problem is that if a relfilenode ever gets assigned by > GetNewRelFileNode() during a binary-upgrade restore, that OID may turn > out to be used by some other object later in the dump. And then > you're dead, because the dump restore will fail

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On Mon, Jun 12, 2017 at 5:25 PM, Andres Freund wrote: > Even there I don't think that's a sane assumption *for the future*. We > just need a slight change in the rules about when a toast table is needed > - and that stuff seriously need overhauling - and it doesn't work >

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Andres Freund writes: > On 2017-06-12 17:35:37 -0400, Tom Lane wrote: >> I thought about trying to insert an assert in GetNewOidWithIndex to >> ensure that no type OIDs are selected automatically during upgrade, >> but it seemed a bit too complicated. Might be a good idea to

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On 2017-06-12 17:35:37 -0400, Tom Lane wrote: > Andres Freund writes: > > In my opinion the problem of: > > > On 2017-06-12 17:13:34 -0400, Tom Lane wrote: > >> assignments of relfilenodes have to be shortcircuited by pg_upgrade > >> override calls during a binary-restore

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Andres Freund writes: > In my opinion the problem of: > On 2017-06-12 17:13:34 -0400, Tom Lane wrote: >> assignments of relfilenodes have to be shortcircuited by pg_upgrade >> override calls during a binary-restore run, or we risk filename >> collisions. > should instead be

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

On 2017-06-12 17:13:34 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-06-11 20:03:28 -0400, Tom Lane wrote: > >> @@ -391,6 +391,13 @@ GetNewRelFileNode(Oid reltablespace, Rel > >> bool collides; > >> BackendId backend; > >> > >> + /* > >> + * If

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Andres Freund writes: > On 2017-06-11 20:03:28 -0400, Tom Lane wrote: >> @@ -391,6 +391,13 @@ GetNewRelFileNode(Oid reltablespace, Rel >> bool collides; >> BackendIdbackend; >> >> +/* >> + * If we ever get here during pg_upgrade, there's something wrong;

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Hi, On 2017-06-11 20:03:28 -0400, Tom Lane wrote: > I wrote: > > I believe I've identified the reason why skink and some other buildfarm > > members have been failing the pg_upgrade test recently. > > ... > > Not sure what we want to do about it. One idea is to make > > ALTER SEQUENCE not so

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Hi, On 2017-06-11 17:17:07 -0400, Tom Lane wrote: > I am not very sure why it's so hard to duplicate the misbehavior; perhaps, > in order to make the failure happen with the current regression tests, > it's necessary for a background auto-analyze to happen and consume some > OIDs (for

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

Tom Lane wrote: > On closer inspection, the only thing that pg_upgrade needs is to be > able to do ALTER SEQUENCE OWNED BY without a relfilenode bump. PFA > two versions of a patch that fixes this problem, at least to the > extent that it gets through check-world without triggering the Assert >

Re: [HACKERS] Transactional sequence stuff breaks pg_upgrade

I wrote: > I believe I've identified the reason why skink and some other buildfarm > members have been failing the pg_upgrade test recently. > ... > Not sure what we want to do about it. One idea is to make > ALTER SEQUENCE not so transactional when in binary-upgrade mode. On closer inspection,

[HACKERS] Transactional sequence stuff breaks pg_upgrade

I believe I've identified the reason why skink and some other buildfarm members have been failing the pg_upgrade test recently. It is that recent changes in sequence support have caused binary-upgrade restore runs to do some sequence OID/relfilenode assignments without any heed to the OIDs that