Re: BUG #15112: Unable to run pg_upgrade with earthdistance extension

On Mon, Apr 02, 2018 at 04:24:02PM -0400, Bruce Momjian wrote: > > I am not sure we can fix this without requiring people to drop and > > recreate such indexes. However, I am even at a loss in how to fix the > > CREATE FUNCTION to reference a cast in the same schema as the function, > > in this ca

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

Summary to date: It's worse than I thought originally, because: - Most widely deployed kernels have cases where they don't tell you about losing your writes at all; and - Information about loss of writes can be masked by closing and re-opening a file So the checkpointer cannot trust that a succ

Excessive PostmasterIsAlive calls slow down WAL redo

I started looking at the "Improve compactify_tuples and PageRepairFragmentation" patch, and set up a little performance test of WAL replay. I ran pgbench, scale 5, to generate about 1 GB of WAL, and timed how long it takes to replay that WAL. To focus purely on CPU overhead, I kept the data dir

Re: [HACKERS] Add support for tuple routing to foreign partitions

Fuiita-san, On 2018/04/05 15:56, Etsuro Fujita wrote: > (2018/04/05 15:37), Amit Langote wrote: >> I noticed that the 2nd patch (foreign-routing-fdwapi-5.patch) fails to >> apply to copy.c: > > I forgot to mention this: the second patch is created on top of the first > patch (postgres-fdw-refacto

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 07:01, Pavan Deolasee wrote: >> +/* >> + * Given OID of the partition leaf, return the index of the leaf in the >> + * partition hierarchy. >> + */ >> +int >> +ExecFindPartitionByOid(PartitionTupleRouting *proute, Oid partoid) >> +{ >> + int i; >> + >> + for (i = 0; i < pro

Re: Postgres stucks in deadlock detection

Hi, Thank for your feedback. On 04.04.2018 21:15, Andres Freund wrote: Hi, On 2018-04-04 11:54:14 +0300, Konstantin Knizhnik wrote: Several times we and our customers are suffered from the problem that Postgres got stuck in deadlock detection. One scenario is YCSB workload with Zipf's distribu

Re: CALL optional in PL/pgSQL

On 27/03/18 03:00, Andrew Dunstan wrote: On Fri, Mar 2, 2018 at 2:01 AM, Tom Lane wrote: I think this is an actively bad idea. It introduces an inherent ambiguity into the grammar; for instance PERFORM (2); now has two valid interpretations. The only way to resolve that is with heu

Re: [HACKERS] path toward faster partition pruning

Hi. On 2018/04/05 0:45, Jesper Pedersen wrote: > Hi, > > On 04/04/2018 09:29 AM, David Rowley wrote: >> Thanks for updating. I've made a pass over v49 and I didn't find very >> much wrong with it. >> >> The only real bug I found was a missing IsA(rinfo->clause, Const) in >> the pseudoconstant che

Re: chained transactions

On 15/03/18 18:39, Alvaro Herrera wrote: From 517bc6d9fefdee9135857d9562f644f2984ace32 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Sun, 18 Feb 2018 09:33:53 -0500 Subject: [PATCH v1 6/8] Turn transaction_isolation into GUC enum XXX no idea why it was done the way it was, but this seem

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On 5 April 2018 at 15:09, Craig Ringer wrote: > Also, it's been reported to me off-list that anyone on the system calling > sync(2) or the sync shell command will also generally consume the write > error, causing us not to see it when we fsync(). The same is true > for /proc/sys/vm/drop_caches.

Re: [HACKERS] logical decoding of two-phase transactions

On 4/5/18 8:50 AM, Nikhil Sontakke wrote: > Hi Tomas, > >> 1) There's a race condition in LogicalLockTransaction. The code does >> roughly this: >> >> if (!BecomeDecodeGroupMember(...)) >> ... bail out ... >> >> Assert(MyProc->decodeGroupLeader); >> lwlock = LockHashPartitionLockByPro

Re: Online enabling of checksums

On Wed, Apr 4, 2018 at 12:11 AM, Tomas Vondra wrote: > On 04/03/2018 02:05 PM, Magnus Hagander wrote: > > On Sun, Apr 1, 2018 at 2:04 PM, Magnus Hagander > > wrote: > > > > On Sat, Mar 31, 2018 at 5:38 PM, Tomas Vondra > > mailto:tomas.von...@2ndquadrant.com>>

Re: [HACKERS] GUC for cleanup indexes threshold.

Hello. The commit leaves three warnings for -Wunused-but-set-variable. Two of them are not assertion-only but really not used at all. I also found that nodeMerge.c has one such variable. regards. At Thu, 5 Apr 2018 15:43:55 +0900, Masahiko Sawada wrote in > On Thu, Apr 5, 2018 at 2:40 PM, Ma

Re: [HACKERS] Add support for tuple routing to foreign partitions

On 2018/04/05 16:31, Amit Langote wrote: > Fuiita-san, Oops, sorry about misspelling your name here, Fujita-san. - Amit

Re: Online enabling of checksums

On 4/5/18 11:07 AM, Magnus Hagander wrote: > > > On Wed, Apr 4, 2018 at 12:11 AM, Tomas Vondra > mailto:tomas.von...@2ndquadrant.com>> wrote: > > ... > > It however still fails to initialize the attempts field after allocating > the db entry in BuildDatabaseList, so if you try running w

Re: pgsql: New files for MERGE

On Wed, Apr 4, 2018 at 3:09 PM, Tom Lane wrote: > Well, what's on the table is reverting this patch and asking you to try > again in the v12 cycle. Given Andres' concerns about the executor design, > and mine about the way the parsing end is built, there's certainly no way > that that's all getti

Re: pgsql: New files for MERGE

On 4 April 2018 at 21:28, Simon Riggs wrote: > On 4 April 2018 at 21:14, Andres Freund wrote: > >>> The normal way is to make review comments that allow change. Your >>> request for change of the parser data structures is fine and can be >>> done, possibly by Saturday >> >> I did request changes,

Re: [HACKERS] GUC for cleanup indexes threshold.

Thanks to everyone, fixes are pushed except nodeMerge.c, I don't wish to increase entropy around MERGE patch :) Kyotaro HORIGUCHI wrote: Hello. The commit leaves three warnings for -Wunused-but-set-variable. Two of them are not assertion-only but really not used at all. I also found that node

Re: [HACKERS] Add support for tuple routing to foreign partitions

(2018/04/05 16:31), Amit Langote wrote: Might be a good idea to attach the bug-fix patch here as well, and perhaps add numbers to the file names like: 0001_postgres-fdw-refactoring-5.patch 0002_BUGFIX-copy-from-check-constraint-fix.patch 0003_foreign-routing-fdwapi-5.patch OK Just one minor

Re: Add support for printing/reading MergeAction nodes

On Wed, Apr 4, 2018 at 11:21 PM, Tom Lane wrote: > Simon Riggs writes: > > On 4 April 2018 at 17:19, Tom Lane wrote: > >> If the MERGE patch has broken this, I'm going to push back on that > >> and push back on it hard, because it probably means there are a > >> whole bunch of other raw-grammar

Get the name of the target Relation from Query struct?

Hello, I want to get the target Relation name for a UPDATE / INSERT / DELETE in a planner_hook. Do I understand struct Query correctly that: Query->resultRelation will be the index into Query->rtable to give me the target Relation? And if yes, what would rtable give me as list entry? An OID or

Re: pgsql: Validate page level checksums in base backups

On Wed, Apr 4, 2018 at 8:22 PM, Michael Banck wrote: > Hi, > > On Wed, Apr 04, 2018 at 07:25:11PM +0200, Magnus Hagander wrote: > > On Wed, Apr 4, 2018 at 3:47 PM, Alvaro Herrera > > wrote: > > > Michael Banck wrote: > > > > > > > However, the pg_basebackup testsuite takes up 800+ MB to run, > >

Re: Add support for printing/reading MergeAction nodes

On 5 April 2018 at 11:31, Pavan Deolasee wrote: > Attached patch refactors the grammar/parser side per your comments. We no > longer use InsertStmt/UpdateStmt/DeleteStmt/SelectStmt as part of > MergeAction. Instead we only collect the necessary information for running > the INSERT/UPDATE/DELETE a

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

somehow you missed some parts in 0001 patch, at least regression tests fail: CREATE EXTENSION btree_gin; + ERROR: could not find function "gin_extract_value_uuid" in file "/usr/local/pgsql/lib/btree_gin.so" Matheus de Oliveira wrote: Hi all. On Wed, Mar 21, 2018 at 1:47 PM, Tomas Vondra

Re: [HACKERS] MERGE SQL Statement for PG11

Hi Simon and Paven, On 04/04/2018 08:46 AM, Jesper Pedersen wrote: On 03/30/2018 07:10 AM, Simon Riggs wrote: No problems found, but moving proposed commit to 2 April pm There is a warning for this, as attached. Updated version due to latest refactoring. Best regards,  Jesper diff --gi

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 12:38, Jesper Pedersen wrote: > Hi Simon and Paven, > > On 04/04/2018 08:46 AM, Jesper Pedersen wrote: >> >> On 03/30/2018 07:10 AM, Simon Riggs wrote: >>> >>> No problems found, but moving proposed commit to 2 April pm >>> >> >> There is a warning for this, as attached. >> > >

Re: [HACKERS] MERGE SQL Statement for PG11

On Thu, Apr 5, 2018 at 5:08 PM, Jesper Pedersen wrote: > Hi Simon and Paven, > > On 04/04/2018 08:46 AM, Jesper Pedersen wrote: > >> On 03/30/2018 07:10 AM, Simon Riggs wrote: >> >>> No problems found, but moving proposed commit to 2 April pm >>> >>> >> There is a warning for this, as attached. >

Re: [HACKERS] MERGE SQL Statement for PG11

Hi, On 04/05/2018 07:48 AM, Simon Riggs wrote: Updated version due to latest refactoring. Thanks for your input. Removing that seems to prevent compilation. Did something change in between? Updated for non-assert build. Best regards, Jesper diff --git a/src/backend/executor/execMerge.c b

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 12:56, Jesper Pedersen wrote: > Hi, > > On 04/05/2018 07:48 AM, Simon Riggs wrote: >>> >>> Updated version due to latest refactoring. >> >> >> Thanks for your input. Removing that seems to prevent compilation. >> >> Did something change in between? >> > > Updated for non-assert

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

Damn, I should have noticed that during the last review, but I missed that somehow. Not sure Matheus will have time to look into it, so here is a (hopefully) fixed version. regards On 4/5/18 1:16 PM, Teodor Sigaev wrote: > somehow you missed some parts in 0001 patch, at least regression tests > f

Re: [HACKERS] MERGE SQL Statement for PG11

The variable would become unused in non-assert builds. I see that. But simply removing it is not a solution and I don't think the code will compile that way. We should either rewrite that assertion or put it inside a #ifdef ASSERT_CHECKING block or simple remove that assertion because we already

Re: [HACKERS] MERGE SQL Statement for PG11

Hi, On 04/05/2018 08:04 AM, Simon Riggs wrote: On 5 April 2018 at 12:56, Jesper Pedersen wrote: Updated for non-assert build. Thanks, pushed. Sorry to have you wait til v3 That patch was a but rushed, and cut off too much. As attached. Best regards, Jesper diff --git a/src/backend/exec

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 13:19, Jesper Pedersen wrote: > Hi, > > On 04/05/2018 08:04 AM, Simon Riggs wrote: >> >> On 5 April 2018 at 12:56, Jesper Pedersen >> wrote: >>> >>> Updated for non-assert build. >> >> >> Thanks, pushed. Sorry to have you wait til v3 >> > > That patch was a but rushed, and cut

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 13:18, Teodor Sigaev wrote: >> The variable would become unused in non-assert builds. I see that. But >> simply removing it is not a solution and I don't think the code will compile >> that way. We should either rewrite that assertion or put it inside a #ifdef >> ASSERT_CHECKING

Re: pgsql: Validate page level checksums in base backups

Hi, On Thu, Apr 05, 2018 at 01:02:27PM +0200, Magnus Hagander wrote: > On Wed, Apr 4, 2018 at 8:22 PM, Michael Banck > wrote: > > Otherwise, I had a quick look and there is no obvious outlier; the > > pgdata is 220 MB after the testrun (195 MB of which is WAL, maybe that > > could be cut down som

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

On Thu, Apr 5, 2018 at 8:16 AM, Teodor Sigaev wrote: > somehow you missed some parts in 0001 patch, at least regression tests > fail: > > CREATE EXTENSION btree_gin; > + ERROR: could not find function "gin_extract_value_uuid" in file > "/usr/local/pgsql/lib/btree_gin.so" > > Ouch... My fault,

typcategory for regconfig

Hi, Does anyone know, why `typcategory` value for tsvector `regconfig` is `TYPCATEGORY_NUMERIC`, but in all the tests it's being used in string format? It's probably not a big deal, but in this thread [1] it prevents me from adopting the nice solution with a boolean flag for `to_tsvector` function

Re: [HACKERS] Runtime Partition Pruning

On 2018/04/05 12:14, Amit Langote wrote: > I will post comments on your v19 later today. I looked at it and here are my thoughts on it after having for the first time looked very closely at it. * Regarding PartitionPruneInfo: I think the names of the fields could be improved -- like pruning_step

Re: Get the name of the target Relation from Query struct?

On 5 April 2018 at 22:34, Ernst-Georg Schmid wrote: > I want to get the target Relation name for a UPDATE / INSERT / DELETE in a > planner_hook. Do I understand struct Query correctly that: > > Query->resultRelation will be the index into Query->rtable to give me the > target Relation? Yes > A

Re: pgsql: Validate page level checksums in base backups

Michael Banck wrote: > Hi, > > Do we have a precedent somewhere for how we do this, or does our test > > framework already have a way to do it? How are all the actual data > > directories etc cleaned up? > > They (and the base backups) are getting purged on success of the whole > testsuite. So to

AW: Get the name of the target Relation from Query struct?

Thank you David, so I am on the right track. >If you want the relation name from the OID then you'll need something >like get_rel_name(). Hm, lsyscache.c says for get_rel_name(): * NOTE: since relation name is not unique, be wary of code that uses this * for anything except preparing error

Re: typcategory for regconfig

Dmitry Dolgov <9erthali...@gmail.com> writes: > Does anyone know, why `typcategory` value for tsvector `regconfig` is > `TYPCATEGORY_NUMERIC`, Because OID is. I think we need all the OID-alias types to be the same category as OID, else we're likely to have issues with queries like ... wh

Query Rewrite for Materialized Views (FDW Extension)

Hi, I wanted to share the project I've been working on which dynamically rewrites queries to target materialized views when views are available that can satisfy part of a query with lower cost plans. I embarked upon as an interesting side project. It took me a bit more time than I anticipated,

Re: [HACKERS] Runtime Partition Pruning

Hi Amit, Thanks for having a look at this. On 6 April 2018 at 00:54, Amit Langote wrote: > I looked at it and here are my thoughts on it after having for the first > time looked very closely at it. > > * Regarding PartitionPruneInfo: > > I think the names of the fields could be improved -- like

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Heikki Linnakangas wrote: > That seems like an utter waste of time. I'm almost inclined to call that a > performance bug. As a straightforward fix, I'd suggest that we call > HandleStartupProcInterrupts() in the WAL redo loop, not on every record, but > only e.g. every 32 records. That would make

Re: typcategory for regconfig

> On 5 April 2018 at 15:27, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: >> Does anyone know, why `typcategory` value for tsvector `regconfig` is >> `TYPCATEGORY_NUMERIC`, > > Because OID is. I think we need all the OID-alias types to be the same > category as OID, else we're l

Re: typcategory for regconfig

Dmitry Dolgov <9erthali...@gmail.com> writes: > On 5 April 2018 at 15:27, Tom Lane wrote: >> I think you need to bite the bullet and just provide the flag in >> the 3-argument case (regconfig,json[b],bool). > Well, it's already like that. I have now: > to_tsvector(json(b), boolean) > to_

Re: Excessive PostmasterIsAlive calls slow down WAL redo

On 5 April 2018 at 08:23, Heikki Linnakangas wrote: > That seems like an utter waste of time. I'm almost inclined to call that a > performance bug. As a straightforward fix, I'd suggest that we call > HandleStartupProcInterrupts() in the WAL redo loop, not on every record, but > only e.g. every 3

Re: Get the name of the target Relation from Query struct?

On 6 April 2018 at 01:20, Ernst-Georg Schmid wrote: >>If you want the relation name from the OID then you'll need something >>like get_rel_name(). > > Hm, lsyscache.c says for get_rel_name(): > > * NOTE: since relation name is not unique, be wary of code that uses this > * for anything except

Re: typcategory for regconfig

> On 5 April 2018 at 15:48, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: >> On 5 April 2018 at 15:27, Tom Lane wrote: >>> I think you need to bite the bullet and just provide the flag in >>> the 3-argument case (regconfig,json[b],bool). > >> Well, it's already like that. I have

Re: WIP: Covering + unique indexes.

On 2018-04-05 00:09, Alexander Korotkov wrote: Hi! Thank you for review! Revised patchset is attached. [0001-Covering-core-v12.patch] [0002-Covering-btree-v12.patch] [0003-Covering-amcheck-v12.patch] [0004-Covering-natts-v12.patch] Really nice performance gains. I read through the docs and m

Re: typcategory for regconfig

Dmitry Dolgov <9erthali...@gmail.com> writes: > On 5 April 2018 at 15:48, Tom Lane wrote: >> Right. So you need to either drop that form, or consider doing >> something other than add-a-bool. Maybe the alternate behavior >> should have a different function name, instead of being selected >> by a

Re: WIP: Covering + unique indexes.

On Thu, Apr 5, 2018 at 5:02 PM, Erik Rijkers wrote: > On 2018-04-05 00:09, Alexander Korotkov wrote: > >> Thank you for review! Revised patchset is attached. >> [0001-Covering-core-v12.patch] >> [0002-Covering-btree-v12.patch] >> [0003-Covering-amcheck-v12.patch] >> [0004-Covering-natts-v12.patc

Re: Flexible configuration for full-text search

Some notices: 0) patch conflicts with last changes in gram.y, conflicts are trivial. 1) jsonb in catalog. I'm ok with it, any opinions? 2) pg_ts_config_map.h, "jsonb mapdicts" isn't decorated with #ifdef CATALOG_VARLEN like other varlena columns in catalog. It it's right, pls, explain a

Re: [HACKERS] path toward faster partition pruning

Amit Langote wrote: > >> 1. Still not sure about RelOptInfo->has_default_part. This flag is > >> only looked at in generate_partition_pruning_steps. The RelOptInfo and > >> the boundinfo is available to look at, it's just that the > >> partition_bound_has_default macro is defined in partition.c ra

Re: WIP: a way forward on bootstrap data

On 4/5/18, Tom Lane wrote: > Here are the results of an evening's desultory hacking on v13. > > [numeric function oids with overloaded name] Thank you for the detailed review and for improving the function references (not to mention the type references I somehow left on the table). I was also not

Re: Online enabling of checksums

> 5 апр. 2018 г., в 14:33, Tomas Vondra > написал(а): > > This patch version seems fine to me. I'm inclined to mark it RFC. +1 The patch works fine for me. I've tried different combinations of backend cancelation and the only suspicious thing I found is that you can start multiple workers by

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin wrote: > > > > 5 апр. 2018 г., в 14:33, Tomas Vondra > написал(а): > > > > This patch version seems fine to me. I'm inclined to mark it RFC. > +1 > The patch works fine for me. I've tried different combinations of backend > cancelation and the only

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

On Wed, 04 Apr 2018 16:07:25 +0300 Marina Polyakova wrote: > Hello, hackers! > > Here there's a seventh version of the patch for error handling and > retrying of transactions with serialization/deadlock failures in > pgbench (based on the commit > a08dc711952081d63577fc182fcf955958f70add). I ad

Re: Online enabling of checksums

> 5 апр. 2018 г., в 19:58, Magnus Hagander написал(а): > > > > On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin wrote: > > > > 5 апр. 2018 г., в 14:33, Tomas Vondra > > написал(а): > > > > This patch version seems fine to me. I'm inclined to mark it RFC. > +1 > The patch works fine for me.

Re: [HACKERS] MERGE SQL Statement for PG11

Quick item: parse_clause.h fails cpluspluscheck because it has a C++ keyword as a function argument name: ./src/include/parser/parse_clause.h:26:14: error: expected ‘,’ or ‘...’ before ‘namespace’ List **namespace); ^ -- Álvaro Herrerahttps://www.2nd

Re: [PATCH] btree_gin, add support for uuid, bool, name, bpchar and anyrange types

Thanks to everyone, first patch is pushed. Range opclass seems unusable because comparing function is close to dummy and BTree opclass is only useful to implement unique check constraint. So, for range it should different index structure to be useful. Matheus de Oliveira wrote: On Thu, Apr

Re: WIP: a way forward on bootstrap data

John Naylor writes: > On 4/5/18, Tom Lane wrote: >> I did not like the hard-wired handling of proargtypes and proallargtypes >> in genbki.pl; it hardly seems impossible that we'll want similar >> conversions for other array-of-OID columns in future. After a bit of >> thought, it seemed like we c

Re: Removing useless DISTINCT clauses

Hi David, The updated patch looks good to me. I've changed the status to "ready for committer" Thanks

Re: json(b)_to_tsvector with numeric values

> On 4 April 2018 at 16:09, Teodor Sigaev wrote: > >>> Hm, seems, it's useful feature, but I suggest to make separate function >>> jsonb_any_to_tsvector and add support for boolean too (if you know better >>> name for function, do not hide it). Changing behavior of existing >>> function >>> is not

Re: [PATCH] Logical decoding of TRUNCATE

On 4/3/18 22:31, Peter Eisentraut wrote: > The problem I see now is that when we WAL-log a truncate, we include all > the relids in one record. That seems useful. But during decoding we > split this into one change per relid. So at the receiving end, truncate > can only process one relation at a

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 16:09, Alvaro Herrera wrote: > Quick item: parse_clause.h fails cpluspluscheck because it has a C++ > keyword as a function argument name: > > ./src/include/parser/parse_clause.h:26:14: error: expected ‘,’ or ‘...’ > before ‘namespace’ >List **namespace); >

Re: [HACKERS] MERGE SQL Statement for PG11

Simon Riggs wrote: > On 5 April 2018 at 16:09, Alvaro Herrera wrote: > > Quick item: parse_clause.h fails cpluspluscheck because it has a C++ > > keyword as a function argument name: > > > > ./src/include/parser/parse_clause.h:26:14: error: expected ‘,’ or ‘...’ > > before ‘namespace’ > >

Re: PATCH: Configurable file mode mask

Hi Michael, On 4/5/18 2:55 AM, Michael Paquier wrote: > On Wed, Apr 04, 2018 at 08:03:54PM -0400, David Steele wrote: > >> Instead I have created variables in file_perm.c >> that hold the current file create mode, dir create mode, and mode mask. >> All call sites use those variables (e.g. pg_dir_

Re: new function for tsquery creartion

Thanks to everyone, pushed with some editorization: 1) translate russian test to prevent potential problems with encoding 2) fix inconsistency 'or cat' and 'cat or', second example doesn't treat OR as lexeme, but first one does. -- Teodor Sigaev E-mail: teo

Re: Allow workers to override datallowconn

On Thu, Mar 29, 2018 at 4:39 PM, Tomas Vondra wrote: > > > On 03/02/2018 12:16 PM, Magnus Hagander wrote: > > On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander > > wrote: > > > > On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane > > wrote: >

Re: [PATCH] Logical decoding of TRUNCATE

This sounds like a good approach. > +static void > +pg_decode_truncate(LogicalDecodingContext *ctx, ReorderBufferTXN *txn, > +int nrelations, Relation relations[], > ReorderBufferChange *change) > +{ > + for (i = 0; i < nrelations; i++) > + { > +

Re: WIP: a way forward on bootstrap data

I experimented with converting all frontend code to include just the catalog/pg_foo_d.h files instead of catalog/pg_foo.h, as per the proposed new policy. I soon found that we'd overlooked one thing: some clients expect to see the relation OID macros, eg LargeObjectRelationId. Attached is a patch

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 5:08 PM, Andrey Borodin wrote: > > > > 5 апр. 2018 г., в 19:58, Magnus Hagander > написал(а): > > > > > > > > On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin > wrote: > > > > > > > 5 апр. 2018 г., в 14:33, Tomas Vondra > написал(а): > > > > > > This patch version seems fi

Re: pgsql: New files for MERGE

On 2018-04-05 06:09:31 -0400, Robert Haas wrote: > On Wed, Apr 4, 2018 at 3:09 PM, Tom Lane wrote: > > Well, what's on the table is reverting this patch and asking you to try > > again in the v12 cycle. Given Andres' concerns about the executor design, > > and mine about the way the parsing end i

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Hi, On 2018-04-05 10:23:43 +0300, Heikki Linnakangas wrote: > Profiling that, without any patches applied, I noticed that a lot of time > was spent in read()s on the postmaster-death pipe, i.e. in > PostmasterIsAlive(). We call that between *every* WAL record. > That seems like an utter waste of

Re: WIP: a way forward on bootstrap data

BTW, I experimented with adding blank lines between the hash items in the .dat files, and that seemed to make a nice improvement in readability, converting masses of rather gray text into visibly distinct stanzas. I'm not dead set on that, but try it and see what you think. A small example from pg

Re: Flexible configuration for full-text search

Hi, On 2018-04-05 17:26:10 +0300, Teodor Sigaev wrote: > Some notices: > > 0) patch conflicts with last changes in gram.y, conflicts are trivial. > > 1) jsonb in catalog. I'm ok with it, any opinions? > > 2) pg_ts_config_map.h, "jsonb mapdicts" isn't decorated with #ifdef > CATALOG_VARLEN

Re: Excessive PostmasterIsAlive calls slow down WAL redo

Andres Freund writes: > ISTM the better approach would be to try to reduce the cost of > PostmasterIsAlive() on common platforms - it should be nearly free if > done right. +1 if it's doable. > One way to achieve that would e.g. to stop ignoring SIGPIPE and instead > check for postmaster death i

Re: some last patches breaks plan cache

On 4/4/18 14:03, Tomas Vondra wrote: >> If there's really no other way, you could use a PG_TRY block to >> ensure that the pointer gets reset on the way out. But I question >> why we've got a design that requires that in the first place. It's >> likely to have more problems than this. > > I agree

Re: Parallel Aggregates for string_agg and array_agg

Moin, On Wed, April 4, 2018 11:41 pm, David Rowley wrote: > Hi Tomas, > > Thanks for taking another look. > > On 5 April 2018 at 07:12, Tomas Vondra > wrote: >> Other than that, the patch seems fine to me, and it's already marked as >> RFC so I'll leave it at that. > > Thanks. I have one more co

Re: [HACKERS] MERGE SQL Statement for PG11

On 5 April 2018 at 17:07, Alvaro Herrera wrote: > Simon Riggs wrote: >> On 5 April 2018 at 16:09, Alvaro Herrera wrote: >> > Quick item: parse_clause.h fails cpluspluscheck because it has a C++ >> > keyword as a function argument name: >> > >> > ./src/include/parser/parse_clause.h:26:14: error: e

Re: Excessive PostmasterIsAlive calls slow down WAL redo

On 2018-04-05 14:39:27 -0400, Tom Lane wrote: > Andres Freund writes: > > ISTM the better approach would be to try to reduce the cost of > > PostmasterIsAlive() on common platforms - it should be nearly free if > > done right. > > +1 if it's doable. > > > One way to achieve that would e.g. to st

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 2018-04-04 22:10:06 -0700, David G. Johnston wrote: > On Wednesday, April 4, 2018, Amit Kapila wrote: > > > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > > > > > > > > Questions: > > > > > > - I'm not perfectly happy with > > > "tuple to be locked was already moved to another parti

Re: SET TRANSACTION in PL/pgSQL

On 4/4/18 13:53, Tomas Vondra wrote: >> Here is the same patch rewritten using SPI, using the new no_snapshots >> facility recently introduced. > > Yeah, doing that using SPI seems much cleaner and more like the rest of > the commands. Most of the patch is boilerplate to support the grammar, > and

Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS

On Thu, Apr 5, 2018 at 03:09:57PM +0800, Craig Ringer wrote: > ENOSPC doesn't seem to be a concern during normal operation of major file > systems (ext3, ext4, btrfs, xfs) because they reserve space before returning > from write(). But if a buffered write does manage to fail due to ENOSPC we'll >

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

Pavan Deolasee wrote: > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > + /* > +* As long as we don't support an UPDATE of INSERT ON CONFLICT for > +* a partitioned table we shouldn't reach to a case where tuple to > +* be lock is moved to anot

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On 2018-04-05 10:17:59 +0530, Amit Kapila wrote: > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund wrote: > Why? tid is both an input and output parameter. The input tid is > valid and is verified at the top of the function, now if no row > version is visible, then it should have the same value as

Re: [HACKERS] Runtime Partition Pruning

Hi David, First of all: Solid patch set with good documentation. On 04/05/2018 09:41 AM, David Rowley wrote: Seems mostly fair. I'm not a fan of using the term "unpruned" though. I'll have a think. The "all" is meant in terms of what exists as subnodes. 'included_parts' / 'excluded_parts' p

Re: [HACKERS] MERGE SQL Statement for PG11

Hi, On 2018-04-05 11:31:48 +0530, Pavan Deolasee wrote: > > +/*- > > > > + * > > + * nodeMerge.c > > + * routines to handle Merge nodes relating to the MERGE command > > > > Isn't this file misnamed and it should be execMer

Re: Vacuum: allow usage of more than 1GB of work mem

On 03/04/18 17:20, Claudio Freire wrote: Ok, rebased patches attached Thanks! I took a look at this. First, now that the data structure is more complicated, I think it's time to abstract it, and move it out of vacuumlazy.c. The Tid Map needs to support the following operations: * Add TIDs,

Re: pgsql: New files for MERGE

On Thu, Apr 5, 2018 at 11:15:20AM +0100, Simon Riggs wrote: > On 4 April 2018 at 21:28, Simon Riggs wrote: > > On 4 April 2018 at 21:14, Andres Freund wrote: > > > >>> The normal way is to make review comments that allow change. Your > >>> request for change of the parser data structures is fine

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 7:30 PM, Magnus Hagander wrote: > On Thu, Apr 5, 2018 at 5:08 PM, Andrey Borodin > wrote: > >> >> >> > 5 апр. 2018 г., в 19:58, Magnus Hagander >> написал(а): >> > >> > >> > >> > On Thu, Apr 5, 2018 at 4:55 PM, Andrey Borodin >> wrote: >> > >> > >> > > 5 апр. 2018 г., в

Re: Online enabling of checksums

On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > I have now pushed this latest version with some minor text adjustments and > a catversion bump. > > Thanks for all the reviews! I want to be on the record that I think merging a nontrival feature that got submitted 2018-02-21, just before the

Re: Online enabling of checksums

On 2018-04-05 13:12:08 -0700, Andres Freund wrote: > On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > > I have now pushed this latest version with some minor text adjustments and > > a catversion bump. > > > > Thanks for all the reviews! > > I want to be on the record that I think merging a

Re: Online enabling of checksums

On Thu, Apr 5, 2018 at 10:14 PM, Andres Freund wrote: > On 2018-04-05 13:12:08 -0700, Andres Freund wrote: > > On 2018-04-05 22:06:36 +0200, Magnus Hagander wrote: > > > I have now pushed this latest version with some minor text adjustments > and > > > a catversion bump. > > > > > > Thanks for al

Re: Online enabling of checksums

On April 5, 2018 1:20:52 PM PDT, Magnus Hagander wrote: >On Thu, Apr 5, 2018 at 10:14 PM, Andres Freund >wrote: > >And even worse, without even announcing an intent to commit and giving >> people a chance to object. >> > >At least this patch was posted on the lists before commit, unlike many >o

Re: WIP: a way forward on bootstrap data

On 4/6/18, Tom Lane wrote: > I experimented with converting all frontend code to include just the > catalog/pg_foo_d.h files instead of catalog/pg_foo.h, as per the > proposed new policy. I soon found that we'd overlooked one thing: > some clients expect to see the relation OID macros, eg > Large

Re: WIP: a way forward on bootstrap data

On 4/5/18, Tom Lane wrote: > I've generalized the BKI_LOOKUP(pg_proc) code so that > you can use either regproc-like or regprocedure-like notation, and then > applied that to relevant columns. > [...] > bootstrap-v13-delta.patch is a diff atop your patch series for the > in-tree files, and convert

Re: Parallel Aggregates for string_agg and array_agg

On 04/05/2018 09:10 PM, Tels wrote: > Moin, > > On Wed, April 4, 2018 11:41 pm, David Rowley wrote: >> Hi Tomas, >> >> Thanks for taking another look. >> >> On 5 April 2018 at 07:12, Tomas Vondra >> wrote: >>> Other than that, the patch seems fine to me, and it's already marked as >>> RFC so I'

  1   2   >