Discussion:
postgresql 9.3 -> 9.4
(too old to reply)
Georg Altmann
2015-01-28 19:28:25 UTC
Permalink
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.
Damian Nowak
2015-01-28 19:34:45 UTC
Permalink
Post by Georg Altmann
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
Squall Lionheart
2015-01-28 19:54:17 UTC
Permalink
Post by Damian Nowak
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
Patrick Burroughs (Celti)
2015-01-28 20:17:46 UTC
Permalink
On Wed, 28 Jan 2015 12:54:17 -0700 Squall Lionheart
Post by Squall Lionheart
Post by Damian Nowak
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
Andrej Podzimek
2015-01-28 20:25:48 UTC
Permalink
Post by Squall Lionheart
Post by Damian Nowak
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
Patrick Burroughs (Celti)
2015-01-28 20:42:07 UTC
Permalink
On Wed, 28 Jan 2015 12:25:48 -0800 Andrej Podzimek
Post by Andrej Podzimek
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
Troy Engel
2015-01-29 00:08:47 UTC
Permalink
Post by Patrick Burroughs (Celti)
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
Patrick Burroughs (Celti)
2015-01-29 00:45:26 UTC
Permalink
On Wed, 28 Jan 2015 18:08:47 -0600 Troy Engel <troyengel
Post by Troy Engel
Post by Patrick Burroughs (Celti)
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.
Post by Troy Engel
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
Troy Engel
2015-01-29 01:21:43 UTC
Permalink
Post by Patrick Burroughs (Celti)
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
Georg Altmann
2015-01-29 10:58:38 UTC
Permalink
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
Martti Kühne
2015-01-29 11:15:08 UTC
Permalink
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
Martti Kühne
2015-01-29 12:00:32 UTC
Permalink
Post by Martti Kühne
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
Bardur Arantsson
2015-01-29 13:22:28 UTC
Permalink
Post by Martti Kühne
Post by Martti Kühne
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.)
Post by Martti Kühne
Post by Martti Kühne
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
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,
Martti Kühne
2015-01-29 13:24:01 UTC
Permalink
Post by Bardur Arantsson
Post by Martti Kühne
Post by Martti Kühne
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.)
Post by Martti Kühne
Post by Martti Kühne
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
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
Bardur Arantsson
2015-01-29 13:51:56 UTC
Permalink
Post by Martti Kühne
Post by Bardur Arantsson
Post by Martti Kühne
Post by Martti Kühne
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.)
Post by Martti Kühne
Post by Martti Kühne
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
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.
Don deJuan
2015-01-29 16:40:52 UTC
Permalink
Post by Bardur Arantsson
Post by Martti Kühne
Post by Bardur Arantsson
Post by Martti Kühne
Post by Martti Kühne
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.)
Post by Martti Kühne
Post by Martti Kühne
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
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.
Bardur Arantsson
2015-01-29 16:58:06 UTC
Permalink
Post by Don deJuan
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.
Post by Don deJuan
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.
Post by Don deJuan
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?
Post by Don deJuan
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.
Georg Altmann
2015-01-29 18:01:38 UTC
Permalink
Post by Don deJuan
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
Don deJuan
2015-01-29 18:17:15 UTC
Permalink
Post by Georg Altmann
Post by Don deJuan
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.
Post by Georg Altmann
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
William Gathoye
2015-01-31 01:11:43 UTC
Permalink
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
<***@gathoye.be>
Christian Demsar
2015-01-31 01:20:28 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
Christian Demsar
2015-01-31 01:22:38 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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
n***@netcourrier.com
2015-01-31 08:41:09 UTC
Permalink
Post by William Gathoye
I'm silently following this discussion from the start
...
Post by William Gathoye
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.

Guus Snijders
2015-01-29 22:13:18 UTC
Permalink
Post by Georg Altmann
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
Continue reading on narkive:
Loading...