Re: Support TRUNCATE triggers on foreign tables

On 2022/07/08 11:19, Yugo NAGATA wrote: You added "foreign tables" for BEFORE statement-level trigger as the above, but ISTM that you also needs to do that for AFTER statement-level trigger. No? Oops, I forgot it. I attached the updated patch. Thanks for updating the patch! LGTM. Barring

Re: AIX support - alignment issues

On Thu, 7 Jul 2022 at 22:36, Thomas Munro wrote: > > * Since Greg Stark's magnificent Vax talk[1], we became even more > dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone > produces a software IEEE math implementation for GCC/VAX... if I had > a pick one to bump off that list,

Re: AIX support - alignment issues

Thomas Munro writes: > * The documented list mentions some in different endiannesses and word > sizes explicitly but not others; I think it'd be tidier to list the > main architecture names and then tack on a "big and little endian, 32 > and 64 bit" sentence. As phrased, this seems to be saying

Re: DropRelFileLocatorBuffers

At Thu, 7 Jul 2022 21:13:59 -0400, Robert Haas wrote in > On Thu, Jul 7, 2022 at 8:22 PM Kyotaro Horiguchi > wrote: > > Thanks for the reply. > > > > Yes if it is "RelFileLocator when we're talking about all the things > > that are needed to locate a relation's files on disk,". I read this as >

Re:Improving RLS planning

This patch causes wrong index scan plan with RLS. Maybe function restriction_is_securely_promotable is too strict? You can reproduce in this way: create table abc (a integer, b text); insert into abc select (random()*(10^4))::integer, (random()*(10^4))::text from generate_series(1,10);

Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections

At Thu, 7 Jul 2022 13:58:06 -0500, Justin Pryzby wrote in > I agree that this is a bug, since it can (and did) cause false positives in a > monitoring system. I'm not this is undoubtfully a bug but agree about the rest. > > As well, patch changes way to allocate memory for local structure.

Re: AIX support - alignment issues

On Thu, Jul 7, 2022 at 1:02 AM Peter Eisentraut wrote: > On 06.07.22 04:21, Thomas Munro wrote: > > /* > >* Do not try to collapse these into one "w+" mode file. Doesn't work > > on > > - * some platforms (eg, HPUX 10.20). > > + * some platforms. > >*/ > >

Re: Support logical replication of DDLs

Here are some review comments for the patch v11-0001: == 1. Commit message This provides base for logical replication of DDL statements. Currently, this provides support for: SUGGESTION This provides a base for logical replication of DDL statements. Currently, the patch has support for:

Re: Support TRUNCATE triggers on foreign tables

Hello Fujii-san, Thank you for reviewing the patch! On Fri, 8 Jul 2022 00:54:37 +0900 Fujii Masao wrote: > > > On 2022/06/30 19:38, Yugo NAGATA wrote: > > Hello, > > > > I propose supporting TRUNCATE triggers on foreign tables > > because some FDW now supports TRUNCATE. I think such

Re: Fast COPY FROM based on batch insert

On 07/07/2022 22:51, Andrey Lepikhov wrote: > On 7/7/2022 06:14, Ian Barwick wrote: >> 2022年3月24日(木) 15:44 Andrey V. Lepikhov : >> > >> > On 3/22/22 06:54, Etsuro Fujita wrote: >> > > On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov >> > > wrote: >> > >> We still have slow 'COPY FROM'

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Tue, Jul 5, 2022 at 5:49 PM John Naylor wrote: > > On Mon, Jul 4, 2022 at 12:07 PM Masahiko Sawada wrote: > > > > Looking at the node stats, and then your benchmark code, I think key > > > construction is a major influence, maybe more than node type. The > > > key/value scheme tested now

Re: Add a test for "cannot truncate foreign table"

On Fri, 08 Jul 2022 09:44:10 +0900 (JST) Kyotaro Horiguchi wrote: > At Fri, 8 Jul 2022 01:06:18 +0900, Fujii Masao > wrote in > > > > > > On 2022/07/08 0:33, Tom Lane wrote: > > > Fujii Masao writes: > > >> On 2022/06/30 10:48, Yugo NAGATA wrote: > > >>> When a foreign table has handler

Re: remove more archiving overhead

At Thu, 7 Jul 2022 15:07:16 -0700, Nathan Bossart wrote in > Here's an updated patch. Thinking RFC'ish, the meaning of "may" and "must" is significant in this description. On the other hand it uses both "may" and "can" but I thinkthat their difference is not significant or "can" there is

Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns

On Thu, Jul 7, 2022 at 3:40 PM Amit Kapila wrote: > > On Thu, Jul 7, 2022 at 8:21 AM Masahiko Sawada wrote: > > > > On Wed, Jul 6, 2022 at 5:55 PM Amit Kapila wrote: > > > > > > On Wed, Jul 6, 2022 at 12:19 PM Masahiko Sawada > > > wrote: > > > > > > > > On Tue, Jul 5, 2022 at 8:00 PM Amit

Re: DropRelFileLocatorBuffers

On Thu, Jul 7, 2022 at 8:22 PM Kyotaro Horiguchi wrote: > Thanks for the reply. > > Yes if it is "RelFileLocator when we're talking about all the things > that are needed to locate a relation's files on disk,". I read this as > RelFileLocator is a kind of pointer to files. I thought RelFileNode

Re: Add a test for "cannot truncate foreign table"

At Fri, 8 Jul 2022 01:06:18 +0900, Fujii Masao wrote in > > > On 2022/07/08 0:33, Tom Lane wrote: > > Fujii Masao writes: > >> On 2022/06/30 10:48, Yugo NAGATA wrote: > >>> When a foreign table has handler but doesn't support TRUNCATE, > >>> an error "cannot truncate foreign table xxx"

Re: DropRelFileLocatorBuffers

