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

test: fix test replication on PG_HEAD #734

Merged
merged 1 commit into from Jan 20, 2017

Conversation

Projects
None yet
5 participants
@jorsol
Contributor

jorsol commented Jan 17, 2017

closes #733

@codecov-io

This comment has been minimized.

Show comment
Hide comment
@codecov-io

codecov-io Jan 17, 2017

Current coverage is 64.22% (diff: 100%)

Merging #734 into master will decrease coverage by 0.01%

@@             master       #734   diff @@
==========================================
  Files           163        163          
  Lines         15142      15142          
  Methods           0          0          
  Messages          0          0          
  Branches       2987       2987          
==========================================
- Hits           9727       9725     -2   
- Misses         4182       4183     +1   
- Partials       1233       1234     +1   

Powered by Codecov. Last update e1a2578...b55beaa

codecov-io commented Jan 17, 2017

Current coverage is 64.22% (diff: 100%)

Merging #734 into master will decrease coverage by 0.01%

@@             master       #734   diff @@
==========================================
  Files           163        163          
  Lines         15142      15142          
  Methods           0          0          
  Messages          0          0          
  Branches       2987       2987          
==========================================
- Hits           9727       9725     -2   
- Misses         4182       4183     +1   
- Partials       1233       1234     +1   

Powered by Codecov. Last update e1a2578...b55beaa

@Gordiychuk

This comment has been minimized.

Show comment
Hide comment
@Gordiychuk

Gordiychuk Jan 17, 2017

Contributor

Maybe fix it as path below?

 #!/usr/bin/env bash
 set -x -e
 
+set_conf_property() {
+    local key=${1}
+    local value=${2}
+
+    sudo sed -i -e "s/#?${key} = .*/${key} = ${value}/g" ${PG_DATADIR}/postgresql.conf
+}
+
 if [ "${REPLICATION}" = "Y" ]
 then
     if [ "${PG_VERSION}" = "HEAD" ]
     then
         PG_VERSION="9.5"
     fi
 
     if (( $(echo "${PG_VERSION} >= 9.1" | bc -l)))
     then
-        sudo sed -i -e 's/#max_wal_senders = 0/max_wal_senders = 4/g' ${PG_DATADIR}/postgresql.conf
-        sudo sed -i -e 's/#wal_keep_segments = 0/wal_keep_segments = 4/g' ${PG_DATADIR}/postgresql.conf
-        sudo sed -i -e 's/#wal_sender_timeout = .*/wal_sender_timeout = 2000/g' ${PG_DATADIR}/postgresql.conf
+        set_conf_property "max_wal_senders" "4"
+        set_conf_property "wal_keep_segments" "4"
+        set_conf_property "wal_sender_timeout" "2000"
         sudo sed -i -e 's/^#local\s\+replication\s\+postgres\s\+\(.*\)/local replication all \1/g' ${PG_DATADIR}/pg_hba.conf
         sudo sed -i -e 's/^#host\s\+replication\s\+postgres\s\+\(.*\)\s\+\(.*\)/host replication all \1 \2/g' ${PG_DATADIR}/pg_hba.conf
         if (( $(echo "${PG_VERSION} >= 9.4" | bc -l)))
         then
-            sudo sed -i -e 's/#wal_level = minimal/wal_level = logical/g' ${PG_DATADIR}/postgresql.conf
-            sudo sed -i -e 's/#max_replication_slots = 0/max_replication_slots = 4/g' ${PG_DATADIR}/postgresql.conf
+            set_conf_property "wal_level" "logical"
+            set_conf_property "max_replication_slots" "4"
         fi
     fi
 fi
Contributor

Gordiychuk commented Jan 17, 2017

Maybe fix it as path below?

 #!/usr/bin/env bash
 set -x -e
 
+set_conf_property() {
+    local key=${1}
+    local value=${2}
+
+    sudo sed -i -e "s/#?${key} = .*/${key} = ${value}/g" ${PG_DATADIR}/postgresql.conf
+}
+
 if [ "${REPLICATION}" = "Y" ]
 then
     if [ "${PG_VERSION}" = "HEAD" ]
     then
         PG_VERSION="9.5"
     fi
 
     if (( $(echo "${PG_VERSION} >= 9.1" | bc -l)))
     then
-        sudo sed -i -e 's/#max_wal_senders = 0/max_wal_senders = 4/g' ${PG_DATADIR}/postgresql.conf
-        sudo sed -i -e 's/#wal_keep_segments = 0/wal_keep_segments = 4/g' ${PG_DATADIR}/postgresql.conf
-        sudo sed -i -e 's/#wal_sender_timeout = .*/wal_sender_timeout = 2000/g' ${PG_DATADIR}/postgresql.conf
+        set_conf_property "max_wal_senders" "4"
+        set_conf_property "wal_keep_segments" "4"
+        set_conf_property "wal_sender_timeout" "2000"
         sudo sed -i -e 's/^#local\s\+replication\s\+postgres\s\+\(.*\)/local replication all \1/g' ${PG_DATADIR}/pg_hba.conf
         sudo sed -i -e 's/^#host\s\+replication\s\+postgres\s\+\(.*\)\s\+\(.*\)/host replication all \1 \2/g' ${PG_DATADIR}/pg_hba.conf
         if (( $(echo "${PG_VERSION} >= 9.4" | bc -l)))
         then
-            sudo sed -i -e 's/#wal_level = minimal/wal_level = logical/g' ${PG_DATADIR}/postgresql.conf
-            sudo sed -i -e 's/#max_replication_slots = 0/max_replication_slots = 4/g' ${PG_DATADIR}/postgresql.conf
+            set_conf_property "wal_level" "logical"
+            set_conf_property "max_replication_slots" "4"
         fi
     fi
 fi
@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 18, 2017

Contributor

Now the problem looks to be on the autorollback tests, any sugestion @Gordiychuk?

Contributor

jorsol commented Jan 18, 2017

Now the problem looks to be on the autorollback tests, any sugestion @Gordiychuk?

@Gordiychuk

This comment has been minimized.

Show comment
Hide comment
@Gordiychuk

Gordiychuk Jan 18, 2017

Contributor

Right now, no. Maybe we can find root cause of move database to recovery mode in /tmp/postgres.log after run tests.

Contributor

Gordiychuk commented Jan 18, 2017

Right now, no. Maybe we can find root cause of move database to recovery mode in /tmp/postgres.log after run tests.

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 18, 2017

Contributor

It looks like is directly a PostgreSQL issue, I get this:

2017-01-18 08:13:25.278 CST [20168] LOG:  server process (PID 23870) was terminated by signal 11: Segmentation fault
2017-01-18 08:13:25.278 CST [20168] LOG:  terminating any other active server processes
2017-01-18 08:13:25.278 CST [20455] WARNING:  terminating connection because of crash of another server process
2017-01-18 08:13:25.278 CST [20455] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2017-01-18 08:13:25.278 CST [20455] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2017-01-18 08:13:25.279 CST [20174] WARNING:  terminating connection because of crash of another server process
2017-01-18 08:13:25.279 CST [20174] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2017-01-18 08:13:25.279 CST [20174] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2017-01-18 08:13:25.280 CST [20168] LOG:  all server processes terminated; reinitializing
2017-01-18 08:13:25.298 CST [23872] LOG:  database system was interrupted; last known up at 2017-01-18 08:11:03 CST

Considering that is a developer preview I guess some bugs can arise. Should we add this to allowed failures? or if everything that is in the master branch of the server should be stable then is a bug that should be reported upstream.

Contributor

jorsol commented Jan 18, 2017

It looks like is directly a PostgreSQL issue, I get this:

2017-01-18 08:13:25.278 CST [20168] LOG:  server process (PID 23870) was terminated by signal 11: Segmentation fault
2017-01-18 08:13:25.278 CST [20168] LOG:  terminating any other active server processes
2017-01-18 08:13:25.278 CST [20455] WARNING:  terminating connection because of crash of another server process
2017-01-18 08:13:25.278 CST [20455] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2017-01-18 08:13:25.278 CST [20455] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2017-01-18 08:13:25.279 CST [20174] WARNING:  terminating connection because of crash of another server process
2017-01-18 08:13:25.279 CST [20174] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2017-01-18 08:13:25.279 CST [20174] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2017-01-18 08:13:25.280 CST [20168] LOG:  all server processes terminated; reinitializing
2017-01-18 08:13:25.298 CST [23872] LOG:  database system was interrupted; last known up at 2017-01-18 08:11:03 CST

