Fix for cache reference leak warning

[pranavJ23]

Description

Problem: Cache Reference Leaks

1. During the Alter function/procedure we are doing a sys-cache search without releasing it.
2. During the routines-definition, in one case we were not releasing the syscache search.

Fix:
a. To do sys-cache search via tuple and releasing it after the sys-cache search.
b. Also we are generating the logfile but the path that we were giving it github action workflow was not correct, updated
that too.
c. Added a step in jdbc-test workflow which will compare the warnings in logfile with expected warnings

Issues Resolved

[BABEL-5551]

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the Apache 2.0 and PostgreSQL licenses, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.

For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[coveralls]

Pull Request Test Coverage Report for Build 13101407937

Details

• 6 of 8 (75.0%) changed or added relevant lines in 2 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.004%) to 74.945%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
contrib/babelfishpg_tsql/src/pl_handler.c	5	6	83.33%
contrib/babelfishpg_tsql/src/pltsql_ruleutils.c	1	2	50.0%

Files with Coverage Reduction	New Missed Lines	%
contrib/babelfishpg_tsql/src/pltsql_ruleutils.c	1	61.09%
contrib/babelfishpg_tds/src/backend/tds/tdscomm.c	2	76.03%

Totals
Change from base Build 13049387475:	-0.004%
Covered Lines:	47013
Relevant Lines:	62730

---

💛 - Coveralls

[tanscorpio7]

we should use HeapTupleIsValid & curly braces can be removed in next line.

[tanscorpio7]

In case of error we do not need to release syscache

[tanscorpio7]

Some warnings do not contain the word leak but are still important for us & need to be resolved.
For example elog(WARNING, "snapshot %p still active", active);
Will this check be able to catch this WARNING if it comes up in future ?

[pranavJ23]

To grep the warnings which do not contains leak, we need to either grep only "WARNING" or we need to grep the whole line containing "WARNING" keyword.
If we only grep WARNING in the expected-file then while debugging it might be difficult to tell that which type of new warning we are getting.
If we grep whole line containing "WARNING" then there are some reference tuple which might be dynamically allocated during test run, so we cannot compare the expected and actual files.
Open to suggestions!

[sumitj824]

There is one more PG_RETURN_NULL() at line 528, we need to release sys cache there as well.

[sumitj824]

Lets have bash script for this check and you can invoke that script directly.

[sumitj824]

Does this mean that for any new testfile which will generate warnings that are expected will increase this count and everytime developer needs to update this?

[pranavJ23]

Yes if that generates the LEAK or SNAPSHOT warning then only this count will change, for that case developer should check why the warning is generated
If there is some other warning, which is expected we are ignoring them. For a new kind of warning we are saying other unexpected warning