Re: database crash during pgbench run
On Tue, Dec 11, 2018 at 10:01 AM Tom Lane wrote: > > Greg Clough writes: > >>> 2018-12-10 19:11:56 IST 23647 LOG: received fast shutdown request > >>> any idea what can cause it ? > > >> Something sent SIGINT to the postmaster. > > > My money is on the OoM (Out of Memory) killer. > > That usually uses SIGKILL. If I had to guess, I'd wonder whether the > postmaster was manually started, and if so whether it was properly > dissociated from the user's terminal (with nohup or the like). > If it wasn't, then a control-C typed at the terminal would SIGINT the > postmaster as well as whatever it was meant to terminate. Yeah. To add to this, pgbench runs are extremely unlikely to cause the kind of memory consumption issues that would trigger an OOM. This is definitely not a database crash, just some kind of administrative problem. Some things that might be helpful to help figure this out: *) What o/s *) how was the database installed *) how exactly did the database start *) are we looking at something exotic here (cloud managed postgres, exotic storage, etc) merlin
psql cli tool and connection pooling
I would love to see a feature on psql cli tool where i can point it to a connection pool provider back end instead of a postgres host. I read that pgpool2 emulates a postgres server, but i've never tried it myself. I know that some languages provide connection pooling, but i'm relying heavily on psql and its features and i think built-in master/slave connection pooling in psql cli would make my day, and that of any other dirty bash scripters out there. Can anyone comment on their experience with pgpool2 in a high activity production environment? Are there other tools or suggestions anyone can point me to? Is there any appetite to support connection pooling natively by either the postmaster or the psql cli or some other device that could be contrib to the source tree? Does it even matter? Is server version 10 ddos-proof, other than max_connections? Thanks.
Re: SQL Perfomance during autovacuum
On Wed, Dec 19, 2018 at 1:04 AM anand086 wrote: > > The Execution time for the above sql is 17841.467 ms during normal > operations but when autovacuum runs on table test_table, the same sql took > 1628495.850 ms (from the postgres log). > > We have noticed this increase in execution times for the sqls only when > autovacuum runs and it runs with prevent wraparound mode. Some competition for resource is to be expected with autovacuum, but making a one-hundred fold difference in run time is rather extreme. I'd suggest that what you have is a locking issue. Something is trying to take a brief Access Exclusive lock on the table. It blocks on the lock held by the autovacuum, and then the Access Share lock needed for your query blocks behind that. Normally an autovacuum will yield the lock when it notices it is blocking something else, but will not do so for wraparound. If you have log_lock_waits turned on, you should see some evidence in the log file if this is the case. Cheers, Jeff
