On Wed, Jun 26, 2019 at 02:12:55PM +0000, pguser wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, June 26, 2019 2:55 PM, pguser <pgu...@diorite.uk> wrote:‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, June 26, 2019 1:07 PM, Dmitry Dolgov 9erthali...@gmail.com wrote: > > On Wed, Jun 26, 2019 at 1:53 PM pguser pgu...@diorite.uk wrote: > > If I apply the latest patch (which says 1 of 2? - maybe I'm missing a part of the patch?), I apply with > > Hi, > First of all, thanks for evaluation! No problem. I'd like to get involved in helping this patch mature as I think that we're suffering in a few areas of performance due to this. > Could you by any change provide also relations schema that were supposed to be > described by this command? Okay for now, it's not much. I get the issue of the SIGSEGV on a brand new database with only one relation: This is with the 12beta2 as compiled from git sources by me: psql (12beta2) Type "help" for help. db2=> \d List of relations Schema | Name | Type | Owner --------+------+-------+------- e5 | t1 | table | e5 (1 row) db2=> \d t1 Table "e5.t1" Column | Type | Collation | Nullable | Default --------+-------------------+-----------+----------+--------- n1 | smallint | | | n2 | smallint | | | c1 | character varying | | | c2 | character varying | | | Indexes: "i1" btree (n1, n2, c1) And with patch 20 applied: psql (12beta2) Type "help" for help. db2=> \d psql: 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. !> \q [postgres@ip-172-31-33-89 ~]$ . sql2 psql (12beta2) Type "help" for help. db2=> \d t1 psql: 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. !> \q In fact, if I do: createdb db3 psql -d db3 db3=# \d psql: 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. I get this on empty database with no relations yet defined. I feel I have done something silly or missed something when applying patchI find that my patched installation can't create its own initdb either: initdb -D /pgd2 The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale "en_US.UTF-8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are disabled. fixing permissions on existing directory /pgd2 ... ok creating subdirectories ... ok selecting dynamic shared memory implementation ... posix selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting default timezone ... UTC creating configuration files ... ok running bootstrap script ... ok performing post-bootstrap initialization ... 2019-06-26 14:05:47.807 UTC [8120] FATAL: could not open file "base/1/2663.1" (target block 17353008): previous segment is only 4 blocks at character 65 2019-06-26 14:05:47.807 UTC [8120] STATEMENT: INSERT INTO pg_shdepend SELECT 0,0,0,0, tableoid,oid, 'p' FROM pg_authid; child process exited with exit code 1 initdb: removing contents of data directory "/pgd2"
Well, there's something seriously wrong with your build or environment, then. I've tried reproducing the issue, but it works just fine for me (initdb, psql, ...).
I was hoping to share the pgdata between 12beta2 without patch, and 12beta2 with patch, for ease of side by side comparison.
That might be dangerous, if there may be differences in contents of catalogs. I don't think the patch does that though, and for me it works just fine. I can initdb database using current master, create table + indexes, do \d. And I can do that with the patch applied too.
Even more I feel that I'm missing something more than just this 20 patch from the Index Skip Scan thread.
Are you sure this is not some sort of OOM issue? That might also demonstrate as a segfault, in various cases. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