At Thu, 7 Jul 2022 08:36:14 -0400, Robert Haas wrote in > On Thu, Jul 7, 2022 at 4:44 AM Kyotaro Horiguchi > wrote: > > While working on a patch, I met a function with the signature of: > > > > > DropRelFileLocatorBuffers(SMgrRelation smgr_reln, ForkNumber *forkNum, > > >

Re: CI and test improvements

rebased on b6a5158f9 and 054325c5e Also, cirrus/freebsd task can run 3x faster with more CPUs. Subject: [PATCH 21/21] cirrus: run freebsd with more CPUs+RAM

Re: Kerberos delegation support in libpq and postgres_fdw

On 4/8/22 05:21, Stephen Frost wrote: > Added a few more tests and updated the documentation too. Sadly, seems > we've missed the deadline for v15 though for lack of feedback on these. > Would really like to get some other folks commenting as these are new > pg_hba and postgresql.conf options

Re: System catalog documentation chapter

On Fri, Jul 8, 2022 at 2:17 AM Bruce Momjian wrote: > > On Thu, Jul 7, 2022 at 09:29:13AM +1000, Peter Smith wrote: > > On Thu, Jun 16, 2022 at 10:59 AM Peter Smith wrote: > > > > > > On Thu, Jun 9, 2022 at 11:50 PM Tom Lane wrote: > > > > > > > > Peter Eisentraut writes: > > > > > Initially,

Re: index for inet column

Zhihong Yu writes: > I was able to create gin index on inet column in PG. > GIN is good with points/elements in sets. Is gin a good index for inet > column ? As far as Postgres is concerned, inet is a scalar type: it has a linear sort order, and there aren't many operations on it that are

Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.

On Tue, Apr 26, 2022 at 12:54:35PM +0800, Julien Rouhaud wrote: > Their API is entirely useless, so I'm still on the opinion that we should > unconditionally use the FILE_MAP_LARGE_PAGES flag if it's defined and call it > a > day. Now that the minimal runtime version is Windows 10 in v16~ thanks

Re: Remove support for Visual Studio 2013

On Mon, May 30, 2022 at 04:48:22PM +0900, Michael Paquier wrote: > After looking at that again, the whole comment related to VS in > strtof.c can be removed. I have noticed while on it more places that > still referred to VS2013 in ./configure[.ac] and win32_langinfo() got > an overall incorrect

Re: explain analyze rows=%.0f

On Thu, Jul 07, 2022 at 04:21:37PM -0400, Robert Haas wrote: > I mean, what I really want here if I'm honest is to not have the > system divide the number of rows by the loop count. And it sort of > sounds like maybe that's what you want, too. You want to know whether > the loop count is actually

Re: Postgres picks suboptimal index after building of an extended statistics

Andrey Lepikhov writes: > On 12/8/21 04:26, Tomas Vondra wrote: >> I wonder if we should teach clauselist_selectivity about UNIQUE indexes, >> and improve the cardinality estimates directly, not just costing for >> index scans. > I tried to implement this in different ways. But it causes

Re: remove more archiving overhead

On Thu, Jul 07, 2022 at 05:06:13PM -0400, David Steele wrote: > On 7/7/22 14:22, Nathan Bossart wrote: >> On Thu, Jul 07, 2022 at 10:51:42AM -0700, Nathan Bossart wrote: >> > +library to ensure that it indeed does not overwrite an existing file. >> > When >> > +a pre-existing file is

Re: index for inet column

## Zhihong Yu (z...@yugabyte.com): > I was able to create gin index on inet column in PG. > > GIN is good with points/elements in sets. Is gin a good index for inet > column ? > It seems gist index would be better. Why not use btree? The common operations are quite supported with that. (Common

Re: SQL/JSON: functions

On 2022-07-07 Th 14:35, Andrew Dunstan wrote: > On 2022-07-07 Th 12:38, a.kozhemya...@postgrespro.ru wrote: >> Hello hackers, >> On branch REL_15_STABLE the following query: SELECT >> JSON_SERIALIZE('{"a":1}' RETURNING jsonb); >> >> produces SIGSEGV for me: You're not supposed to be able to

index for inet column

Hi, I was able to create gin index on inet column in PG. GIN is good with points/elements in sets. Is gin a good index for inet column ? It seems gist index would be better. Comments are welcome.

Re: Select Reference Page - Make Join Syntax More Prominent

"David G. Johnston" writes: > Looking again at the SELECT Reference page while helping a novice user I > was once again annoyed but how the most common query syntax form for the > FROM clause is buried within a bunch of "how to generate a table" detail. Hmm ... I'm good with the concept of

Re: remove more archiving overhead

On 7/7/22 14:22, Nathan Bossart wrote: On Thu, Jul 07, 2022 at 10:51:42AM -0700, Nathan Bossart wrote: +library to ensure that it indeed does not overwrite an existing file. When +a pre-existing file is encountered, the archive library may return +true if the WAL file has identical

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 1:21 PM Robert Haas wrote: > Nested Loop (actual time=TIME FOR THIS AND ALL CHILDREN rows=THE REAL > ROW COUNT loops=1) > -> Seq Scan on something (actual time=THE TIME IT REALLY TOOK rows=THE > REAL ROW COUNT loops=1) > -> Index Scan using someidx on somethingelse (actual

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 1:53 PM Greg Stark wrote: > > - -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50) > > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 > > At the not inconsiderable risk of bike-shedding > > I'm wondering if printing something

Re: pg15b2: large objects lost on upgrade

On Tue, Jul 5, 2022 at 12:43:54PM -0400, Robert Haas wrote: > On Sat, Jul 2, 2022 at 11:49 AM Justin Pryzby wrote: > > I suppose it's like Bruce said, here. > > > > https://www.postgresql.org/message-id/20210601140949.GC22012%40momjian.us > > Well, I feel dumb. I remember reading that email

Re: Patch proposal: New hooks in the connection path

Joe Conway writes: > It isn't clear to me if having a hook in the timeout handler is a > nonstarter -- perhaps a comment with suitable warning for prospective > extension authors is enough? Anyone else want to weigh in on this issue > specifically? It doesn't seem like a great place for a

Re: Patch proposal: New hooks in the connection path

On 7/6/22 04:13, Drouvot, Bertrand wrote: On 7/6/22 12:11 AM, Joe Conway wrote: On 7/5/22 03:37, Bharath Rupireddy wrote: 2. Timeout Handler is a signal handler, called as part of SIGALRM signal handler, most of the times, signal handlers ought to be doing small things, now that we are handing

Re: should check interrupts in BuildRelationExtStatistics ?

Thomas Munro writes: > On Wed, Jul 6, 2022 at 11:37 AM Tom Lane wrote: >> qsort_interruptible > +1 So here's a patch that does it that way. I first meant to put the new file into src/port/, but after remembering that that directory has no backend-only functions, I went with

Re: pg_parameter_aclcheck() and trusted extensions

On 7/7/22 15:00, Tom Lane wrote: Nathan Bossart writes: On Thu, Jul 07, 2022 at 12:41:00PM -0400, Tom Lane wrote: Can we get away with doing these things in beta3? We could avoid breaking (2) in the v15 branch by making set_config_option into a wrapper around set_config_option_ext, or

Re: pg15b2: large objects lost on upgrade

+ /* Keep track of whether a filenode matches the OID */ + if (maps[mapnum].relfilenumber == LargeObjectRelationId) + *has_lotable = true; + if (maps[mapnum].relfilenumber == LargeObjectLOidPNIndexId) +

Re: pg15b2: large objects lost on upgrade

Justin Pryzby writes: > On Thu, Jul 07, 2022 at 02:38:44PM -0400, Robert Haas wrote: >> On Thu, Jul 7, 2022 at 2:24 PM Bruce Momjian wrote: >>> Uh, that initdb-created pg_largeobject file should not have any data in >>> it ever, as far as I know at that point in pg_upgrade. How would values >>>

Re: pg_parameter_aclcheck() and trusted extensions

Nathan Bossart writes: > On Thu, Jul 07, 2022 at 12:41:00PM -0400, Tom Lane wrote: >> Can we get away with doing these things in beta3? We could avoid >> breaking (2) in the v15 branch by making set_config_option into >> a wrapper around set_config_option_ext, or something like that; >> but the

Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections

On Thu, Jun 30, 2022 at 11:05:28PM +0300, Michael Zhilin wrote: > I would like to submit patch for column wait_event of view pg_stat_activity. > Please find it attached. Thanks. I had this thread on my list to look at later but then, by chance, I got an erroneous nagios notification about a

Re: enable/disable broken for statement triggers on partitioned tables

Hi! I've looked through the code and everything looks good. But there is one thing I doubt. Patch changes result of test: create function trig_nothing() returns trigger language plpgsql as $$ begin return null; end $$; create table parent (a int) partition by list (a); create table

Re: pg15b2: large objects lost on upgrade

On Thu, Jul 07, 2022 at 02:38:44PM -0400, Robert Haas wrote: > On Thu, Jul 7, 2022 at 2:24 PM Bruce Momjian wrote: > > On Thu, Jul 7, 2022 at 01:38:44PM -0400, Robert Haas wrote: > > > On Thu, Jul 7, 2022 at 1:10 PM Justin Pryzby wrote: > > > > Maybe it's a good idea to check that the file is

Re: pg_parameter_aclcheck() and trusted extensions

On Thu, Jul 07, 2022 at 12:41:00PM -0400, Tom Lane wrote: > Yeah. So the fix here seems pretty obvious: rather than applying the > permissions check using bare GetUserId(), we need to remember the role > OID that originally applied the setting, and use that. Please ignore my previous message.

Re: pg15b2: large objects lost on upgrade

On Thu, Jul 7, 2022 at 2:24 PM Bruce Momjian wrote: > On Thu, Jul 7, 2022 at 01:38:44PM -0400, Robert Haas wrote: > > On Thu, Jul 7, 2022 at 1:10 PM Justin Pryzby wrote: > > > Maybe it's a good idea to check that the file is empty before unlinking... > > > > If we want to verify that there are

Re: SQL/JSON: functions

On 2022-07-07 Th 12:38, a.kozhemya...@postgrespro.ru wrote: > Hello hackers, > On branch REL_15_STABLE the following query: SELECT > JSON_SERIALIZE('{"a":1}' RETURNING jsonb); > > produces SIGSEGV for me: > #0  getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at > jsonb_util.c:148 > 148

Re: pg15b2: large objects lost on upgrade

On Thu, Jul 7, 2022 at 01:38:44PM -0400, Robert Haas wrote: > On Thu, Jul 7, 2022 at 1:10 PM Justin Pryzby wrote: > > Maybe it's a good idea to check that the file is empty before unlinking... > > If we want to verify that there are no large objects in the cluster, > we could do that in

Re: remove more archiving overhead

On Thu, Jul 07, 2022 at 10:51:42AM -0700, Nathan Bossart wrote: > +library to ensure that it indeed does not overwrite an existing file. > When > +a pre-existing file is encountered, the archive library may return > +true if the WAL file has identical contents to the > +

Re: remove more archiving overhead

On Thu, Jul 07, 2022 at 02:07:26PM -0400, David Steele wrote: > On 7/7/22 12:18, Nathan Bossart wrote: >> On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote: >> >> > There are plenty of ways that already-archived WAL might get archived again >> > and this is just one of them. >> >>

Re: remove more archiving overhead

On 7/7/22 12:18, Nathan Bossart wrote: On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote: There are plenty of ways that already-archived WAL might get archived again and this is just one of them. What are some of the others? I was aware of the case that was fixed in ff9f111,

Re: explain analyze rows=%.0f

> - -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50) > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 At the not inconsiderable risk of bike-shedding I'm wondering if printing something like 0.00 will be somewhat deceptive when the real value is

Re: remove more archiving overhead

On Thu, Jul 07, 2022 at 09:18:25AM -0700, Nathan Bossart wrote: > On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote: >> On 7/7/22 10:37, Robert Haas wrote: >>> I don't object, but I just started to wonder whether the need to >>> handle re-archiving of the same file cleanly is as

Re: pg15b2: large objects lost on upgrade

On Thu, Jul 7, 2022 at 1:10 PM Justin Pryzby wrote: > Maybe it's a good idea to check that the file is empty before unlinking... If we want to verify that there are no large objects in the cluster, we could do that in check_new_cluster_is_empty(). However, even if there aren't, the length of the

Re: making relfilenodes 56 bits

Trying to compile with 0001 and 0002 applied and -Wall -Werror in use, I get: buf_init.c:119:4: error: implicit truncation from 'int' to bit-field changes value from -1 to 255 [-Werror,-Wbitfield-constant-conversion] CLEAR_BUFFERTAG(buf->tag);

Re: pg15b2: large objects lost on upgrade

On Wed, Jul 06, 2022 at 08:25:04AM -0400, Robert Haas wrote: > On Wed, Jul 6, 2022 at 7:56 AM Justin Pryzby wrote: > > I'm looking into it, but it'd help to hear suggestions about where to put > > it. > > My current ideas aren't very good. > > In main() there is a comment that begins "Most

Re: archive modules

On Thu, Jul 07, 2022 at 11:48:20AM -0400, Tom Lane wrote: > Alvaro Herrera writes: >> Well, this does sound unsatisfactory. I suppose one answer would be to >> load the module in all backends, in case the user wants to look at the >> value. But that would be wasteful. Maybe we should have a

Re: pg_parameter_aclcheck() and trusted extensions

On Thu, Jul 07, 2022 at 10:04:18AM +0900, Michael Paquier wrote: > On Wed, Jul 06, 2022 at 03:47:27PM -0700, Nathan Bossart wrote: >> I think the call to superuser_arg() in pg_parameter_aclmask() is causing >> set_config_option() to bypass the normal privilege checks, as >>

Add function to return backup_label and tablespace_map

Hi, Since an exclusive backup method was dropped in v15, in v15 or later, we need to create backup_label and tablespace_map files from the result of pg_backup_stop() when taking a base backup using low level backup API. One issue when doing this is that; there is no simple way to create those

Re: pg_parameter_aclcheck() and trusted extensions

Michael Paquier writes: > On Wed, Jul 06, 2022 at 03:47:27PM -0700, Nathan Bossart wrote: >> I think the call to superuser_arg() in pg_parameter_aclmask() is causing >> set_config_option() to bypass the normal privilege checks, as >> execute_extension_script() will have set the user ID to the

Re: SQL/JSON: functions

Hello hackers, On branch REL_15_STABLE the following query: SELECT JSON_SERIALIZE('{"a":1}' RETURNING jsonb); produces SIGSEGV for me: #0 getJsonbOffset (index=39920251, jc=0x563cc5601d5c) at jsonb_util.c:148 148 offset += JBE_OFFLENFLD(jc->children[i]); (gdb) bt #0

Re: remove more archiving overhead

On Thu, Jul 07, 2022 at 10:46:23AM -0400, David Steele wrote: > On 7/7/22 10:37, Robert Haas wrote: >> On Thu, Jul 7, 2022 at 10:03 AM Fujii Masao >> wrote: >> > Thanks for updating the patch. It looks good to me. >> > Barring any objection, I'm thinking to commit it. >> >> I don't object, but

System catalog documentation chapter

On Thu, Jul 7, 2022 at 09:29:13AM +1000, Peter Smith wrote: > On Thu, Jun 16, 2022 at 10:59 AM Peter Smith wrote: > > > > On Thu, Jun 9, 2022 at 11:50 PM Tom Lane wrote: > > > > > > Peter Eisentraut writes: > > > > Initially, that chapter did not document any system views. > > > > > > Maybe we