Considering that is a developer preview I guess some bugs can arise. Should we add this to allowed failures? or if everything that is in the master branch of the server should be stable then is a bug that should be reported upstream.

@vlsi

This comment has been minimized.

Show comment
Hide comment
@vlsi

vlsi Jan 18, 2017

Member

@jorsol , the idea was to report issues to the upstream

Member

vlsi commented Jan 18, 2017

@jorsol , the idea was to report issues to the upstream

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 18, 2017

Contributor

@vlsi this is the stacktrace that apparently crash the server, I'm lost here and don't know the root cause. will you going to report the issue to upstream?

ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl receiveRFQ
MÁS DETALLADO:  <=BE ReadyForQuery(E)
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl execute
MÁS DETALLADO:   simple execute, handler=org.postgresql.jdbc.PgStatement$StatementResultHandler@21035eec, maxRows=0, fetchSize=0, flags=20
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl sendBind
MÁS DETALLADO:  FE=> Bind(stmt=S_3,portal=null)
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl sendExecute
MÁS DETALLADO:  FE=> Execute(portal=null,limit=1)
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl sendSync
MÁS DETALLADO:  FE=> Sync
ene 18, 2017 11:08:52 AM org.postgresql.jdbc.PgConnection isValid
ADVERTENCIA: Validating connection.
org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:322)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
        at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:136)
        at org.postgresql.jdbc.PgConnection.isValid(PgConnection.java:1303)
        at org.postgresql.test.jdbc2.AutoRollbackTestSuite.run(AutoRollbackTestSuite.java:246)
        at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.junit.runners.Suite.runChild(Suite.java:128)
        at org.junit.runners.Suite.runChild(Suite.java:27)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
        at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.io.EOFException
        at org.postgresql.core.PGStream.receiveChar(PGStream.java:284)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1889)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:295)
        ... 39 more
Contributor

jorsol commented Jan 18, 2017

@vlsi this is the stacktrace that apparently crash the server, I'm lost here and don't know the root cause. will you going to report the issue to upstream?

ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl receiveRFQ
MÁS DETALLADO:  <=BE ReadyForQuery(E)
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl execute
MÁS DETALLADO:   simple execute, handler=org.postgresql.jdbc.PgStatement$StatementResultHandler@21035eec, maxRows=0, fetchSize=0, flags=20
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl sendBind
MÁS DETALLADO:  FE=> Bind(stmt=S_3,portal=null)
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl sendExecute
MÁS DETALLADO:  FE=> Execute(portal=null,limit=1)
ene 18, 2017 11:08:52 AM org.postgresql.core.v3.QueryExecutorImpl sendSync
MÁS DETALLADO:  FE=> Sync
ene 18, 2017 11:08:52 AM org.postgresql.jdbc.PgConnection isValid
ADVERTENCIA: Validating connection.
org.postgresql.util.PSQLException: An I/O error occurred while sending to the backend.
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:322)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
        at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:136)
        at org.postgresql.jdbc.PgConnection.isValid(PgConnection.java:1303)
        at org.postgresql.test.jdbc2.AutoRollbackTestSuite.run(AutoRollbackTestSuite.java:246)
        at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
        at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
        at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.junit.runners.Suite.runChild(Suite.java:128)
        at org.junit.runners.Suite.runChild(Suite.java:27)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
        at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.io.EOFException
        at org.postgresql.core.PGStream.receiveChar(PGStream.java:284)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1889)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:295)
        ... 39 more
@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Jan 18, 2017

Member
Member

davecramer commented Jan 18, 2017

@Gordiychuk

This comment has been minimized.

Show comment
Hide comment
@Gordiychuk

Gordiychuk Jan 18, 2017

Contributor

@davecramer on CI yes. But i can't reproduce it locally.

Contributor

Gordiychuk commented Jan 18, 2017

@davecramer on CI yes. But i can't reproduce it locally.

@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Jan 18, 2017

Member
Member

davecramer commented Jan 18, 2017

@Gordiychuk

This comment has been minimized.

Show comment
Hide comment
@Gordiychuk

Gordiychuk Jan 18, 2017

Contributor

I will try extract core dump from CI

Contributor

Gordiychuk commented Jan 18, 2017

I will try extract core dump from CI

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 18, 2017

Contributor

I can reproduce it locally.

Contributor

jorsol commented Jan 18, 2017

I can reproduce it locally.

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 18, 2017

Contributor

BTW, it's not related to the replication issue so this PR essentially fix the first problem.

Contributor

jorsol commented Jan 18, 2017

BTW, it's not related to the replication issue so this PR essentially fix the first problem.

@Gordiychuk

This comment has been minimized.

Show comment
Hide comment
@Gordiychuk
Contributor

Gordiychuk commented Jan 19, 2017

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 19, 2017

Contributor

@davecramer, @Gordiychuk , I can reproduce the issue locally, and it's not related to the replication, I have disabled replication completely and the error is still there.

I run only AutoRollbackTestSuite and enabled DEBUG messages in postgres and this is what I get:
https://drive.google.com/open?id=0ByHbu-sR29gda2d2LUFpV0lPdUk

Contributor

jorsol commented Jan 19, 2017

@davecramer, @Gordiychuk , I can reproduce the issue locally, and it's not related to the replication, I have disabled replication completely and the error is still there.

I run only AutoRollbackTestSuite and enabled DEBUG messages in postgres and this is what I get:
https://drive.google.com/open?id=0ByHbu-sR29gda2d2LUFpV0lPdUk

@Gordiychuk

This comment has been minimized.

Show comment
Hide comment
@davecramer

This comment has been minimized.

Show comment
Hide comment
@davecramer

davecramer Jan 19, 2017

Member
Member

davecramer commented Jan 19, 2017

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 20, 2017

Contributor

Fix in upstream confirmed: postgres/postgres@ba61a04

Contributor

jorsol commented Jan 20, 2017

Fix in upstream confirmed: postgres/postgres@ba61a04

@jorsol jorsol changed the title from fix: test replication on PG_HEAD to test: fix test replication on PG_HEAD Jan 20, 2017

@jorsol

This comment has been minimized.

Show comment
Hide comment
@jorsol

jorsol Jan 20, 2017

Contributor

This needs to be merged to avoid Travis failing.

Contributor

jorsol commented Jan 20, 2017

This needs to be merged to avoid Travis failing.

@davecramer davecramer merged commit 3b406a1 into pgjdbc:master Jan 20, 2017

2 checks passed

codecov/project Absolute coverage decreased by -0.01% but relative coverage increased by +35.76% compared to e1a2578
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@jorsol jorsol deleted the jorsol:fix-head-replication branch Jan 20, 2017

Gordiychuk added a commit to Gordiychuk/pgjdbc that referenced this pull request Jan 21, 2017

chore: Gather backtrace from core dump on CI
Add script that check health state of postgresql after run tests, because
some tests can lead to fail database with segmentation fault as it was
in pgjdbc#734. For easy debug this scenarios and provide helpfull information to
upstream we need check db state.

Right now health script extract backtrace from core dumps and print logs.
In the future list health checks can be increased.

Example build output https://travis-ci.org/Gordiychuk/pgjdbc/builds/194050719

Closes pgjdbc#735

vlsi added a commit that referenced this pull request Jan 21, 2017

chore: Gather backtrace from core dump on CI (#736)
Add script that check health state of postgresql after run tests, because
some tests can lead to fail database with segmentation fault as it was
in #734. For easy debug this scenarios and provide helpfull information to
upstream we need check db state.

Right now health script extract backtrace from core dumps and print logs.
In the future list health checks can be increased.

Example build output https://travis-ci.org/Gordiychuk/pgjdbc/builds/194050719

Sample output:
The command "./.travis/travis_build.sh" exited with 1.
0.48s$ ./.travis/travis_check_postgres_health.sh
Detected core dump: /etc/postgresql/HEAD/main/core
Reading symbols from /usr/local/pgsql/bin/postgres...done.
[New LWP 16124]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: test test 127.0.0.1(54316) BIND                         '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000007e670d in exec_bind_message (input_message=0x7ffc29a05ee0)
    at postgres.c:1562
1562			(!IsTransactionExitStmt(psrc->raw_parse_tree->stmt) ||
(gdb) #0  0x00000000007e670d in exec_bind_message (input_message=0x7ffc29a05ee0)
    at postgres.c:1562
        portal_name = 0x1e47340 ""
        stmt_name = 0x1e47341 "S_3"

Closes #735
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment