postgrespro / postgres Goto Github PK

This project forked from postgres/postgres

Up-to-date mirror of @postgres with Travis-CI / Appveyor integration and PRs

License: Other

Emacs Lisp 0.01% Makefile 0.70% Shell 0.18% C++ 2.25% SQLPL 0.48% C 83.25% PLpgSQL 6.03% PLSQL 0.02% Perl 2.34% Assembly 0.01% DTrace 0.01% XS 0.02% Python 0.11% Batchfile 0.02% M4 0.24% TSQL 1.71% Yacc 1.36% Lex 0.48% Objective-C 0.51% Ruby 0.26%

postgres's Introduction

PostgreSQL mirror

Involves automatic builds of PRs/commits on Linux (Travis-CI) and Windows (Appveyor):

Linux: full make check-world
Windows: only build + make check

These checks are very similar to cfbot builds.

If you want to verify your patch set before sending it to hackers, then just send a PR with your changes to the branch master_ci from any other postgres fork across GitHub. See example.

Branch master is left intact for convinience. Default branch is master_ci now, but do not push or commit anything there. To update master_ci you should add upstream remote first (you have to do it only once):

git remote add upstream [email protected]:postgres/postgres.git

Then update master branch:

git checkout master
git pull --rebase upstream master
git push -f origin master

And finally update master_ci branch:

git checkout master_ci
git pull --rebase upstream master
git push -f origin master_ci

For original PostgreSQL readme refer to README file.

postgres's People

Contributors

Stargazers

Watchers

Forkers

drrtuy anisimov-ds hartraft yanxuebiao-code lk18347265415 panchukdima

postgres's Issues

Unable to increase max_replication_slots

As of 3947ef5 I get the following while trying to increase max_replication_slots:

postgres@pgtest05f ~ $ psql
psql (9.4.4)
Type "help" for help.

pgtest05f/postgres M # show max_replication_slots ;
 max_replication_slots
-----------------------
 2
(1 row)

Time: 0.433 ms
pgtest05f/postgres M # \q
postgres@pgtest05f ~ $ psql
psql (9.4.4)
Type "help" for help.

pgtest05f/postgres M # alter system set max_replication_slots to 3;
ALTER SYSTEM
Time: 5.309 ms
pgtest05f/postgres M # \q
postgres@pgtest05f ~ $ /usr/pgsql-9.4/bin/pg_ctl stop -m fast -D /var/lib/pgsql/9.4/data/
waiting for server to shut down.... done
server stopped
postgres@pgtest05f ~ $ /usr/pgsql-9.4/bin/pg_ctl start -D /var/lib/pgsql/9.4/data/
server starting
postgres@pgtest05f ~ $ < 2015-10-26 11:43:25.081 MSK >LOG:  registering background worker "pg_stat_wait collector"
< 2015-10-26 11:43:25.082 MSK >LOG:  registering background worker "repl_mon"
< 2015-10-26 11:43:25.461 MSK >FATAL:  no more LWLocks available

postgres@pgtest05f ~ $ vim /var/lib/pgsql/9.4/data/postgresql.auto.conf
postgres@pgtest05f ~ $ /usr/pgsql-9.4/bin/pg_ctl start -D /var/lib/pgsql/9.4/data/
server starting
postgres@pgtest05f ~ $ < 2015-10-26 11:45:04.244 MSK >LOG:  registering background worker "pg_stat_wait collector"
< 2015-10-26 11:45:04.244 MSK >LOG:  registering background worker "repl_mon"
< 2015-10-26 11:45:04.447 MSK >LOG:  redirecting log output to logging collector process
< 2015-10-26 11:45:04.447 MSK >HINT:  Future log output will appear in directory "pg_log".

postgres@pgtest05f ~ $

It does not reproduce with stock 9.4.5.

Segfault with pg_stat_wait_history on replics

pgtest02f/postgres R # show shared_preload_libraries ;
                shared_preload_libraries
---------------------------------------------------------
 pg_stat_statements,pg_stat_kcache,pg_stat_wait,repl_mon
(1 row)

Time: 0.366 ms
pgtest02f/postgres R # select pg_is_in_recovery();
 pg_is_in_recovery
-------------------
 t
(1 row)

Time: 0.715 ms
pgtest02f/postgres R # select * from pg_stat_wait_current ;
  pid  |           sample_ts           | class_id | class_name | event_id | event_name | wait_time | p1 | p2 | p3 | p4 | p5
-------+-------------------------------+----------+------------+----------+------------+-----------+----+----+----+----+----
 28182 | 2015-07-08 11:56:18.611896+03 |        4 | Latch      |        0 | Latch      |    841512 |  0 |  0 |  0 |  0 |  0
 28260 | 2015-07-08 11:56:18.611896+03 |        4 | Latch      |        0 | Latch      |     33178 |  0 |  0 |  0 |  0 |  0
 28259 | 2015-07-08 11:56:18.611896+03 |        4 | Latch      |        0 | Latch      |  29602538 |  0 |  0 |  0 |  0 |  0
 28270 | 2015-07-08 11:56:18.611896+03 |        5 | Network    |        0 | READ       |    763131 |  0 |  0 |  0 |  0 |  0
 28266 | 2015-07-08 11:56:18.611896+03 |        5 | Network    |        0 | READ       |    425323 |  0 |  0 |  0 |  0 |  0
(5 rows)

Time: 5.924 ms
pgtest02f/postgres R # select * from pg_stat_wait_history ;
server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
Time: 831.582 ms
psql: server closed the connection unexpectedly
    This probably means the server terminated abnormally
    before or while processing the request.
pgtest02f/ R >

Here is the backtrace of coredump:

(gdb) bt
#0  SetLatch (latch=0x0) at pg_latch.c:518
#1  0x00007f99c51a8b73 in pg_stat_wait_get_history (fcinfo=0x7ffffedff180) at pg_stat_wait.c:558
#2  0x000000000059ed67 in ExecMakeTableFunctionResult (funcexpr=0x161c630, econtext=0x161be58, argContext=<value optimized out>, expectedDesc=0x161d9e8, randomAccess=0 '\000') at execQual.c:2196
#3  0x00000000005b07f2 in FunctionNext (node=0x161bd48) at nodeFunctionscan.c:95
#4  0x000000000059f94e in ExecScanFetch (node=0x161bd48, accessMtd=0x5b0540 <FunctionNext>, recheckMtd=0x5afe70 <FunctionRecheck>) at execScan.c:82
#5  ExecScan (node=0x161bd48, accessMtd=0x5b0540 <FunctionNext>, recheckMtd=0x5afe70 <FunctionRecheck>) at execScan.c:132
#6  0x0000000000598878 in ExecProcNode (node=0x161bd48) at execProcnode.c:426
#7  0x00000000005b1c19 in ExecSort (node=0x161bad8) at nodeSort.c:103
#8  0x00000000005987e8 in ExecProcNode (node=0x161bad8) at execProcnode.c:468
#9  0x00000000005adc68 in ExecMergeJoin (node=0x15f0a00) at nodeMergejoin.c:730
#10 0x0000000000598818 in ExecProcNode (node=0x15f0a00) at execProcnode.c:453
#11 0x00000000005973e2 in ExecutePlan (queryDesc=0x15f3f90, direction=<value optimized out>, count=0) at execMain.c:1490
#12 standard_ExecutorRun (queryDesc=0x15f3f90, direction=<value optimized out>, count=0) at execMain.c:319
#13 0x00007f99c55b317b in pgss_ExecutorRun (queryDesc=0x15f3f90, direction=ForwardScanDirection, count=0) at pg_stat_statements.c:875
#14 0x000000000068c2d7 in PortalRunSelect (portal=0x1505c10, forward=<value optimized out>, count=0, dest=<value optimized out>) at pquery.c:946
#15 0x000000000068d501 in PortalRun (portal=0x1505c10, count=9223372036854775807, isTopLevel=1 '\001', dest=0x1652f50, altdest=0x1652f50, completionTag=0x7ffffedffa70 "") at pquery.c:790
#16 0x0000000000689b8e in exec_simple_query (query_string=0x14f8f80 "select * from pg_stat_wait_history ;") at postgres.c:1072
#17 0x000000000068b208 in PostgresMain (argc=<value optimized out>, argv=<value optimized out>, dbname=0x14df980 "postgres", username=<value optimized out>) at postgres.c:4074
#18 0x0000000000633fdd in BackendRun (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:4164
#19 BackendStartup (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:3829
#20 ServerLoop (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:1597
#21 PostmasterMain (argc=<value optimized out>, argv=<value optimized out>) at postmaster.c:1244
#22 0x00000000005cbc28 in main (argc=3, argv=0x14deaa0) at main.c:228
(gdb)

This is all happening with waits_monitoring_94 branch.

RAM is being full and updates error

Hello.
I tested new TOAST (https://github.com/postgrespro/postgres/tree/jsonb_toaster) mechanism for jsonb data types. Version (15.1 (Debian 15.1-1.pgdg110+1), server 15beta1). Test table has 6 columns which has jsonb data type.
I was inserting a "large" amount of data (over 1 million) and noticed the session “eats up” the entire RAM. (I saw it in Zabbix monitoring system)

Also, each I run update statement I get the following error:

WARNING: terminating connection because of crash of another server process
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.
HINT: In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

postgrespro / postgres Goto Github PK

postgres's Introduction

PostgreSQL mirror

postgres's People

Contributors

Stargazers

Watchers

Forkers

postgres's Issues

Unable to increase max_replication_slots

Segfault with pg_stat_wait_history on replics

RAM is being full and updates error

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent