Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grYno-0007Yg-Cw for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Feb 2019 01:48:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1grYmp-0008ID-31 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Feb 2019 01:47:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grYmo-0008FI-KU for pgsql-hackers@lists.postgresql.org; Thu, 07 Feb 2019 01:47:30 +0000 Received: from mail-it1-x143.google.com ([2607:f8b0:4864:20::143]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1grYmh-0002jZ-BB for pgsql-hackers@lists.postgresql.org; Thu, 07 Feb 2019 01:47:29 +0000 Received: by mail-it1-x143.google.com with SMTP id g85so10972302ita.3 for ; Wed, 06 Feb 2019 17:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hD//bayJbUNkN3QLwyxOcrUj8hHZWdePElh9JAHRud0=; b=vPaNBx7OYWLPZHsx058mmC9bOkEIWelwjRqhhhDMw7BLtNoKXvZKRMgeC5TY7h8RUS /DQrLMmnLuuGOxiv/mqeAN7TaLIOUhopOpz/kGb5g53olnm/07sgGDZA18H9ZtrqLkjK X33pcLcn2Y9CkbVHMNO3A2BfRt4s9j1Q1iX4+hGBOz9vcBIXix02uEj4j2eZQ5mXWruA mo3DOtnkvT+ho4lxFtYod556zY6IQKm2W6JIu5QxrMMsXt3cOc6u79619OBztw+ERK/4 0g2rS+e3MOPAZfZTPmQJ3DuhpVn938ddv6c9pedHqHxG4StgJn1ffkkNy5jXXEVyxNFX uhXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hD//bayJbUNkN3QLwyxOcrUj8hHZWdePElh9JAHRud0=; b=r1iG97AXf1uKzJEYtqMevBW+UJURPyfudNGSzlkchOHidl0cU9m77yFxxJa5TpQOno iqWVAIeLoQ1Usv/a1r/w5oCa15KbtE97x/6xEVIR6E3PRs0gJ50j9dWEK2SwRT/RUqzc qspquL6WZmKEs0UPoqoCVAIw9F6JthYSUEqqCohXe6tdDP9NJblOh7W3I8Uc6XaZrEmH e/q6WxnitM8Pg3+ZDpPe8IgYHMnaRrlXu2qfAgy4lgGIV0r6baI6FaV6A9Ey46B293W0 6W44Wz1ZFm+bHSkpzlsE0E6dEy2bxSV7fi83F2b0nZUHhIGcXD+sbQPXtl9lnPUFKQWN aJmg== X-Gm-Message-State: AHQUAuYrmA2eHv7HlUYeD2LVh8WMXd3AJsNjIMvycVXw0z4gmQXsIRRI iiRjf+v5FwCuTh+/YqKKfmKffg== X-Google-Smtp-Source: AHgI3IbG0nuUHgZcmgg2+HJymw4gWrWMFHunBJhjbw0/kR38wNg3JZ7qJM7oTXgvkYfAIXX5uN8Qhg== X-Received: by 2002:a5e:d808:: with SMTP id l8mr6837505iok.299.1549504041706; Wed, 06 Feb 2019 17:47:21 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s10sm3959293ioc.21.2019.02.06.17.47.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 17:47:20 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id CE43A800BD7; Wed, 6 Feb 2019 19:47:19 -0600 (CST) Date: Wed, 6 Feb 2019 19:47:19 -0600 From: Justin Pryzby To: Thomas Munro Cc: pgsql-hackers@lists.postgresql.org Subject: Re: pg11.1: dsa_area could not attach to segment Message-ID: <20190207014719.GJ29720@telsasoft.com> References: <20190206060137.GW29720@telsasoft.com> <20190206062427.GX29720@telsasoft.com> <20190206063548.GZ29720@telsasoft.com> <20190206070819.GA29720@telsasoft.com> <20190206071940.GB29720@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk FYI, I wasn't yet able to make this work yet. (gdb) print *segment_map->header Cannot access memory at address 0x7f347e554000 However I *did* reproduce the error in an isolated, non-production postgres instance. It's a total empty, untuned v11.1 initdb just for this, running ONLY a few simultaneous loops around just one query It looks like the simultaneous loops sometimes (but not always) fail together. This has happened a couple times. It looks like one query failed due to "could not attach" in leader, one failed due to same in worker, and one failed with "not pinned", which I hadn't seen before and appears to be related to DSM, not DSA... |ERROR: dsa_area could not attach to segment |ERROR: cannot unpin a segment that is not pinned |ERROR: dsa_area could not attach to segment |CONTEXT: parallel worker | |[2] Done while PGHOST=/tmp PGPORT=5678 psql postgres -c "SELECT colcld.child c, parent p, array_agg(colpar.attname::text ORDER BY colpar.attnum) cols, array_agg(format_type(colpar.atttypid, colpar.atttypmod) ORDER BY colpar.attnum) AS types FROM queued_alters qa JOIN pg_attribute colpar ON to_regclass(qa.parent)=colpar.attrelid AND colpar.attnum>0 AND NOT colpar.attisdropped JOIN (SELECT *, attrelid::regclass::text AS child FROM pg_attribute) colcld ON to_regclass(qa.child) =colcld.attrelid AND colcld.attnum>0 AND NOT colcld.attisdropped WHERE colcld.attname=colpar.attname AND colpar.atttypid!=colcld.atttypid GROUP BY 1,2 ORDER BY parent LIKE 'unused%', regexp_replace(colcld.child, '.*_((([0-9]{4}_[0-9]{2})_[0-9]{2})|(([0-9]{6})([0-9]{2})?))$', '\\3\\5') DESC, regexp_replace(colcld.child, '.*_', '') DESC LIMIT 1"; do | :; |done > /dev/null |[5]- Done while PGHOST=/tmp PGPORT=5678 psql postgres -c "SELECT colcld.child c, parent p, array_agg(colpar.attname::text ORDER BY colpar.attnum) cols, array_agg(format_type(colpar.atttypid, colpar.atttypmod) ORDER BY colpar.attnum) AS types FROM queued_alters qa JOIN pg_attribute colpar ON to_regclass(qa.parent)=colpar.attrelid AND colpar.attnum>0 AND NOT colpar.attisdropped JOIN (SELECT *, attrelid::regclass::text AS child FROM pg_attribute) colcld ON to_regclass(qa.child) =colcld.attrelid AND colcld.attnum>0 AND NOT colcld.attisdropped WHERE colcld.attname=colpar.attname AND colpar.atttypid!=colcld.atttypid GROUP BY 1,2 ORDER BY parent LIKE 'unused%', regexp_replace(colcld.child, '.*_((([0-9]{4}_[0-9]{2})_[0-9]{2})|(([0-9]{6})([0-9]{2})?))$', '\\3\\5') DESC, regexp_replace(colcld.child, '.*_', '') DESC LIMIT 1"; do | :; |done > /dev/null |[6]+ Done while PGHOST=/tmp PGPORT=5678 psql postgres -c "SELECT colcld.child c, parent p, array_agg(colpar.attname::text ORDER BY colpar.attnum) cols, array_agg(format_type(colpar.atttypid, colpar.atttypmod) ORDER BY colpar.attnum) AS types FROM queued_alters qa JOIN pg_attribute colpar ON to_regclass(qa.parent)=colpar.attrelid AND colpar.attnum>0 AND NOT colpar.attisdropped JOIN (SELECT *, attrelid::regclass::text AS child FROM pg_attribute) colcld ON to_regclass(qa.child) =colcld.attrelid AND colcld.attnum>0 AND NOT colcld.attisdropped WHERE colcld.attname=colpar.attname AND colpar.atttypid!=colcld.atttypid GROUP BY 1,2 ORDER BY parent LIKE 'unused%', regexp_replace(colcld.child, '.*_((([0-9]{4}_[0-9]{2})_[0-9]{2})|(([0-9]{6})([0-9]{2})?))$', '\\3\\5') DESC, regexp_replace(colcld.child, '.*_', '') DESC LIMIT 1"; do I'm also trying to reproduce on other production servers. But so far nothing else has shown the bug, including the other server which hit our original (other) DSA error with the queued_alters query. So I tentatively think there really may be something specific to the server (not the hypervisor so maybe the OS, libraries, kernel, scheduler, ??). Find the schema for that table here: https://www.postgresql.org/message-id/20181231221734.GB25379%40telsasoft.com Note, for unrelated reasons, that query was also previously discussed here: https://www.postgresql.org/message-id/20171110204043.GS8563%40telsasoft.com Justin