Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
debian-packaging/0003-dpkg-buildflags.patch | Add CPPFLAGS in upstream makefiles | Chris Lamb <lamby@debian.org> | no | 2015-10-30 | ||
0001-fix-ftbfs-on-kfreebsd.patch | fix-ftbfs-on-kfreebsd | Chris Lamb <lamby@debian.org> | no | 2015-10-30 | ||
debian-packaging/0007-Set-Debian-configuration-defaults.patch | Set Debian configuration defaults. | Chris Lamb <lamby@debian.org> | not-needed | 2017-10-10 | ||
0010-Use-get_current_dir_name-over-PATHMAX-etc.patch | Use get_current_dir_name over PATHMAX, etc. | Chris Lamb <lamby@debian.org> | no | 2018-01-24 | ||
0010-Add-support-for-USE_SYSTEM_JEMALLOC-flag.patch | Add support for USE_SYSTEM_JEMALLOC flag. https://github.com/antirez/redis/pull/5279 |
Chris Lamb <lamby@debian.org> | no | 2018-08-25 | ||
0011-Add-support-for-a-USE_SYSTEM_LUA-flag.patch | Add support for a USE_SYSTEM_LUA flag. https://github.com/antirez/redis/pull/5280 |
Chris Lamb <lamby@debian.org> | invalid | 2018-08-26 | ||
0007-Add-support-for-a-USE_SYSTEM_HIREDIS-flag.patch | Add support for a USE_SYSTEM_HIREDIS flag. | Chris Lamb <lamby@debian.org> | no | 2018-10-03 | ||
debian-packaging/0008-Ensure-we-use-the-modules-for-third-party-libraries.patch | Ensure we use the modules for third-party libraries. | Chris Lamb <lamby@debian.org> | not-needed | 2018-11-08 | ||
0009-Send-the-readiness-notification-when-we-are-ready-to.patch | Send the readiness notification when we are ready to accept connections On a replica we do accept connections, even though commands accessing the database will operate in read-only mode. But the server is still already operational and processing commands. Not sending the readiness notification means that on a HA setup where the nodes all start as replicas (with replicaof in the config) with a replica that cannot connect to the master server and which might not come back in a predictable amount of time or at all, the service supervisor will end up timing out the service and terminating it, with no option to promote it to be the main instance. This seems counter to what the readiness notification is supposed to be signaling. Instead send the readiness notification when we start accepting commands, and then send the various server status changes as that. |
Guillem Jover <gjover@sipwise.com> | no | 2021-01-19 |