{"action":"created","issue":{"url":"https://api.github.com/repos/greenplum-db/gpdb/issues/5922","repository_url":"https://api.github.com/repos/greenplum-db/gpdb","labels_url":"https://api.github.com/repos/greenplum-db/gpdb/issues/5922/labels{/name}","comments_url":"https://api.github.com/repos/greenplum-db/gpdb/issues/5922/comments","events_url":"https://api.github.com/repos/greenplum-db/gpdb/issues/5922/events","html_url":"https://github.com/greenplum-db/gpdb/pull/5922","id":366554561,"node_id":"MDExOlB1bGxSZXF1ZXN0MjIwMTk5NDY2","number":5922,"title":"Improve Oid sync logic for both QD and QE in wraparound cases","user":{"login":"jimmyyih","id":1973115,"node_id":"MDQ6VXNlcjE5NzMxMTU=","avatar_url":"https://avatars2.githubusercontent.com/u/1973115?v=4","gravatar_id":"","url":"https://api.github.com/users/jimmyyih","html_url":"https://github.com/jimmyyih","followers_url":"https://api.github.com/users/jimmyyih/followers","following_url":"https://api.github.com/users/jimmyyih/following{/other_user}","gists_url":"https://api.github.com/users/jimmyyih/gists{/gist_id}","starred_url":"https://api.github.com/users/jimmyyih/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jimmyyih/subscriptions","organizations_url":"https://api.github.com/users/jimmyyih/orgs","repos_url":"https://api.github.com/users/jimmyyih/repos","events_url":"https://api.github.com/users/jimmyyih/events{/privacy}","received_events_url":"https://api.github.com/users/jimmyyih/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-10-03T22:29:15Z","updated_at":"2018-10-04T16:48:20Z","closed_at":null,"author_association":"MEMBER","pull_request":{"url":"https://api.github.com/repos/greenplum-db/gpdb/pulls/5922","html_url":"https://github.com/greenplum-db/gpdb/pull/5922","diff_url":"https://github.com/greenplum-db/gpdb/pull/5922.diff","patch_url":"https://github.com/greenplum-db/gpdb/pull/5922.patch"},"body":"When Oid count between the QD and QE were not synced as expected, there are\r\ncases where object creation could take a long time due to Oid synchronizing.\r\n\r\nThese are the two that we found:\r\n1. If the QD wrapped around and the QE did not, the QD syncing with the highest\r\nQE Oid counter value could result in a long loop. Additionally, there's a hack\r\nin how the QD advances its Oid counter above the highest QE Oid counter value\r\nwhere it will increment the Oid counter 10 more times to be *safe*. However,\r\nthis hack introduces holes in the Oid count and makes this bug more probable.\r\n2. The QE advances its Oid counter when creating objects with dispatched\r\npre-assigned Oids. If the pre-assigned Oid dispatched by the QD was not from\r\nwraparound and the QE had already wrapped around, it would result in a long\r\nloop for the QE to synchronize with the QD.\r\n\r\nTo prevent long Oid synchronization loops, we add logic to handle wraparound\r\ncases in both QD and QE.\r\n\r\nThis can be easily reproduced by running `pg_resetxlog -o <Oid>` to set the Oid\r\ncounter value on QD and/or QE to simulate the scenarios.\r\n\r\nCo-authored-by: Ekta Khanna <ekhanna@pivotal.io>"},"comment":{"url":"https://api.github.com/repos/greenplum-db/gpdb/issues/comments/427090311","html_url":"https://github.com/greenplum-db/gpdb/pull/5922#issuecomment-427090311","issue_url":"https://api.github.com/repos/greenplum-db/gpdb/issues/5922","id":427090311,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNzA5MDMxMQ==","user":{"login":"hlinnaka","id":191602,"node_id":"MDQ6VXNlcjE5MTYwMg==","avatar_url":"https://avatars2.githubusercontent.com/u/191602?v=4","gravatar_id":"","url":"https://api.github.com/users/hlinnaka","html_url":"https://github.com/hlinnaka","followers_url":"https://api.github.com/users/hlinnaka/followers","following_url":"https://api.github.com/users/hlinnaka/following{/other_user}","gists_url":"https://api.github.com/users/hlinnaka/gists{/gist_id}","starred_url":"https://api.github.com/users/hlinnaka/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hlinnaka/subscriptions","organizations_url":"https://api.github.com/users/hlinnaka/orgs","repos_url":"https://api.github.com/users/hlinnaka/repos","events_url":"https://api.github.com/users/hlinnaka/events{/privacy}","received_events_url":"https://api.github.com/users/hlinnaka/received_events","type":"User","site_admin":false},"created_at":"2018-10-04T16:48:20Z","updated_at":"2018-10-04T16:48:20Z","author_association":"MEMBER","body":"On 04/10/18 19:38, Jimmy Yih wrote:\n> @hlinnaka <https://github.com/hlinnaka> It's possible to write a \n> regression test but there are some weird caveats. To run |pg_resetxlog| \n> to set the Oid counter, the segment has to be shut down first (master in \n> 1st scenario and primary in the 2nd scenario).\n\nAnother option is to write a little helper C function that sets nextOid \nto whatever you want. Something like:\n\nCREATE FUNCTION gp_set_next_oid(new_oid oid) LANGUAGE C AS \n'$libdir/regress.so', 'gp_set_next_oid';\n\nThen you can use that in the tests to set the OID counters on each node \nwhatever you need.\n\nI think we do something similar to that with XIDs, to test XID \nwraparound. Messing with XID counters is a scary (although we do it \nanyway), but setting the OID counter should be pretty safe.\n\n- Heikki\n"}}
{"actor":{"display_login":"hlinnaka"}}