Re: [HACKERS] Possible bug in PostgreSQL 9.2 stable: TwoPhaseGetDummyBackendId()
Robert Ross rr...@translattice.com writes: I have looked at the Postgres 9.2 stable and Postgres 9.2 beta 3 git archives and this bug still appears to be present. TwoPhaseGetDummyProc returns a PGPROC*. In 9.0, it was safe for TwoPhaseGetDummyBackendId() to cast this to a GlobalTransaction because the GlobalTransactionData structure's first element was always a PGPROC structure. However, in 9.2 this is no longer true. Clearly an oversight in commit ed0b409d22346b1b027a4c2099ca66984d94b6dd :-(. Will fix, thanks for the report! regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Possible bug in PostgreSQL 9.2 stable: TwoPhaseGetDummyBackendId()
I have looked at the Postgres 9.2 stable and Postgres 9.2 beta 3 git archives and this bug still appears to be present. TwoPhaseGetDummyProc returns a PGPROC*. In 9.0, it was safe for TwoPhaseGetDummyBackendId() to cast this to a GlobalTransaction because the GlobalTransactionData structure's first element was always a PGPROC structure. However, in 9.2 this is no longer true. Despite the mismatch that now exists between the structures, TwoPhaseGetDummyBackendId() still attempts to cast a PGPROC* to a GlobalTransaction to extract the member 'dummyBackendId'. Rewriting this function to use the GlobalTransaction structure that is found in TwoPhaseState-prepXacts[] appears to fix the problem. In practice this appears to result in TwoPhaseGetDummyBackendId() returning invalid values (such as 0) instead of the expected range above MaxBackends. I'm not sure why this hasn't caused problems with multixact.c's use of this function. Is this a known bug? Would it be helpful to submit a patch? Regards, Robert Ross -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers