{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":19347155,"defaultBranch":"master","name":"pg_catcheck","ownerLogin":"EnterpriseDB","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-05-01T14:43:04.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/7386129?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1726765130.0","currentOid":""},"activityList":{"items":[{"before":"7dd4f3246706c6bcd6dc9f829bebc240abf061a7","after":"942c6bc6e015fc5f029222da3c9238eee44fe14c","ref":"refs/heads/master","pushedAt":"2024-09-19T17:16:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rhaas-edb","name":"Robert Haas","path":"/rhaas-edb","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/62960447?s=80&v=4"},"commit":{"message":"Fix assorted compiler warnings.\n\nPer Devrim Gunduz, perform_checks() declares 'tab' in two different\nplaces. Don't do that.\n\nPer my local compiler, 'select_from_relations', 'progname', and\na bunch of things in definitions.c should be marked static, so do\nthat. Doing so revealed that check_collation_oid is altogether unused,\nso remove it.","shortMessageHtmlLink":"Fix assorted compiler warnings."}},{"before":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","after":"7dd4f3246706c6bcd6dc9f829bebc240abf061a7","ref":"refs/heads/master","pushedAt":"2024-07-19T16:39:24.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rhaas-edb","name":"Robert Haas","path":"/rhaas-edb","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/62960447?s=80&v=4"},"commit":{"message":"Include pg_attribute_d.h rather than pg_attribute.h on v17+.\n\nOtherwise, compilation fails, because PostgreSQL commit\nd939cb2fd612acde0304913213cfbdb01994e682 added backend-only code\nto pg_attribute_d.h.\n\nPer report from Rushabh Lathia, but this patch is different from\nhis proposal.","shortMessageHtmlLink":"Include pg_attribute_d.h rather than pg_attribute.h on v17+."}},{"before":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","after":"07e4dc71584814da2f39186fd5cc8b3eb0f98ad1","ref":"refs/heads/dev/FS-7095","pushedAt":"2024-01-30T16:27:06.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jwsapienza","name":"John Sapienza","path":"/jwsapienza","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/98348171?s=80&v=4"},"commit":{"message":"ci(FS-7095): Update blackduck-scan.yml","shortMessageHtmlLink":"ci(FS-7095): Update blackduck-scan.yml"}},{"before":null,"after":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","ref":"refs/heads/dev/FS-7095","pushedAt":"2024-01-30T16:27:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jwsapienza","name":"John Sapienza","path":"/jwsapienza","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/98348171?s=80&v=4"},"commit":{"message":"Avoid running out of memory in the face of large catalog tables.\n\nIf a table has no dependencies (e.g. foreign keys that point to it),\nthen we need not store the catalog data in an in-memory hash table,\nand we can read and check rows one at a time using single-row mode\ninstead of reading the result set all at once. Thus turns out to\nbe faster, because the old coding built a bunch of hash tables that\nwe didn't really need, and it also saves a lot of memory.\n\nTypically, we don't expect catalog tables to be large enough for\nthis to matter, but it could, especially for pg_largeobject.\n\nPatch by Shruthi KC, reviewed by Mahendra Singh Thalor.","shortMessageHtmlLink":"Avoid running out of memory in the face of large catalog tables."}},{"before":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","after":"fa417ed56485c6507b9697b82bd584fe49d0a54e","ref":"refs/heads/dev/FS-7060","pushedAt":"2024-01-30T16:24:17.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jwsapienza","name":"John Sapienza","path":"/jwsapienza","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/98348171?s=80&v=4"},"commit":{"message":"ci(FS-7060): Update trufflehog-scan.yml","shortMessageHtmlLink":"ci(FS-7060): Update trufflehog-scan.yml"}},{"before":null,"after":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","ref":"refs/heads/dev/FS-7060","pushedAt":"2024-01-30T16:24:16.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jwsapienza","name":"John Sapienza","path":"/jwsapienza","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/98348171?s=80&v=4"},"commit":{"message":"Avoid running out of memory in the face of large catalog tables.\n\nIf a table has no dependencies (e.g. foreign keys that point to it),\nthen we need not store the catalog data in an in-memory hash table,\nand we can read and check rows one at a time using single-row mode\ninstead of reading the result set all at once. Thus turns out to\nbe faster, because the old coding built a bunch of hash tables that\nwe didn't really need, and it also saves a lot of memory.\n\nTypically, we don't expect catalog tables to be large enough for\nthis to matter, but it could, especially for pg_largeobject.\n\nPatch by Shruthi KC, reviewed by Mahendra Singh Thalor.","shortMessageHtmlLink":"Avoid running out of memory in the face of large catalog tables."}},{"before":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","after":"43407df898c88afb2bdaff66a1bbf49d22df7833","ref":"refs/heads/dev/FS-7025","pushedAt":"2024-01-30T16:21:33.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jwsapienza","name":"John Sapienza","path":"/jwsapienza","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/98348171?s=80&v=4"},"commit":{"message":"ci(FS-7025): Update sonarqube-scan.yml","shortMessageHtmlLink":"ci(FS-7025): Update sonarqube-scan.yml"}},{"before":null,"after":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","ref":"refs/heads/dev/FS-7025","pushedAt":"2024-01-30T16:21:32.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jwsapienza","name":"John Sapienza","path":"/jwsapienza","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/98348171?s=80&v=4"},"commit":{"message":"Avoid running out of memory in the face of large catalog tables.\n\nIf a table has no dependencies (e.g. foreign keys that point to it),\nthen we need not store the catalog data in an in-memory hash table,\nand we can read and check rows one at a time using single-row mode\ninstead of reading the result set all at once. Thus turns out to\nbe faster, because the old coding built a bunch of hash tables that\nwe didn't really need, and it also saves a lot of memory.\n\nTypically, we don't expect catalog tables to be large enough for\nthis to matter, but it could, especially for pg_largeobject.\n\nPatch by Shruthi KC, reviewed by Mahendra Singh Thalor.","shortMessageHtmlLink":"Avoid running out of memory in the face of large catalog tables."}},{"before":"375f058c901b29a768e806b6de5e46aa76744990","after":"5d3bfc8d8771f6a5d8897748e07e50badeed25fb","ref":"refs/heads/master","pushedAt":"2023-08-28T14:25:57.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rhaas-edb","name":"Robert Haas","path":"/rhaas-edb","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/62960447?s=80&v=4"},"commit":{"message":"Avoid running out of memory in the face of large catalog tables.\n\nIf a table has no dependencies (e.g. foreign keys that point to it),\nthen we need not store the catalog data in an in-memory hash table,\nand we can read and check rows one at a time using single-row mode\ninstead of reading the result set all at once. Thus turns out to\nbe faster, because the old coding built a bunch of hash tables that\nwe didn't really need, and it also saves a lot of memory.\n\nTypically, we don't expect catalog tables to be large enough for\nthis to matter, but it could, especially for pg_largeobject.\n\nPatch by Shruthi KC, reviewed by Mahendra Singh Thalor.","shortMessageHtmlLink":"Avoid running out of memory in the face of large catalog tables."}},{"before":"1dff9505f4f072827338dc491ded1f54a3a24c56","after":"375f058c901b29a768e806b6de5e46aa76744990","ref":"refs/heads/master","pushedAt":"2023-03-22T13:48:01.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"rhaas-edb","name":"Robert Haas","path":"/rhaas-edb","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/62960447?s=80&v=4"},"commit":{"message":"Remove hard dependency on fls().\n\nPrior to PostgreSQL 15, fls() was included in libpgport if not\nprovided by the operating system, allowing pg_catcheck to rely on\nit unconditionally. However, that's no longer true, which causes\ncompilation failures on platforms where fls() is not provided by\nthe OS. Switch to using pg_leftmost_one_pos32() instead when\ncompiling against newer PostgreSQL versions.\n\nRobert Haas and Shruthi KC","shortMessageHtmlLink":"Remove hard dependency on fls()."}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOS0xOVQxNzoxNjowNS4wMDAwMDBazwAAAAS7IpXe","endCursor":"Y3Vyc29yOnYyOpK7MjAyMy0wMy0yMlQxMzo0ODowMS4wMDAwMDBazwAAAAMI44Pl"}},"title":"Activity · EnterpriseDB/pg_catcheck"}