Em 01-11-2017 18:27, Jeremy Evans escreveu:
On Wednesday, November 1, 2017 at 9:19:17 PM UTC+1, Rodrigo Rosenfeld
Rosas wrote:
Hi Jeremy. Today I moved our PG production database from 9.6.5 to
10. Using pglogical allowed me to upgrade it with minimal downtime.
However, I also had to restart the application itself because of
changes to the OID of pg extensions such as JSON, array and
row_type. Without restarting the application it would read JSON
columns as text, for example.
We serve PG with Docker and stopping the 9.6 container and
restarting the PG 10 container so that it listen in the production
port is so fast that PG would be unreachable for just a second or
so. However, restarting the applications as well will add another
few seconds to the upgrade process, which I'd prefer to avoid if
possible.
So, I'm trying to understand whether it would be possible for
Sequel to detect that the OIDs have changed and re-register those
extensions. I don't actually understand how this part works in
client-side tools such as Sequel's PG support, so I currently have
no suggestions on actual improvements to the code base or API.
Do you think it would be feasible to detect such changes and allow
us to register some proc that would run in such scenario, such as
re-registering those extensions and models?
No, I don't think it is feasible. Certainly I don't think Sequel
would be able to detect OID changes automatically in any efficient
manner. You should restart your application when moving to a new
database if the OIDs have changed. If you really want to handle this
without restarting, you would have to tell Sequel when the OIDs
changed, and reregister all related conversion procs. That is
possible at runtime, but only if you haven't frozen the Database
object. It is recommended that the Database object be frozen in
production and when testing.
Ok, thank you Jeremy. I was just wondering that when you get the data
from some query you would get the oid for the columns and then you'd be
able to detect whenever an OID mapping is missing and some default
mechanism is being used to handle it. In that case, it would be an
opportunity for the application to try to re-register the field types.
This is similar to when we ask Sequel to run something like "select 1"
before any statement to make sure the connection is valid. It adds some
overhead but for many applications we would prefer such an overhead over
an error for each connection in the pool when the database is restarted
for example. The same way, I could live with an overhead of always
checking for OID change whenever an OID is not mapped in the application
if it would allow me to make upgrades quicker.
Anyway, thanks for the prompt response :)
Cheers,
Rodrigo.
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