Re: Add a test for "cannot truncate foreign table"

On 2022/07/08 0:33, Tom Lane wrote: Fujii Masao writes: On 2022/06/30 10:48, Yugo NAGATA wrote: When a foreign table has handler but doesn't support TRUNCATE, an error "cannot truncate foreign table xxx" occurs. So, what about adding a test this message output? We can add this test for

Re: Support TRUNCATE triggers on foreign tables

On 2022/06/30 19:38, Yugo NAGATA wrote: Hello, I propose supporting TRUNCATE triggers on foreign tables because some FDW now supports TRUNCATE. I think such triggers are useful for audit logging or for preventing undesired truncate. Patch attached. Thanks for the patch! It looks good to

Re: archive modules

Alvaro Herrera writes: > Well, this does sound unsatisfactory. I suppose one answer would be to > load the module in all backends, in case the user wants to look at the > value. But that would be wasteful. Maybe we should have a warning > about it in the docs -- tell people to LOAD the library

Re: Add a test for "cannot truncate foreign table"

Fujii Masao writes: > On 2022/06/30 10:48, Yugo NAGATA wrote: >> When a foreign table has handler but doesn't support TRUNCATE, >> an error "cannot truncate foreign table xxx" occurs. So, what >> about adding a test this message output? We can add this test >> for file_fdw because it is one of

Re: Add a test for "cannot truncate foreign table"

On 2022/06/30 10:48, Yugo NAGATA wrote: Hello, During checking regression tests of TRUNCATE on foreign tables for other patch [1], I found that there is no test for foreign tables that don't support TRUNCATE. When a foreign table has handler but doesn't support TRUNCATE, an error "cannot

Re: Use outerPlanState macro instead of referring to leffttree

Richard Guo writes: > Update the patch to include changes about righttree. But this doesn't > include changes for edge case usages. (A rough look through shows to me > that the current usages should be able to be covered by tests.) I found a couple other places by grepping, and adjusted those

Re: archive modules

On 2022-Jul-07, talk to ben wrote: > The modified archive module parameters are visible in pg_file_settings. > They don't show up in \dconfig+, which I understand given the query used by > the meta command, but I find a little confusing from an end user POV. Well, this does sound unsatisfactory.

Re: Backup command and functions can cause assertion failure and segmentation fault

On 2022/07/07 9:09, Michael Paquier wrote: On Wed, Jul 06, 2022 at 11:27:58PM +0900, Fujii Masao wrote: For the test, BASE_BACKUP needs to be canceled after it finishes do_pg_backup_start(), i.e., checkpointing, and before it calls do_pg_backup_stop(). So the timing to cancel that seems more

Re: remove more archiving overhead

On 7/7/22 10:37, Robert Haas wrote: On Thu, Jul 7, 2022 at 10:03 AM Fujii Masao wrote: Thanks for updating the patch. It looks good to me. Barring any objection, I'm thinking to commit it. I don't object, but I just started to wonder whether the need to handle re-archiving of the same file

Re: remove more archiving overhead

On Thu, Jul 7, 2022 at 10:03 AM Fujii Masao wrote: > Thanks for updating the patch. It looks good to me. > Barring any objection, I'm thinking to commit it. I don't object, but I just started to wonder whether the need to handle re-archiving of the same file cleanly is as well-documented as it

Re: remove more archiving overhead

