-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: Cannot read property 'name' of null #1105
Comments
I wonder, if the same error would occur within pg-promise, if you follow the example... At least this would help ruling out some reasons of why this is happening... |
@greghart interesting error - any way you could include the query & some data so I could try to reproduce it here? Maybe using |
I'm having a similar issue. For me it seems to be related to parameterized queries.
Do you have any further findings @greghart |
I may have found something promising. I tried to use a new client object with the original in the prototype chain. I did this because I didn't want I did something like this: (using lodash _.create) const new_client = _.create(client, {
release: function () { /* noop */ }
})
new_client.query('SELECT 1') |
Call |
I've been having the same issue but only on my live site, once every few hours. One would then get executed and the second would crash. I haven't been able to replicate this offline. I switched to pg-native and the problem appears to have stopped (over 12 hours with no issues). |
Having this issue. I had switched away from Only happens on first-start. The second time pg is used, the error goes away. The "race" condition is that it happens always at first. So part of our production push right now is to hit the servers ourselves first before we let users use them so they don't get this error. Which is a hack of a fix. Anyone was able to fix this? |
Just had this issue occur with connect-pg-simple configured pretty much as described in the advanced example of https://github.com/voxpelli/node-connect-pg-simple#usage. |
Do any of y'all have a small script I can use that will likely reproduce this? Also are you using @nemo gah that fix is gross - sorry you have to do that. You're using normal |
My application (very rarely) has experienced this problem as well. We have unfortunately been unable to distill it down to a simple script/app that can reliably reproduce, but general observation so far seems to indicate this happens when there is a connection issue with the database. @brianc : I can completely understand the need to be able to reproduce in order to fix - but what are your thoughts on a short term fix to at least check to make sure https://github.com/brianc/node-postgres/blob/master/lib/client.js#L241 indicates access to the |
@andyatmiami - what version of pg & pg-pool are you using? Are you using pg-cursor or pg-query-stream? |
We use parameterized queries exclusively. FWIW: |
Yah that's wretched that its happening. I really hope you can figure out a reproducible test case. I'd also suggest trying with the most recent version of pg & pg-pool. They both received pretty substantial internals upgrades from 6.x -> 7.x & 1.x -> 2.x respectively. |
@brianc : Thanks for responsiveness in issue - will post back any updates/learnings as they come available! |
I get the same error and also sometimes a different stack which I am guessing points to the same root cause
I see there was pull request from @spollack (#961) around this . @spollack, @jshepard it was mentioned in the PR that there was an another library causing this, do you mind sharing your findings ? |
@vedant15 pretty sure we only saw it during statement timeouts. |
ok @jshepard , I am able to reproduce this issue on local (not always), but only when I put a considerable load on the application running queries with statement timeouts . Thanks for all the info ! |
If statement timeouts are causing it I might be able to simulate them locally |
@brianc I added some log statements on my local and whenever I am able to reproduce any of the 2 flavors of this issue, the log statements show the following:
quick question , from the comments in the code, it seems Also, what do you think about checking if |
Yah - any query w/ parameters has a
I feel like that's similar to doing a |
If you can send over a script that smashes a local database w/ lots of load & uses statement timeouts that might be all I need. I've gotten pretty decent at triangulating issues in the connection after all these years. 😝 |
something like: const { Pool } = require('pg')
const async = require('async')
async.times(100000000, function(i, next) {
pool.query('pg_sleep(100)')
pool.query('SELECT $1::text as name', ['foo'], next)
}) or something? I'm missing where to define the statement timeout and if that reproduces the issue in your environment though |
@brianc let me see if I can come up with a script which can reliably reproduce this (reliably being the keyword 😛 ) . I will keep you posted |
sweet - even if i need to run the script for a long time or over and over to reproduce the issue I should be able to work with it and narrow down where things are going amiss |
So .. my initial attempts to recreate it via a script has failed. I will try a couple of ideas to see if I can make it work .. 😞 |
I believe the code I posted above(6 months ago) reproduced the error. Working backward from that may find the root cause. |
@joeandaverde I appreciate what you put above, but it's not quite enough for me to repro easily over here. can you post up a more complete/executable example? neither of your examples above are executable "out of the box" and I'm not sure I follow what "working backwards" entails. |
@daveisfera If you could create a failing test against current master, that would be super helpful. |
I have same problem: pg node: 7.6.1 |
@pankleks when? |
@charmander hard to tell, but probably related to timeout from db. |
After having stumbled into this in our production code, I tried to generate a little script to reproduce. I put the script in https://github.com/timotm/pg-bug . It seems to have something to do with timing as CPU load affects the reproducibility, and on a slower machine it reproduces more often than on a faster machine. (adjusting the number of Running it three times in row in my machine, I got three different errors:
|
With console.log debug technology it seemed that the flow in the crash was something like
I tried ignoring the first ReadyForQuery and only reacting to the second one and could no longer reproduce the null crashes. EDIT: forgot to include server version: |
An interesting observation: after having upgraded the production machine to Also, on a colleague's machine running |
Started getting this error after using the query_timeout config parameter, pg 7.10.0 Repro steps for me, using this config: Steps: lock a table in the database and then issue queries against that table, so that they all time out; doesn't have to be very fast, 1-2 per second will do. I get the crash very quickly, somewhere after around 10 to 100 query timeouts. Other timing information, if it's relevant: the database and node-postgres servers are on separate machines but the ping rtt is very low, 0.5 - 1ms. |
I'm also using query_timeout: [2019-07-11 09:36:36] [ERROR] [pid:8718] TypeError: Cannot read property 'name' of null |
I was experiencing this issue with |
I'm also using Unfortunately, I only encounter this issue when running some automated tests in a docker container ( If it's at all helpful, here's the test code that fails:
Here's a much simplified version of my server code:
The failure happens reliably every time I run the tests, so if there's some places I can add log statements to better track down this problem, I am happy to assist. |
After reading this comment and some more experimentation, I seem to have gotten around this problem by making sure the stream is closed before releasing the connection back to the pool.
I'm not sure where the right place to make the change would be, but it seems like maybe this safeguard could be added to one of the involved libraries ( Also, I feel like it's worth mentioning that I initially got around this error by commenting out this line in |
For those of you catching this with statement timeouts: I was able to reproduce this error consistently when |
I have a PR up for this: #2367. The fix feels dirty to me, but I think what's happening here might be a race condition within postgres itself we're working around. |
FYI @brianc we did see this on postgres 12.3, not 9.x |
@pvatterott that's good to know, but a bummer as my hunch was around a race condition in older versions of postgres. I've been going back and forth w/ some postgres maintainers & think this might fix it. I can confirm it fixes in 9.x & 10.x of postgres, it might fix it for 12.3 of postgres as well. The change involves pipelining the |
Thank you @brianc ! |
@pckilgore my pleasure! Let me know if it still happens...was quite a monster to track down but @timotm is the real hero here. Steps to reproduce & deep analysis helped me know where to focus. I regret it took me so long to circle back to this issue. |
Hello, |
First off, thanks for the library! Overall it's been incredibly performant and straightforward to use. I am running into one issue which may be an issue with the library, though it's a bit hard to follow the protocol for me so my usage may be off as well.
I'm running into an uncaught error during the
parseComplete
handler in client.js (https://github.com/brianc/node-postgres/blob/v6.0.1/lib/client.js#L131).I am doing a direct
connect
against the pool and then utilizing pg-query-streamAt some point during my app's life cycle, I get an uncaught error
So obviously
activeQuery
is becoming null, and I am trying to narrow down why I would receive aparseComplete
event when the active query is null.According to my logs, the stream is not emitting an error, and seems to be closing normally. Therefore it seems like the connection client is getting a
readyForQuery
orend
event, and then right after that getting theparseComplete
event. Any idea why this would be happening, or see any issues with my usage? Thanks for any help you can give! I'll keep looking into it as well.The text was updated successfully, but these errors were encountered: