Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporary workaround when excessive memory is required by FORMAT fields #1689

Merged
merged 2 commits into from
Dec 5, 2023

Conversation

pd3
Copy link
Member

@pd3 pd3 commented Nov 14, 2023

The BCF limit of ~2GB per VCF row causes the parser to return an error. In this temporary solution we drop the excessive fields, typically these will be PL and other Number=G tags. in future work the library would automatically convert such tags into their localized alternatives (LPL).

The BCF limit of ~2GB per VCF row causes the parser to return an error.
In this temporary solution we drop the excessive fields, typically these
will be PL and other Number=G tags. in future work the library would
automatically convert such tags into their localized alternatives (LPL).
The removal of large tags by d800f13 inadvertently
changed output for invalid rows, such as the one introduced by 8f782d1.
This was caused by relying on fmt->size==0 never happening - such assumption is
correct, I think, but only for valid tags, not such that failed parsing
@whitwham whitwham merged commit b49eea4 into samtools:develop Dec 5, 2023
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants