Re: Schema variables - new implementation for Postgres 15

pá 16. 4. 2021 v 8:07 odesílatel Joel Jacobson napsal: > On Thu, Apr 15, 2021, at 10:42, Pavel Stehule wrote: > > *Attachments:* > >- schema-variables-v-execnode-2021-01.patch >- schema-variables-v-utility-2021-01.patch > > > Applications are currently know to be misusing > set_config()+c

Re: Table refer leak in logical replication

On Tue, Apr 06, 2021 at 02:25:05PM +0900, Amit Langote wrote: > While updating the patch to do so, it occurred to me that maybe we > could move the ExecInitResultRelation() call into > create_estate_for_relation() too, in the spirit of removing > duplicative code. See attached updated patch. Actu

Re: TRUNCATE on foreign table

On Fri, Apr 16, 2021 at 8:24 AM Fujii Masao wrote: > We are still discussing whether RESTRICT option should be pushed down to > a foreign data wrapper. But ISTM at least we could reach the consensus about > the drop of extra information for each foreign table. So what about applying > the attached

Re: Schema variables - new implementation for Postgres 15

On Thu, Apr 15, 2021, at 10:42, Pavel Stehule wrote: > *Attachments:* > * schema-variables-v-execnode-2021-01.patch > * schema-variables-v-utility-2021-01.patch Applications are currently know to be misusing set_config()+current_setting() to pass information in a session or transaction. Such u

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 4:35 PM Masahiko Sawada wrote: > > Thank you for the update! The patch looks good to me. > I have pushed the first patch. Comments on the next patch v13-0001-Use-HTAB-for-replication-slot-statistics: 1. + /* + * Check for all replication slots in stats hash table. We do th

Re: TRUNCATE on foreign table

At Fri, 16 Apr 2021 11:54:16 +0900, Fujii Masao wrote in > On 2021/04/16 9:15, Bharath Rupireddy wrote: > > On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao > > wrote: > >> On 2021/04/14 12:54, Bharath Rupireddy wrote: > >>> IMHO, we can push all the TRUNCATE options (ONLY, RESTRICTED, CASCADE, > >>

Re: Retry in pgbench

It would be useful to test replicating clusters with a (switch|fail)over procedure. Interesting idea but in general a failover takes sometime (like a few minutes), and it will strongly affect TPS. I think in the end it just compares the failover time. Or are you suggesting to ignore the time

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 2:46 PM Amit Kapila wrote: > > On Thu, Apr 15, 2021 at 1:13 PM Masahiko Sawada wrote: > > > > On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila wrote: > > > > > Thank you for updating the patch. > > > > I have one question on the doc change: > > > > +so the counter is n

Re: Replication slot stats misgivings

On Fri, Apr 16, 2021 at 08:48:29AM +0530, Amit Kapila wrote: > I am fine with your proposed changes. There are one or two more > patches in this area. I can include your suggestions along with those > if you don't mind? However's convenient is fine -- Justin

Re: Replication slot stats misgivings

On Fri, Apr 16, 2021 at 8:22 AM Justin Pryzby wrote: > > On Thu, Apr 15, 2021 at 02:46:35PM +0530, Amit Kapila wrote: > > On Thu, Apr 15, 2021 at 1:13 PM Masahiko Sawada > > wrote: > > > > > > On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila > > > wrote: > > > > > > > Thank you for updating the pat

Re: Performance degradation of REFRESH MATERIALIZED VIEW

At Mon, 12 Apr 2021 15:20:41 +0900, Masahiko Sawada wrote in > . > > On Thu, Mar 11, 2021 at 5:44 PM Masahiko Sawada wrote: > > > > Hi, > > > > While discussing freezing tuples during CTAS[1], we found that > > heap_insert() with HEAP_INSERT_FROZEN brings performance degradation. > > For insta

Re: Forget close an open relation in ReorderBufferProcessTXN()

On Thu, Apr 15, 2021 at 10:56 PM Tom Lane wrote: > > Amit Kapila writes: > > On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote: > >> > >> The RelationIdGetRelation() comment says: > >> > > Caller should eventually decrement count. (Usually, > > that happens by calling RelationClose().) > >> > >> Ho

Re: Bogus collation version recording in recordMultipleDependencies

On Thu, Apr 15, 2021 at 10:06:24AM -0400, Tom Lane wrote: > Julien Rouhaud writes: > > On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote: > >> (To be clear: 0002 passes check-world as-is, while 0001 is not > >> committable without some regression-test fiddling.) > > > I'm probably missing

Re: TRUNCATE on foreign table

On 2021/04/16 9:15, Bharath Rupireddy wrote: On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao wrote: On 2021/04/14 12:54, Bharath Rupireddy wrote: IMHO, we can push all the TRUNCATE options (ONLY, RESTRICTED, CASCADE, RESTART/CONTINUE IDENTITY), because it doesn't have any major challenge(impleme

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 02:46:35PM +0530, Amit Kapila wrote: > On Thu, Apr 15, 2021 at 1:13 PM Masahiko Sawada wrote: > > > > On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila wrote: > > > > > Thank you for updating the patch. > > > > I have one question on the doc change: > > > > +so the count

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On Thu, Apr 15, 2021 at 6:27 PM Tomas Vondra wrote: > > > On 4/15/21 7:35 PM, James Coleman wrote: > > On Thu, Apr 15, 2021 at 5:33 AM Luc Vlaming wrote: > >> > >> On 15-04-2021 04:01, James Coleman wrote: > >>> On Wed, Apr 14, 2021 at 5:42 PM James Coleman > wrote: > > On Mon, Apr 12

Re: Converting built-in SQL functions to new style

On Thu, Apr 15, 2021 at 07:25:39PM -0400, Tom Lane wrote: > One thing I was wondering about, but did not pull the trigger on > here, is whether to split off the function-related stuff in > system_views.sql into a new file "system_functions.sql" +1 -- Justin

Re: Truncate in synchronous logical replication failed

On Thu, 15 Apr 2021 at 19:25, Amit Kapila wrote: > On Thu, Apr 15, 2021 at 4:30 PM Japin Li wrote: >> >> >> On Thu, 15 Apr 2021 at 18:22, Amit Kapila wrote: >> > On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila >> > wrote: >> >> >> >> On Tue, Apr 13, 2021 at 8:07 PM Petr Jelinek >> >> wrote: >>

Re: Converting contrib SQL functions to new style

On Wed, Apr 14, 2021 at 02:03:56PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Apr 14, 2021 at 1:41 PM Tom Lane wrote: > >> Could we hack things so that extension scripts are only allowed to > >> reference objects created (a) by the system, (b) earlier in the > >> same script, or (c)

Re: Retry in pgbench

> By the way, I've been playing with the idea of failing gracefully and retry > indefinitely (or until given -T) on SQL error AND connection issue. > > It would be useful to test replicating clusters with a (switch|fail)over > procedure. Interesting idea but in general a failover takes sometime (

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On 4/15/21 7:35 PM, James Coleman wrote: > On Thu, Apr 15, 2021 at 5:33 AM Luc Vlaming wrote: >> >> On 15-04-2021 04:01, James Coleman wrote: >>> On Wed, Apr 14, 2021 at 5:42 PM James Coleman wrote: On Mon, Apr 12, 2021 at 8:37 AM Tomas Vondra wrote: > > On 4/12/21 2:24

Re: wal stats questions

On 2021/04/13 9:33, Fujii Masao wrote: > > > On 2021/03/30 20:37, Masahiro Ikeda wrote: >> OK, I added the condition to the fast-return check. I noticed that I >> misunderstood that the purpose is to avoid expanding a clock check using WAL >> stats counters. But, the purpose is to make the cond

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

On 4/15/21 8:36 PM, Michael Paquier wrote: > On Thu, Apr 15, 2021 at 07:16:05AM -0400, Andrew Dunstan wrote: >> Reviewing the history, I don't want to undo 114541d58e5. > Maybe we could remove it, but that may be better as a separate > discussion if it is proving to not improve the situation, and

Re: Remove redundant variable from transformCreateStmt

On Thu, Apr 15, 2021 at 8:40 PM Jeevan Ladhe wrote: > IMHO, I think the idea here was to just get rid of an unnecessary variable > rather than refactoring. > > On Thu, Apr 15, 2021 at 5:48 PM Bharath Rupireddy > wrote: >> >> On Thu, Apr 15, 2021 at 5:04 PM Amul Sul wrote: >> > >> > Hi, >> > >>

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

On Thu, Apr 15, 2021 at 07:16:05AM -0400, Andrew Dunstan wrote: > Reviewing the history, I don't want to undo 114541d58e5. Maybe we could remove it, but that may be better as a separate discussion if it is proving to not improve the situation, and I don't really want to take any risks in destabil

Re: New IndexAM API controlling index vacuum strategies

On Thu, Apr 15, 2021 at 5:12 PM Andres Freund wrote: > > https://thebuild.com/blog/2019/02/08/do-not-change-autovacuum-age-settings/ > > Not at all convinced. The issue of needing to modify a lot of > all-visible pages again to freeze them is big enough to let it be a > problem even after the free

Re: TRUNCATE on foreign table

On Thu, Apr 15, 2021 at 8:19 PM Fujii Masao wrote: > On 2021/04/14 12:54, Bharath Rupireddy wrote: > > IMHO, we can push all the TRUNCATE options (ONLY, RESTRICTED, CASCADE, > > RESTART/CONTINUE IDENTITY), because it doesn't have any major > > challenge(implementation wise) unlike pushing some cla

Re: New IndexAM API controlling index vacuum strategies

Hi, On 2021-04-14 21:30:29 -0700, Peter Geoghegan wrote: > I think that this was once true, but is now much less common, mostly > due to the freeze map stuff in 9.6. And due a general recognition that > the *risk* of increasing them is just too great (a risk that we can > hope was diminished by th

Re: Replacing pg_depend PIN entries with a fixed range check

Andres Freund writes: > On 2021-04-15 19:59:24 -0400, Tom Lane wrote: >> No, *neither* of them are pinned, and we don't want them to be. >> It's something of a historical artifact that template1 has a low OID. > Hm, it makes sense for template1 not to be pinned, but it doesn't seem > as obvious w

Re: Replacing pg_depend PIN entries with a fixed range check

Hi, On 2021-04-15 19:59:24 -0400, Tom Lane wrote: > Andres Freund writes: > > Hm, maybe we ought to swap template0 and template1 instead? I.e. have > > template0 be in pg_database.dat and thus get a pinned oid, and then > > create template1, postgres etc from that? > > No, *neither* of them are

Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

Hi, On 2021-04-12 19:49:36 -0700, Melanie Plageman wrote: > So, I took a stab at implementing this in PgBackendStatus. Cool! > The attached patch is not quite on top of current master, so, alas, > don't try and apply it. I went to rebase today and realized I needed > to make some changes in lig

Re: Replacing pg_depend PIN entries with a fixed range check

Andres Freund writes: > Hm, maybe we ought to swap template0 and template1 instead? I.e. have > template0 be in pg_database.dat and thus get a pinned oid, and then > create template1, postgres etc from that? No, *neither* of them are pinned, and we don't want them to be. It's something of a histo

Re: Replacing pg_depend PIN entries with a fixed range check

Hi, On 2021-04-14 21:43:28 -0400, Tom Lane wrote: > In [1] Andres and I speculated about whether we really need all > those PIN entries in pg_depend. Here is a draft patch that gets > rid of them. Yay. > There are a couple of objects, namely template1 and the public > schema, that are in the ca

Converting built-in SQL functions to new style

[ moving this to a new thread so as not to confuse the cfbot ] I wrote: > Andrew Dunstan writes: >> Is there anything else we should be doing along the eat your own dogfood >> line that don't have these security implications? > We can still convert the initdb-created SQL functions to new style,

Re: Collation versioning

On Mon, Mar 15, 2021 at 2:25 PM Thomas Munro wrote: > FYI I have added this as an open item for PostgreSQL 14. My default > action will be to document this limitation, if we can't come up with > something better in time. Here is a short doc update to explain the situation on Windows and close th

Re: SQL-standard function body

Based on the discussion so far, I've committed 0001 and 0002 but not 0003, and marked this open issue as closed. regards, tom lane

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On 4/15/21 2:21 AM, Robert Haas wrote: > On Wed, Apr 14, 2021 at 8:20 PM James Coleman wrote: >>> Hmm, could be. Although, the stack trace at issue doesn't seem to show >>> a call to create_incrementalsort_plan(). >> >> The changes to gather merge path generation made it possible to use >> thos

Re: ATTACH PARTITION locking documentation for DEFAULT partitions

On Thu, Apr 15, 2021 at 08:47:26PM +0200, Matthias van de Meent wrote: > I recently noticed that ATTACH PARTITION also recursively locks the > default partition with ACCESS EXCLUSIVE mode when its constraints do > not explicitly exclude the to-be-attached partition, which I couldn't > find document

ATTACH PARTITION locking documentation for DEFAULT partitions

Hi, I recently noticed that ATTACH PARTITION also recursively locks the default partition with ACCESS EXCLUSIVE mode when its constraints do not explicitly exclude the to-be-attached partition, which I couldn't find documented (has been there since PG10 I believe). PFA a patch that documents just

Iterating on IndexTuple attributes and nbtree page-level dynamic prefix truncation

-- Targeting PG15; if too early / noise then please ignore. I've noticed there are a lot of places in the btree index infrastructure (and also some other index AMs) that effectively iterate over the attributes of the index tuple, but won't use index_deform_tuple for reasons. However, this implies

Re: psql - add SHOW_ALL_RESULTS option

On 15.04.21 13:51, Fabien COELHO wrote: That's a lot IMO, so my vote would be to discard this feature for now and revisit it properly in the 15 dev cycle, so as resources are redirected into more urgent issues (13 open items as of the moment of writing this email). I don't wish to tell people w

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On Thu, Apr 15, 2021 at 5:33 AM Luc Vlaming wrote: > > On 15-04-2021 04:01, James Coleman wrote: > > On Wed, Apr 14, 2021 at 5:42 PM James Coleman wrote: > >> > >> On Mon, Apr 12, 2021 at 8:37 AM Tomas Vondra > >> wrote: > >>> > >>> On 4/12/21 2:24 PM, Luc Vlaming wrote: > Hi, > >

Re: Forget close an open relation in ReorderBufferProcessTXN()

Amit Kapila writes: > On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote: >> >> The RelationIdGetRelation() comment says: >> > Caller should eventually decrement count. (Usually, > that happens by calling RelationClose().) >> >> However, it doesn't do it in ReorderBufferProcessTXN(). >> I think we

Re: Converting contrib SQL functions to new style

On 2021-Apr-15, Vik Fearing wrote: > CREATE DOMAIN earth AS "$extension".cube.cube > CONSTRAINT not_point check("$extension".cube.cube_is_point(value)) > CONSTRAINT not_3d check("$extension".cube.cube_dim(value <= 3) > ...; I find this syntax pretty weird -- here, the ".cube." part of the i

Re: pg_amcheck contrib application

> On Apr 14, 2021, at 10:17 AM, Robert Haas wrote: > > On Mon, Apr 12, 2021 at 11:06 PM Mark Dilger > wrote: >> It now reports: >> >> # heap table "postgres"."public"."test", block 0, offset 18, attribute 2: >> # toast value 16461 missing chunk 3 with expected size 1996 >> # heap table "p

wrong units in ExplainPropertyFloat

|commit 7a50bb690b4837d29e715293c156cff2fc72885c |Author: Andres Freund |Date: Fri Mar 16 23:13:12 2018 -0700 | |Add 'unit' parameter to ExplainProperty{Integer,Float}. | |This allows to deduplicate some existing code, but mainly avoids some |duplication in upcoming commits. |

Re: Replacing pg_depend PIN entries with a fixed range check

[ connecting up two threads here ] I wrote: > Hence, what this patch does is to establish a manually-managed cutoff > point akin to FirstBootstrapObjectId, and make initdb push the OID > counter up to that once it's made the small number of pinned objects > it's responsible for. With the value I

Re: Options given both on cmd-line and in the config with different values

On 4/14/21 7:55 PM, Tom Lane wrote: Honza Horak writes: I'm trying to understand what is happening in the following bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1935301 The upgrade process makes it a bit more difficult, but it seems to boil down to this problem -- even when pg_ctl

Re: Schema variables - new implementation for Postgres 15

čt 15. 4. 2021 v 18:02 odesílatel tsunakawa.ta...@fujitsu.com < tsunakawa.ta...@fujitsu.com> napsal: > From: Pavel Stehule > > -- > > do $$ > > declare x int ; > > begin > > for i in 1..100 > > loop > > let ooo = i; > > end loop; > > e

RE: Schema variables - new implementation for Postgres 15

From: Pavel Stehule -- do $$ declare x int ; begin for i in 1..100 loop let ooo = i; end loop; end; $$; variant 1 .. 1500 ms variant 2 with PLpgSQL support .. 140 ms variant 2 without PLpgSQL support 9000 ms ---

buildfarm xversion diff

Forking https://www.postgresql.org/message-id/20210328231433.gi15...@telsasoft.com I gave suggestion how to reduce the "lines of diff" metric almost to nothing, allowing a very small "fudge factor", and which I think makes this a pretty good metric rather than a passable one. Thoughts ? On Sun,

Re: Commit ab596105b55 - BRIN minmax-multi indexes

Rushabh Lathia writes: > On Thu, Apr 15, 2021 at 7:49 PM Tom Lane wrote: >> As of right now, genbki.pl's OID counter reaches 12036, so it's >> pretty clear that 12000 no longer works. (I have this figure in >> my head because I noted it while working on [1].) 13000 might >> well be an excessive

Re: Remove redundant variable from transformCreateStmt

IMHO, I think the idea here was to just get rid of an unnecessary variable rather than refactoring. On Thu, Apr 15, 2021 at 5:48 PM Bharath Rupireddy < bharath.rupireddyforpostg...@gmail.com> wrote: > On Thu, Apr 15, 2021 at 5:04 PM Amul Sul wrote: > > > > Hi, > > > > Attached patch removes "is_

Re: TRUNCATE on foreign table

On 2021/04/14 13:41, Kyotaro Horiguchi wrote: At Wed, 14 Apr 2021 13:17:55 +0900, Kohei KaiGai wrote in Please assume the internal heap data is managed by PostgreSQL core, and external data source is managed by postgres_fdw (or other FDW driver). TRUNCATE command requires these object manage

Re: Commit ab596105b55 - BRIN minmax-multi indexes

On 4/15/21 4:29 PM, Rushabh Lathia wrote: > > > On Thu, Apr 15, 2021 at 7:49 PM Tom Lane > wrote: > > Rushabh Lathia > writes: > > Commit mentioned in the $subject changed the FirstBootstrapObjectId > > (transam.h) fro

Re: TRUNCATE on foreign table

On 2021/04/14 12:54, Bharath Rupireddy wrote: IMHO, we can push all the TRUNCATE options (ONLY, RESTRICTED, CASCADE, RESTART/CONTINUE IDENTITY), because it doesn't have any major challenge(implementation wise) unlike pushing some clauses in SELECT/UPDATE/DELETE and we already do this on the ma

Re: Commit ab596105b55 - BRIN minmax-multi indexes

Hi, On 4/15/21 4:03 PM, Rushabh Lathia wrote: > Hi, > > Commit mentioned in the $subject changed the FirstBootstrapObjectId > (transam.h) from 12000 to 13000.  I was trying to understand the reason > behind this change, but was not able to gather that information. Also didn't > find anything in t

Re: Commit ab596105b55 - BRIN minmax-multi indexes

On Thu, Apr 15, 2021 at 7:49 PM Tom Lane wrote: > Rushabh Lathia writes: > > Commit mentioned in the $subject changed the FirstBootstrapObjectId > > (transam.h) from 12000 to 13000. I was trying to understand the reason > > behind this change, but was not able to gather that information. Also >

Re: Commit ab596105b55 - BRIN minmax-multi indexes

Rushabh Lathia writes: > Commit mentioned in the $subject changed the FirstBootstrapObjectId > (transam.h) from 12000 to 13000. I was trying to understand the reason > behind this change, but was not able to gather that information. Also didn't > find anything in the commit message either. As of

Re: Bogus collation version recording in recordMultipleDependencies

Julien Rouhaud writes: > On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote: >> (To be clear: 0002 passes check-world as-is, while 0001 is not >> committable without some regression-test fiddling.) > I'm probably missing something obvious but both 0001 and 0002 pass check-world > for me, on

Commit ab596105b55 - BRIN minmax-multi indexes

Hi, Commit mentioned in the $subject changed the FirstBootstrapObjectId (transam.h) from 12000 to 13000. I was trying to understand the reason behind this change, but was not able to gather that information. Also didn't find anything in the commit message either. Can you please explain those cha

Re: Remove redundant variable from transformCreateStmt

On Thu, Apr 15, 2021 at 5:47 PM Bharath Rupireddy wrote: > > On Thu, Apr 15, 2021 at 5:04 PM Amul Sul wrote: > > > > Hi, > > > > Attached patch removes "is_foreign_table" from transformCreateStmt() > > since it already has cxt.isforeign that can serve the same purpose. > > Yeah having that variab

Re: Remove redundant variable from transformCreateStmt

On Thu, Apr 15, 2021 at 5:04 PM Amul Sul wrote: > > Hi, > > Attached patch removes "is_foreign_table" from transformCreateStmt() > since it already has cxt.isforeign that can serve the same purpose. Yeah having that variable as "is_foreign_table" doesn't make sense when we have the info in ctx. I

Re: psql - add SHOW_ALL_RESULTS option

Hello Tom, That's a lot IMO, so my vote would be to discard this feature for now and revisit it properly in the 15 dev cycle, so as resources are redirected into more urgent issues (13 open items as of the moment of writing this email). I don't wish to tell people which open issues they ough

Re: Remove redundant variable from transformCreateStmt

Thanks Amul, this looks pretty straight forward. LGTM. I have also run the regression on master and seems good. Regards, Jeevan Ladhe

Remove redundant variable from transformCreateStmt

Hi, Attached patch removes "is_foreign_table" from transformCreateStmt() since it already has cxt.isforeign that can serve the same purpose. Regards, Amul diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c index 9dd30370dae..97e6d65158c 100644 --- a/src/backend/p

Re: Truncate in synchronous logical replication failed

On Thu, Apr 15, 2021 at 4:30 PM Japin Li wrote: > > > On Thu, 15 Apr 2021 at 18:22, Amit Kapila wrote: > > On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila wrote: > >> > >> On Tue, Apr 13, 2021 at 8:07 PM Petr Jelinek > >> wrote: > >> > > >> > > On 12 Apr 2021, at 08:58, Amit Kapila wrote: > >> > >

Re: Forget close an open relation in ReorderBufferProcessTXN()

On Thu, Apr 15, 2021 at 4:00 PM Japin Li wrote: > > The RelationIdGetRelation() comment says: > > > Caller should eventually decrement count. (Usually, > > that happens by calling RelationClose().) > > However, it doesn't do it in ReorderBufferProcessTXN(). > I think we should close it, here is a

Re: File truncation within PostgresNode::issues_sql_like() wrong on Windows

On 4/15/21 12:57 AM, Michael Paquier wrote: > On Wed, Apr 14, 2021 at 09:26:19PM -0400, Andrew Dunstan wrote: >> Well, let me try it on fairywren tomorrow. Since we manage this on the >> buildfarm without any use at all of Win32API::File it might not be >> necessary in TAP code either, particular

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 6:16 PM Amit Kapila wrote: > > On Thu, Apr 15, 2021 at 1:13 PM Masahiko Sawada wrote: > > > > On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila wrote: > > > > > Thank you for updating the patch. > > > > I have one question on the doc change: > > > > +so the counter is n

Re: Truncate in synchronous logical replication failed

On Thu, 15 Apr 2021 at 18:22, Amit Kapila wrote: > On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila wrote: >> >> On Tue, Apr 13, 2021 at 8:07 PM Petr Jelinek >> wrote: >> > >> > > On 12 Apr 2021, at 08:58, Amit Kapila wrote: >> > > >> > > The problem happens only when we try to fetch IDENTITY_KEY

Re: Bogus collation version recording in recordMultipleDependencies

On Wed, Apr 14, 2021 at 01:18:07PM -0400, Tom Lane wrote: > > One question here is whether it's correct that the domain's dependency > on collation "aa_DJ" is unversioned. Maybe that's intentional, but it > seems worth asking. This is intentional I think, we should record collation version only

Forget close an open relation in ReorderBufferProcessTXN()

The RelationIdGetRelation() comment says: > Caller should eventually decrement count. (Usually, > that happens by calling RelationClose().) However, it doesn't do it in ReorderBufferProcessTXN(). I think we should close it, here is a patch that fixes it. Thoughts? -- Regrads, Japin Li. ChengD

Re: Truncate in synchronous logical replication failed

On Wed, Apr 14, 2021 at 3:31 PM Amit Kapila wrote: > > On Tue, Apr 13, 2021 at 8:07 PM Petr Jelinek > wrote: > > > > > On 12 Apr 2021, at 08:58, Amit Kapila wrote: > > > > > > The problem happens only when we try to fetch IDENTITY_KEY attributes > > > because pgoutput uses RelationGetIndexAttrBi

Re: "could not find pathkey item to sort" for TPC-DS queries 94-96

On 15-04-2021 04:01, James Coleman wrote: On Wed, Apr 14, 2021 at 5:42 PM James Coleman wrote: On Mon, Apr 12, 2021 at 8:37 AM Tomas Vondra wrote: On 4/12/21 2:24 PM, Luc Vlaming wrote: Hi, When trying to run on master (but afaik also PG-13) TPC-DS queries 94, 95 and 96 on a SF10 I get th

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 1:13 PM Masahiko Sawada wrote: > > On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila wrote: > > > Thank you for updating the patch. > > I have one question on the doc change: > > +so the counter is not incremented for subtransactions. Note that this > +includes t

Re: [Proposal] Global temporary tables

wenjing 于2021年4月15日周四 下午3:26写道： > HI Pavel > > I added user documentation. > Please give me feedback. > > > Wenjing > > Hi, Wenjing, I have checked your documentation section and fixed a spelling mistake, adjusted some sentences for you. All the modified content is in the new patch, and please c

Re: Extensions not dumped when --schema is used

Le jeu. 15 avr. 2021 à 09:58, Michael Paquier a écrit : > On Wed, Apr 14, 2021 at 05:31:15AM -0700, Noah Misch wrote: > > The name "without_extension_explicit_schema" arose because that test > differs > > from the "without_extension" test by adding --schema=public. The test > named > > "without_

Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On Wed, Apr 14, 2021 at 02:33:26PM -0400, Bruce Momjian wrote: > On Tue, Apr 13, 2021 at 01:30:16PM -0400, Álvaro Herrera wrote: > > > > So I'm -1 on Julien's first proposed change, and +1 on his second > > proposed change (the name of the first argument of > > pgstat_report_query_id should be que

Re: Extensions not dumped when --schema is used

On Wed, Apr 14, 2021 at 05:31:15AM -0700, Noah Misch wrote: > The name "without_extension_explicit_schema" arose because that test differs > from the "without_extension" test by adding --schema=public. The test named > "without_extension_implicit_schema" differs from "without_extension" by adding

Re: [PATCH] expand the units that pg_size_pretty supports on output

On Wed, Apr 14, 2021 at 11:13:47AM -0500, David Christensen wrote: > Enclosed is a patch that expands the unit output for > pg_size_pretty(numeric) going up to Yottabytes; I reworked the existing > numeric output code to account for the larger number of units we're using > rather than just adding n

Re: Problems around compute_query_id

On Mon, Apr 12, 2021 at 02:56:59PM +0800, Julien Rouhaud wrote: > I think we should simply document that %Q is not compatible with > log_statements. Hearing no objection I documented that limitation. > > > While making the feature run on some test server, I have noticed that > > %Q would log som

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 3:22 PM Amit Kapila wrote: > > On Wed, Apr 14, 2021 at 5:52 PM vignesh C wrote: > > > > I have made minor changes to the 0001 and 0002 patches. Attached is > the combined patch for them, I think we can push them as one patch. > Changes made are (a) minor editing in comment

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 12:45 PM vignesh C wrote: > > On Thu, Apr 15, 2021 at 11:52 AM Amit Kapila wrote: > > > > On Wed, Apr 14, 2021 at 5:52 PM vignesh C wrote: > > > > > > > I have made minor changes to the 0001 and 0002 patches. Attached is > > the combined patch for them, I think we can pus

Re: Replication slot stats misgivings

On Thu, Apr 15, 2021 at 11:52 AM Amit Kapila wrote: > > On Wed, Apr 14, 2021 at 5:52 PM vignesh C wrote: > > > > I have made minor changes to the 0001 and 0002 patches. Attached is > the combined patch for them, I think we can push them as one patch. > Changes made are (a) minor editing in commen