[arch-general] postgresql 9.3 -> 9.4
Hi, There was nothing mentioning a minor realease upgrade or did I miss something? Next time a heads up would be nice, so I know I have to dump and restore beforehand. Thanks! Georg -- PGP-Key: 0x1E320E65 D150 7783 A0D1 7507 1266 C5B3 BBF1 9C42 1E32 0E65 I don't like the idea of secret agencies to analyse and archive personal communication. GnuPG is available as open source, free as as in freedom, as a countermeasure. I use http://www.enigmail.net/ for Mozilla Thunderbird. If you can, please use a frontend of your choice to send me encrypted e-mail. See http://www.gnupg.org/ for an overview.
Next time a heads up would be nice, so I know I have to dump and restore beforehand.
Next time reading pacman -Syu output before hitting Y would be even nicer. ;-) I use IgnorePkg for postgresql and postgresql-libs on my servers. -- -Nowaker www.virtkick.io
Next time reading pacman -Syu output before hitting Y would be even nicer. ;-)
You know what, sometimes their is just so much on the screen to catch all the messages for things like this. I was hit with the same problem and had a server down for almost a day. This should have been posted on the home page with a warning and a link to the Wiki or instructions on how to perform upgrade. Thank you Squall
On Wed, 28 Jan 2015 12:54:17 -0700 Squall Lionheart <headmastersquall@gmail.com> wrote:
Next time reading pacman -Syu output before hitting Y would be even nicer. ;-)
You know what, sometimes their is just so much on the screen to catch all the messages for things like this. I was hit with the same problem and had a server down for almost a day. This should have been posted on the home page with a warning and a link to the Wiki or instructions on how to perform upgrade.
I think there should have been a post-install message — something that catches the eye as opposed to a simple version increment. However, an announcement on the homepage for a completely routine version change, that has happened regularly in the past, is overkill. Regards ~Celti
Next time reading pacman -Syu output before hitting Y would be even nicer. ;-)
You know what, sometimes their is just so much on the screen to catch all the messages for things like this. I was hit with the same problem and had a server down for almost a day. This should have been posted on the home page with a warning and a link to the Wiki or instructions on how to perform upgrade.
I think there should have been a post-install message — something that catches the eye as opposed to a simple version increment. However, an announcement on the homepage for a completely routine version change, that has happened regularly in the past, is overkill.
Well, version changes that require a non-trivial manual intervention are certainly not "routine". There have been many bugfix version updates of PostgreSQL that required no action at all. Those would definitely qualify as "routine". PostgreSQL minor version changes, on the other hand, may be tricky (often requiring a dump and restore) and should be, IMHO, always loudly announced. Cheers, Andrej
On Wed, 28 Jan 2015 12:25:48 -0800 Andrej Podzimek <andrej@podzimek.org> wrote:
Well, version changes that require a non-trivial manual intervention are certainly not "routine". There have been many bugfix version updates of PostgreSQL that required no action at all. Those would definitely qualify as "routine". PostgreSQL minor version changes, on the other hand, may be tricky (often requiring a dump and restore) and should be, IMHO, always loudly announced.
They ARE routine, though. When dealing with databases anything more than a bugfix upgrade is suspect and you should be aware of such. Further, if an upgrade announcement wasn't necessary any time in the past (the only remotely related announcement was regarding a patched security vulnerability in Postgres in 2008), I don't see why one is necessary now. A post-install message is the right place for this. Regards, ~Celti
On Wed, Jan 28, 2015 at 2:42 PM, Patrick Burroughs <celti@celti.name> wrote:
They ARE routine, though. When dealing with databases anything more
Respectfully, they are not routine for what's being discussed. The vendor themselves packages the binaries for each release into separate packaged versions, with each version being a different tree, for all the RPM and DEB distributions to prevent any sort of accidental upgrade from, say, 9.2 to 9.3 because they know it will probably break. It's near impossible to go from 9.2 -> 9.3 -> 9.4 for instance without manual work; for a given 9.x -> 9.y upgrade it might be required to run pg_upgrade as an example task. Having a PGSQL package release that goes from 9.3 to 9.4 seems crazy without letting folks know ahead of time, even if it's a simple mailing list post. (the same is generally true for MySQL 5.1 -> 5.5 -> 5.6, extending to MariaDB) These database vendors do not consider a point release as routine or minor, it's a big deal that requires the admin to possibly perform a bunch of work - update a config file to work out deprecated settings, run something like mysql_upgrade or pg_upgrade to get schema changes and all that stuff. Backups are always good. :) I do agree that PGSQL should have been listed in IgnorePkg as a matter of good systems admin practice, which would have prevented this problem. IMHO you should never let your DB "just upgrade" without meaning for it to happen explicitly - typically you'll need a restart of the service at a minimum, so planning downtime is key for your end users. Every once in awhile a very minor release comes down the pipe that actually breaks something important and you should be ready to roll back on the spot. $0.02, -te
On Wed, 28 Jan 2015 18:08:47 -0600 Troy Engel <troyengel +arch@gmail.com> wrote:
On Wed, Jan 28, 2015 at 2:42 PM, Patrick Burroughs <celti@celti.name> wrote:
They ARE routine, though. When dealing with databases anything more
Respectfully, they are not routine for what's being discussed.
Perhaps we're running into semantic differences. In terms of running database software, upgrades of any sort are not routine. In terms of package management of database software, this is the umpteenth repetition of a minor version upgrade and incredibly routine.
Having a PGSQL package release that goes from 9.3 to 9.4 seems crazy without letting folks know ahead of time, even if it's a simple mailing list post. (the same is generally true for MySQL 5.1 -> 5.5 -> 5.6, extending to MariaDB) These database vendors do not consider a point release as routine or minor, it's a big deal that requires the admin to possibly perform a bunch of work - update a config file to work out deprecated settings, run something like mysql_upgrade or pg_upgrade to get schema changes and all that stuff. Backups are always good. :)
I agree, and a message from pacman as I've multiply stated should be in place seems perfectly sufficient notification to me — you DO read all your messages from pacman, don't you? Regards, ~Celti
On Wed, Jan 28, 2015 at 6:45 PM, Patrick Burroughs <celti@celti.name> wrote:
I agree, and a message from pacman as I've multiply stated should be in place seems perfectly sufficient notification to me — you DO read all your messages from pacman, don't you?
Please keep your passive aggressive personal attacks to yourself. I do not run PGSQL on Arch, I do not run Arch as a server and yes, I do read my pacman output. What *I* was doing was offering a fact-based contrary opinion based on lengthy experience and working in an Enterprise arena that deals with this subject matter directly on a large scale with several distributions. -te
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks like I hit quite a nail here. Let me describe my usecase. I was doing this on my personal box. If it was on a production server, I would have looked three times before doing an upgrade of any kind. I would refrain from having a rolling release distro on a server anyway, but that is another topic. Probably I should have looked at the pacman output more closely. And running a postgresql instance one should know that minor upgrades need a dump and restore. I also think there are people with less experience that are caught unprepared by such a situation. I know arch is for experienced people, but what's the harm of showing a _pre_ upgrade notice anyway? In the end, a distribution and a packaging system should make life easier not harder, right? I humbly propose that for the next postgresql release that needs manual intervention, there should be a _pre_ upgrade notice, clearly saying that manual intervention is needed. It doesn't look like pacman provides this capability though or does it? Regards, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUyhJVAAoJELvxnEIeMg5lGMIIAIwLJSSiBuD5RduqZH9VkaYw YdFhg+L5zVyR3QPx1Hw3F4l0xS5QoGvQG3aZiF14lQhvf4ANlkLahJpZBMa4MRpM eZzJVpSNTNiLDXqpycxn1dD8N2yjvrT4j7Qa/dmropArHdWn14Xy8lg4Q1lBW2vN heLSZgIKL90vd+I3bJFOCxoU92w5tzn9L65Wl3qxW/exLcka/VMVXknp5NOMD0tb 0xXB615r9IOzcMgfaxRDMcuzx5doBS/e/ICNlShG52ZcAPmhCBVAfeHzwQRIIerT D+DCCHl1HQTgzPBIcfxmerlOTmIN4ZWbjIS0Tyj36QFqD2Zv5xYwfa+znOEExDQ= =TNjm -----END PGP SIGNATURE-----
You could also write a pacman wrapper that interferes with pacman's execution upon specific output. Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like. cheers! mar77i
On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne <mysatyre@gmail.com> wrote:
You could also write a pacman wrapper that interferes with pacman's execution upon specific output. Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like.
To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update. cheers! mar77i
On 01/29/2015 01:00 PM, Martti Kühne wrote:
On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne <mysatyre@gmail.com> wrote:
You could also write a pacman wrapper that interferes with pacman's execution upon specific output.
(Doesn't scale to more than one user since nobody else is going to be using that script.)
Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like.
To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update.
Uh, there's a difference between a) We *know* that upgrade X will break your system and/or require manual intervention. and b) We have no specific knowledge that upgrade X will break your system and/or require manual intervention. This was clearly a case of the former and not the latter. The risk tradeoff between doing an upgrade when you know you're in case a) vs. case b) is also drastically different -- though, yes, would could always end up with a broken system even in situation b). I don't see how pacman warning the user explicitly that they're in siutation a) is somehow a huge problem. AFAICT it has also been the practice to post notices at least on archlinux.org for all the breaking updates that that were known of ahead of time. (Obviously, I can't know if that's actually true of things that wouldn't have affected my particular set of installed packages, but...) Georg's request seems eminently sensible to me. If the problem here is that it would be a chore to do this for maintainers for every X.Y -> X.(Y+1) upgrade, then maybe Arch package descriptions could grow a field or flag to handle such things semi-automatically? Maybe something as simple as "if the version number is about to change in *this way*, then warn loudly using *this message*". Regards,
On Thu, Jan 29, 2015 at 2:22 PM, Bardur Arantsson <spam@scientician.net> wrote:
On 01/29/2015 01:00 PM, Martti Kühne wrote:
On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne <mysatyre@gmail.com> wrote:
You could also write a pacman wrapper that interferes with pacman's execution upon specific output.
(Doesn't scale to more than one user since nobody else is going to be using that script.)
Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like.
To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update.
Uh, there's a difference between
a) We *know* that upgrade X will break your system and/or require manual intervention.
and
b) We have no specific knowledge that upgrade X will break your system and/or require manual intervention.
So, my script doesn't scale and your notion of 'we' does? How comes? cheers! mar77i
On 01/29/2015 02:24 PM, Martti Kühne wrote:
On Thu, Jan 29, 2015 at 2:22 PM, Bardur Arantsson <spam@scientician.net> wrote:
On 01/29/2015 01:00 PM, Martti Kühne wrote:
On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne <mysatyre@gmail.com> wrote:
You could also write a pacman wrapper that interferes with pacman's execution upon specific output.
(Doesn't scale to more than one user since nobody else is going to be using that script.)
Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like.
To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update.
Uh, there's a difference between
a) We *know* that upgrade X will break your system and/or require manual intervention.
and
b) We have no specific knowledge that upgrade X will break your system and/or require manual intervention.
So, my script doesn't scale and your notion of 'we' does? How comes?
I think we may have a language barrier -- I have no idea what you're getting at. I said "doesn't scale up to more than one *user*". "We" = package/pacman owners/developers -- this *does* scale to all the users of Arch Linux. Was this not clear? I'm not saying the developers/packagers have infinite reasources, I was pointing out that it might make sense and be worth the effort to implement something (process/pacman support/whatever) which would scale to all the users of Arch Linux and could hopefully be specified in-package once and for all for known cases where upgrades WILL break things.
On 01/29/2015 05:51 AM, Bardur Arantsson wrote:
On 01/29/2015 02:24 PM, Martti Kühne wrote:
On Thu, Jan 29, 2015 at 2:22 PM, Bardur Arantsson <spam@scientician.net> wrote:
On 01/29/2015 01:00 PM, Martti Kühne wrote:
On Thu, Jan 29, 2015 at 12:15 PM, Martti Kühne <mysatyre@gmail.com> wrote:
You could also write a pacman wrapper that interferes with pacman's execution upon specific output. (Doesn't scale to more than one user since nobody else is going to be using that script.)
Then you could have loud warning signals, send emails that get you fired and an automatic backup to the NSA, or NAS, as you like.
To correct myself: It's silly to assume the package that breaks your setup is already on that watchlist. There's only one thing you can do: make sure you have the time to clean up after your update.
Uh, there's a difference between
a) We *know* that upgrade X will break your system and/or require manual intervention.
and
b) We have no specific knowledge that upgrade X will break your system and/or require manual intervention.
So, my script doesn't scale and your notion of 'we' does? How comes?
I think we may have a language barrier -- I have no idea what you're getting at.
I said "doesn't scale up to more than one *user*". "We" = package/pacman owners/developers -- this *does* scale to all the users of Arch Linux. Was this not clear?
I'm not saying the developers/packagers have infinite reasources, I was pointing out that it might make sense and be worth the effort to implement something (process/pacman support/whatever) which would scale to all the users of Arch Linux and could hopefully be specified in-package once and for all for known cases where upgrades WILL break things. From someone who runs Arch in prod on a ton of servers. It was the admins fault. Not arch's not pacman's and not PGSQL's it was the admin.
Running a rolling release in prod requires the ability to pay attention to every detail fully for every action you make. Be accountable for your own mistake. This thread is a joke at this point. The OP messed up by nothing other than his own lack of admining a prod box productively and effectively. This situation would have been avoided if you were on top of your prod box and not just blindly running pacman -Syu. And yes I actually had 0 issues with this update cause I saw it in the queue to install and took the needed steps to avoid the OP's exact situation. Have a screwed up on one of these sure and was never anything more than my own mistake. Whatever happened to self accountability? Know the software you run, dont let the software run you.
On 01/29/2015 05:40 PM, Don deJuan wrote:
From someone who runs Arch in prod on a ton of servers. It was the admins fault. Not arch's not pacman's and not PGSQL's it was the admin.
You might try putting yourself in others' shoes when evaluating their opinions. Not everybody is running Arch in "prod on a ton of servers". Some Arch users are just plain desktop users, or (probably slightly more likely) developers of some type or other. Also, if you're running Arch on a ton of servers, I take it that this is your day job? If so, then it *is* your responsibility to be very sure what you're doing and using canary servers, etc. to make sure nothing gets screwed up on an upgrade. Plus you hopefully get *paid* to do this. You probably also have automation tools to help you do this. This may or may not be typical for users of Arch Linux -- I honestly have no idea.
Running a rolling release in prod requires the ability to pay attention to every detail fully for every action you make.
Certainly, but people make mistakes (or are sometimes just plain non-perfect and non-attentive due to routine) and an extra warning pre-upgrade might be enough to avoid some significant percentage of those mistakes.
Be accountable for your own mistake. This thread is a joke at this point. The OP messed up by nothing other than his own lack of admining a prod box productively and effectively. This situation would have been avoided if you were on top of your prod box and not just blindly running pacman -Syu. And yes I actually had 0 issues with this update cause I saw it in the queue to install and took the needed steps to avoid the OP's exact situation. Have a screwed up on one of these sure and was never anything more than my own mistake. Whatever happened to self accountability?
I think the OP actually admitted that he made a mistake?
Know the software you run, dont let the software run you.
AFAICT, blaming the user for lack of user-friendliness is exactly "let[ting] the software run you". *Shrugs*... As it is this thread has stopped being constructive, so I'm out.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.01.2015 17:40, Don deJuan wrote:
From someone who runs Arch in prod on a ton of servers. It was the admins fault. Not arch's not pacman's and not PGSQL's it was the admin.
Running a rolling release in prod requires the ability to pay attention to every detail fully for every action you make.
Be accountable for your own mistake. This thread is a joke at this point. The OP messed up by nothing other than his own lack of admining a prod box productively and effectively. This situation would have been avoided if you were on top of your prod box and not just blindly running pacman -Syu. And yes I actually had 0 issues with this update cause I saw it in the queue to install and took the needed steps to avoid the OP's exact situation. Have a screwed up on one of these sure and was never anything more than my own mistake. Whatever happened to self accountability? Know the software you run, dont let the software run you.
Look, I don't see what you are getting at here. I am not blaming anyone for anything. I am _not_ running anything like a production environment. Again, this is my personal desktop computer. I cannot spent much time for every update that shows up. And, as I said before, we live in a world where remote security flaws appear almost daily and thus, as a responsible person, you have to update often. It would be nice if the packaging system would support me doing this and not "run me" as it did in this special case. I am merely _suggesting_ to implement a warning message. It certainly _is_ easy to miss something in the "pacman -Suy" output. As such, I think this would be beneficial to everybody running postgresql, be it on a single desktop computer or a farm of servers. Regards, Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUynWBAAoJELvxnEIeMg5lfPIIAILHHZjEJfwiH1xlvOvqYpFC lJbVasAL4XlRtO2FksSqVEw01srwr5YLkKL1/nsQmrm23C8iGD8H5Gt3dFWZSaPt +H+kqa1HyEZuBwNA8ti/u540OaH+kTDeXCS/OfW+WJRhQUtMx/Fu7hT74s0HekDE vOCbNZlQUlvVsAnVeqQnDnxpKpmJsTnjSugLBxSkOnP1Jg2LzsQdaH7+L8UYb/P8 4ToAmUY2JvVSXabLJHOH5VsAftaPOZQnwpK7SBgUVmyKi4a8bsZFhhwM1Xkm2rbd tteKH0/TItgwGnXdOzJ0kZ+9OWgkJmnv6vEGy1bNYVopQks1ebCBfgpTxjySyjI= =HNoY -----END PGP SIGNATURE-----
On 01/29/2015 10:01 AM, Georg Altmann wrote:
On 29.01.2015 17:40, Don deJuan wrote:
From someone who runs Arch in prod on a ton of servers. It was the admins fault. Not arch's not pacman's and not PGSQL's it was the admin.
Running a rolling release in prod requires the ability to pay attention to every detail fully for every action you make.
Be accountable for your own mistake. This thread is a joke at this point. The OP messed up by nothing other than his own lack of admining a prod box productively and effectively. This situation would have been avoided if you were on top of your prod box and not just blindly running pacman -Syu. And yes I actually had 0 issues with this update cause I saw it in the queue to install and took the needed steps to avoid the OP's exact situation. Have a screwed up on one of these sure and was never anything more than my own mistake. Whatever happened to self accountability? Know the software you run, dont let the software run you.
Look, I don't see what you are getting at here. I am not blaming anyone for anything. I am _not_ running anything like a production environment. Again, this is my personal desktop computer. I cannot spent much time for every update that shows up. And, as I said before,
That is the key sentence right there "cannot spent much time for every update" Sounds like Arch is not the most ideal Linux OS for your use case. Arch requires the time and effort personal box or not. And how many home users/admins who have it prod did not have this issue cause they spent the time that IS required to admin an arch install effectively.
we live in a world where remote security flaws appear almost daily and thus, as a responsible person, you have to update often. It would be nice if the packaging system would support me doing this and not "run me" as it did in this special case.
I am merely _suggesting_ to implement a warning message. It certainly _is_ easy to miss something in the "pacman -Suy" output. As such, I think this would be beneficial to everybody running postgresql, be it on a single desktop computer or a farm of servers.
Regards, Georg
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/29/2015 07:01 PM, Georg Altmann wrote:
On 29.01.2015 17:40, Don deJuan wrote: I am merely _suggesting_ to implement a warning message. It certainly _is_ easy to miss something in the "pacman -Suy" output. As such, I think this would be beneficial to everybody running postgresql, be it on a single desktop computer or a farm of servers.
I'm silently following this discussion from the start and I completely agree with this POV. I'm myself a student and I'm sometimes (indirectly) asked to upgrade some servers, and I would have been completely desperate if I broke one because I forgot I was updating a piece of software which was breaking compatibility. This is why, in such case, companies are more willing to use stable distributions than Arch Linux. Thus, big +1 for more warnings in the future. Regards, - -- William Gathoye <william@gathoye.be> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUzCvKAAoJEA595SwE1xaDBK4P/i2w+fUfk07PZaM5HmmxeX/u PqmGtytyQ22cE92/PLpoCgfa629zovPJubAFKzK3V9dRLsTcfN2KqCDUNdjIIlEB NmXhRXMq+Fpag/PtK3k4Hd2jUnVyKKjN+NjdYt5gTlhVOS6Sz/dtNh90SvblQyIY rGZrSJtf+qXY5462rvopDpyeItHHELauIY165LIa4YEJor6Cf5koiIOwb9lOi9wj xFY0B4l27gRBSLpUhRV0LkNa1lLor7PMQ2ARFMyYjle8bE0pGXMO51rURoX3ZUl/ TWpWHQ8Sb4FUYfq2aGwfkPn225/JylExZQjkgqBapKPseiLma09wXd6uK0m+l6q2 Xw70WUoXc0j+/9NUPf0DbY8W2pQTkhgbqieKvjLalnXp+/481+UvOPSMMIWOOkgf qGyWQVa2bWxBaYiAL9wNF2+fh6eeeZ6woZPxpRGW5STQe0SSIRTNqy1M9ce8xIq5 BHRo/tDR4/QPHRCxrHei4GnbpR3ggIggOvIeLv6RotmSQtCC4Of4PNdYS/rux/Ap kdM6yg6mkMQlmDey+KuSlW1C341gbvXccXb73a+d0p/SLn12HDZ6FxF5ciEoy2MY fQMTNbUJkMaMouNDnhV2iDQkxgsJtBmE+8t67sXSrq98jPsi+NW9jcCYLuko78aO hMRzwBdyeIT0vlu8bs7j =/x1g -----END PGP SIGNATURE-----
On Fri, Jan 30, 2015, at 08:11 PM, William Gathoye wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 01/29/2015 07:01 PM, Georg Altmann wrote:
On 29.01.2015 17:40, Don deJuan wrote: I am merely _suggesting_ to implement a warning message. It certainly _is_ easy to miss something in the "pacman -Suy" output. As such, I think this would be beneficial to everybody running postgresql, be it on a single desktop computer or a farm of servers.
I'm silently following this discussion from the start and I completely agree with this POV.
-- vixsomnis
On Fri, Jan 30, 2015, at 08:11 PM, William Gathoye wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 01/29/2015 07:01 PM, Georg Altmann wrote:
On 29.01.2015 17:40, Don deJuan wrote: I am merely _suggesting_ to implement a warning message. It certainly _is_ easy to miss something in the "pacman -Suy" output. As such, I think this would be beneficial to everybody running postgresql, be it on a single desktop computer or a farm of servers.
I'm silently following this discussion from the start and I completely agree with this POV.
I've also been following this discussion. I think having warnings can make upgrades easier without taking any control away from the user. There's already a flag in pacman for disabling interactivity (auto-selecting yes), so that same concept could be used for ignoring any upgrade warnings. -- vixsomnis
Le samedi 31 janvier 2015 02:11:43 William Gathoye a écrit :
I'm silently following this discussion from the start ... Thus, big +1 for more warnings in the future.
One more silent follower : I think it's the DBA's responsibility to know what he's doing when upgrading his box. Blind upgrade of any DB server is faulty. In Arch's Postgresql wiki's page, it's clearly stated that pacman.conf must have IgnorePkg = postgresql postgresql-libs. We cannot blame packaging / warnings / pacman ... here. Test on a lab server before touching a production one. 2c.
2015-01-28 20:28 GMT+01:00 Georg Altmann <george@george-net.de>:
Hi,
There was nothing mentioning a minor realease upgrade or did I miss something?
It's been fun to watch how this thread developed. On the one hand; as admin/owner/root of your machine, you are the one responsible for anything that happens with it. This of course includes reading pacman's output. Then again; it's easy to overlook a single package update. And indeed, an upgrade message might have been nice. On the other hand; if this specific package requires some maintenance on specific updates, one could also turn to tools like logwatch. Combine that with a good package cache (pacman -Sc before -Syu keeps the *currently installed* versions) so rolling back can be done quickly, if necessary. Logwatch can be used to monitor the pacman log and warn you (by e-mail) on updates to certain packages (like postgresql in this case). This would tackle two situations (assuming the DBMS fails after the upgrade): - if the DBMS is needed *right now*; downgrade the package - if it isn't that interesting ATM, the system can still warn you (by e-mail) that some work is needed to restore the DBMS and you get a nice reminder to schedule this action. Just my two cents. mvg, Guus
participants (13)
-
Andrej Podzimek
-
Bardur Arantsson
-
Christian Demsar
-
Damian Nowak
-
Don deJuan
-
Georg Altmann
-
Guus Snijders
-
Martti Kühne
-
nmset＠netcourrier.com
-
Patrick Burroughs
-
Squall Lionheart
-
Troy Engel
-
William Gathoye