On 2022/04/08 7:23, Nathan Bossart wrote: On Thu, Feb 24, 2022 at 09:55:53AM -0800, Nathan Bossart wrote: Yes. I found that a crash at an unfortunate moment can produce multiple links to the same file in pg_wal, which seemed bad independent of archival. By fixing that (i.e., switching from

Re: Fast COPY FROM based on batch insert

On 7/7/2022 06:14, Ian Barwick wrote: 2022年3月24日(木) 15:44 Andrey V. Lepikhov : > > On 3/22/22 06:54, Etsuro Fujita wrote: > > On Fri, Jun 4, 2021 at 5:26 PM Andrey Lepikhov > > wrote: > >> We still have slow 'COPY FROM' operation for foreign tables in current > >> master. > >> Now we

Re: Add checkpoint and redo LSN to LogCheckpointEnd log message

On 2022/07/07 16:26, Kyotaro Horiguchi wrote: + * ControlFileLock is not required as we are the only +* updator of these variables. Isn't it better to add "at this time" or something at the end of the comment because only we're not always

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 7 de jul. de 2022 às 08:00, Peter Eisentraut < peter.eisentr...@enterprisedb.com> escreveu: >diff --git a/src/backend/access/transam/twophase.c b/src/backend/access/transam/twophase.c >index 41b31c5c6f..803d169f57 100644 >--- a/src/backend/access/transam/twophase.c >+++

Re:Improving RLS planning

This causes wrong index scan with RLS. Maybe function restriction_is_securely_promotable is too strict? You can reproduce in this way: create table abc (a integer, b text); insert into abc select (random()*(10^4))::integer, (random()*(10^4))::text from generate_series(1,10); create

Re: DropRelFileLocatorBuffers

On Thu, Jul 7, 2022 at 4:44 AM Kyotaro Horiguchi wrote: > While working on a patch, I met a function with the signature of: > > > DropRelFileLocatorBuffers(SMgrRelation smgr_reln, ForkNumber *forkNum, > > int nforks, BlockNumber > > *firstDelBlock)

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 7 de jul. de 2022 às 08:00, Peter Eisentraut < peter.eisentr...@enterprisedb.com> escreveu: > On 18.05.22 15:52, Peter Eisentraut wrote: > > On 18.05.22 01:18, Justin Pryzby wrote: > >> Take the first one as an example. It says: > >> > >> GenericCosts costs; > >>

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

On 01.07.22 17:58, Ranier Vilela wrote: Em qui., 30 de jun. de 2022 às 19:37, Peter Eisentraut > escreveu: I have also committed a patch that gets rid of MemSet() calls where the value is a constant not-0, because that just falls back to

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

On 2022-Jul-07, Peter Eisentraut wrote: > diff --git a/src/bin/pg_basebackup/pg_basebackup.c > b/src/bin/pg_basebackup/pg_basebackup.c > index 4445a86aee..79b23fa7d7 100644 > --- a/src/bin/pg_basebackup/pg_basebackup.c > +++ b/src/bin/pg_basebackup/pg_basebackup.c > @@ -1952,7 +1948,6 @@

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

On 18.05.22 15:52, Peter Eisentraut wrote: On 18.05.22 01:18, Justin Pryzby wrote: Take the first one as an example.  It says: GenericCosts costs; MemSet(, 0, sizeof(costs)); You sent a patch to change it to sizeof(GenericCosts). But it's not a pointer, so they are the

Re: Make name optional in CREATE STATISTICS

On Thu, 7 Jul 2022 at 12:55, Simon Riggs wrote: > There are various other ways of doing this and, yes, we could refactor > other parts of the grammar to make this work. There is a specific > guideline about patch submission that says the best way to get a patch > rejected is to include

Re: Make name optional in CREATE STATISTICS

On Wed, 6 Jul 2022 at 19:35, Matthias van de Meent wrote: > > On Sun, 15 May 2022 at 14:20, Simon Riggs > wrote: > > > > Currently, CREATE STATS requires you to think of a name for each stats > > object, which is fairly painful, so users would prefer an > > automatically assigned name. > > > >

Re: tuplesort Generation memory contexts don't play nicely with index builds

On 7/6/22 23:15, Tom Lane wrote: David Rowley writes: On Thu, 7 Jul 2022 at 13:41, John Naylor wrote: Hmm, the commit appeared on git.postgresql.org, but apparently not in my email nor the list archives. Strange. I'd suspect a temporary hiccup in whatever code pushes the commits onto the

Re: Add red-black tree missing comparison searches

On Thu, Jul 7, 2022 at 2:16 AM Steve Chavez wrote: > Thanks Alexander! > > wrt to the new patch. I think the following comment is misleading since > keyDeleted can be true or false: > > + /* switch equal_match to false so we only find greater matches now */ > + node = (IntRBTreeNode *)

Re: explain analyze rows=%.0f

On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote: > > > > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston > wrote: >> >> On Wed, Jun 22, 2022 at 12:11 PM Ibrar Ahmed wrote: >>> >>> On Thu, Jun 23, 2022 at 12:01 AM Tom Lane wrote: Robert Haas writes: > On Jun 2, 2009, at

Re: [RFC] building postgres with meson -v9

On 06.07.22 15:21, Andres Freund wrote: Here is my rough assessment of where we are with this patch set: 08b4330ded prereq: deal with \ paths in basebackup_to_shell tests. This still needs clarification, per my previous review. Hm. I thought I had explained that bit, but apparently not. Well,

Re: [PATCH] Log details for client certificate failures

On 05.07.22 18:34, Jacob Champion wrote: On Fri, Jul 1, 2022 at 1:51 PM Jacob Champion wrote: Sorry for the misunderstanding! v3 adds the Issuer to the logs as well. Resending v3; I messed up the certificate diff with my gitconfig. This patch looks pretty good to me. Some minor details:

Re: POC: Lock updated tuples in tuple_update() and tuple_delete()

Hi Alexander, > I'm going to need more time to meditate on the proposed changes and to figure > out the performance impact. OK, turned out this patch is slightly more complicated than I initially thought, but I think I managed to get some vague understanding of what's going on. I tried to

Re: explain analyze rows=%.0f

On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote: > > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston > wrote: >> >> - WRITE_FLOAT_FIELD(rows, "%.0f"); >> + WRITE_FLOAT_FIELD(rows, "%.2f"); >> >> This one looks suspicious, though I haven't dug into the code to see exactly >> what all is

Re: Fix unnecessary includes and comments in 019_replslot_limit.pl, 007_wal.pl and 004_timeline_switch.pl

> > Especially knowing that the test uses a segment size of 1MB via initdb > to be cheaper. v2 looks fine by itself, so applied. > Thanks, Michael! -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com

DropRelFileLocatorBuffers

Hello. While working on a patch, I met a function with the signature of: > DropRelFileLocatorBuffers(SMgrRelation smgr_reln, ForkNumber *forkNum, > int nforks, BlockNumber > *firstDelBlock) It was DropRelFileNodeBuffers(), which means "Drop

Re: Make mesage at end-of-recovery less scary.

At Wed, 6 Jul 2022 11:05:51 -0700, Jacob Champion wrote in > On Mon, Mar 28, 2022 at 11:07 PM Kyotaro Horiguchi > wrote: > > > > Rebased. > > Unfortunately this will need another rebase over latest. Thanks! Done. regards. -- Kyotaro Horiguchi NTT Open Source Software Center >From

Re: In-placre persistance change of a relation

At Wed, 6 Jul 2022 08:44:18 -0700, Jacob Champion wrote in > On Thu, Mar 31, 2022 at 2:36 AM Kyotaro Horiguchi > wrote: > > > > At Thu, 31 Mar 2022 18:33:18 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > I don't think this can be commited to 15. So I post the fixed version > > > then move

Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit

Hi Jacob, On Fri, Jul 1, 2022 at 3:50 AM Jacob Champion wrote: > On 5/12/22 01:46, Etsuro Fujita wrote: > > On Wed, May 11, 2022 at 7:39 PM Etsuro Fujita > > wrote: > >> I’m planning to commit this as a follow-up patch for commit 04e706d42. > > > > Done. > > FYI, I think cfbot is confused

Re: Custom tuplesorts for extensions

On Wed, Jul 6, 2022 at 8:45 PM Alexander Korotkov wrote: > > > From b06bcb5f3666f0541dfcc27c9c8462af2b5ec9e0 Mon Sep 17 00:00:00 2001 > > > From: Alexander Korotkov > > > Date: Wed, 22 Jun 2022 21:48:05 +0300 > > > Subject: [PATCH v2 6/6] Split tuplesortops.c > > > > I strongly suspect this will

Re: archive modules

(Sorry for the spam Nathan) With the list in CC and additional information : The modified archive module parameters are visible in pg_file_settings. They don't show up in \dconfig+, which I understand given the query used by the meta command, but I find a little confusing from an end user POV.

Re: Add checkpoint and redo LSN to LogCheckpointEnd log message

At Thu, 7 Jul 2022 01:11:33 +0900, Fujii Masao wrote in > > > On 2022/03/16 10:29, Kyotaro Horiguchi wrote: > > At Wed, 16 Mar 2022 09:19:13 +0900 (JST), Kyotaro Horiguchi > > wrote in > >> In short, I split out the two topics other than checkpoint log to > >> other threads. > > So, this is

  1   2   >