Closed michaelshobbs closed 2 years ago
@otan @mjibson please let me know if i can be of any more assistance in getting this merged
@otan @mjibson
i know pgx
is the preferred path forward. however, i also know there are many folks still using pq
and this addition would certainly be a value add for those users. please let me know how i can help move this forward.
thank you 🙏
well looks like CI no longer works :\
Yea looks like they deprecated travis-ci.org in favor of travis-ci-com. not sure what needs to happen to move this project over. Let me know if I can help.
Looks like all you have to do is sign up on the .com?
i've tried that and resent the webhooks but no bueno, perhaps try git commit --amend --reset-author -a
and git push --force
your commit to try retrigger it.
i don't have admin permissions to debug this further unfortunately (travis-ci.com doesn't show this repo when i try configure it there), may have to move to a new CI system. /shrug
I was able to add my fork here: https://travis-ci.com/github/michaelshobbs/pq/builds/235721359
I assume that's because I own it. Who is still an admin on this repo? 😬
@otan where did we end up and is there anything i can do to help?
You'd need to find who the admin is :) Idk who it is. Maybe @mjibson knows.
I do not!
Well I think the answer to get CI working (and for me to have confidence in merging) we'd need to migrate to Github Actions. I don't have the time to do this, such is maintenance life :\
FYI I previously tried really hard to make github actions work at https://github.com/lib/pq/commit/8cec54691dd09a5323a614565c97d6622dcad10d. I was never able to get the pg initial configuration files correctly installed before the pg server started running. But that commit is like almost all there.
I was never able to get the pg initial configuration files correctly installed before the pg server started running.
It looks like the scripts should be mounted at /docker-entrypoint-initdb.d
. Those scripts can copy the certs, write conf, createdb
, etc. It looks like you can rely on $PGDATA
rather than hard-coding /var/lib/postgresql/data
, too.
@otan @mjibson i'll give this a look this week
@otan @mjibson can one of you approve me for running workflows?
gotcha
Sweet! I'll start working on this in the morning
Hi! Thank you very much for this PR. Just found out our code has the same problems with cancelling requests from prepared statements. Would be awesome to get this into master ASAP.
Quick update @michaelshobbs. We have tested your patch (just replaced the go.mod to your fork) and it seems still not to work on prepared statements.
Our usecase: add 10sec timeout to context from and send a db query on a prepared statement which last longer, than 1 minute.
@DoubleDi can you provide some code that demonstrates the incorrect behavior? this PR includes canceling statement due to user request
test assertions on stmt.QueryContext()
, and stmt.ExecContext()
. i'd like to better understand where we might be missing something here. thanks 🙏
@michaelshobbs I am not exactly sure, but in some cases, this works. I can see the canceling statement due to user request
error in the logs. But for some reason, we still have long queries, maybe it's an internal problem. I will let you know if I find out anything.
@otan @mjibson https://github.com/lib/pq/pull/1054
@otan @mjibson rebased master. this should be good to go now
@otan thanks! Please also tag a new release
v1.10.3, you have to be a tad more patient than 90s :P
thank you so much!
See #1046 for more context. (pun intended)
This is almost a line for line copy of #921 with test cases (thanks @kylejbrock). Please let me know what else needs to be done to get this merged.
Also dropped ci testing of unsupported versions (9.5 and 9.4) per pg docs here and added ci testing of versions 11, 12, and 13.
closes #921 closes #1046