Re: subtransaction performance regression [kind of] due to snapshot caching

On 2021-04-06 01:34:02 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2021-04-06 00:47:13 -0400, Tom Lane wrote: > >> Not wanting to distract from your point about xactCompletionCount, > >> but ... I wonder if we could get away with defining "isObjectPinned" > >> as "is the OID <= "

Re: Replication slot stats misgivings

On Mon, Mar 22, 2021 at 9:55 AM Masahiko Sawada wrote: > > On Sat, Mar 20, 2021 at 3:52 AM Andres Freund wrote: > > > > > > - PgStat_ReplSlotStats etc use slotname[NAMEDATALEN]. Why not just NameData? > > That's because we followed other definitions in pgstat.h that use > char[NAMEDATALEN]. I'm

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 01.04.21 20:49, Peter Eisentraut wrote: also done I also figured out a way to combine the float8 and numeric implementations so that there is not so much duplication.  Added tests to cover all the edge and overflow cases. I think this is solid now. The extract(julian from timestamp) is

Reference Leak with type

Hi All , I found the below reference leak on master. Steps to reproduce the issue : --1) create type create type float_array_typ as ( i float8); --2) create anonymous block postgres=# do $$ declare a float_array_typ[]; begin a[1].i := 11; commit; end $$; WARNING: TupleDesc reference

Re: subtransaction performance regression [kind of] due to snapshot caching

Andres Freund writes: > On 2021-04-06 00:47:13 -0400, Tom Lane wrote: >> Not wanting to distract from your point about xactCompletionCount, >> but ... I wonder if we could get away with defining "isObjectPinned" >> as "is the OID <= " (and, in consequence, dropping explicit pin >> entries

Re: Table refer leak in logical replication

On Tue, Apr 6, 2021 at 1:57 PM Masahiko Sawada wrote: > On Tue, Apr 6, 2021 at 1:15 PM Amit Langote wrote: > > On Tue, Apr 6, 2021 at 1:01 PM houzj.f...@fujitsu.com > > > The commit introduced a > > > > new function ExecInitResultRelation() that sets both > > > > estate->es_result_relations and

Re: typo fix in pgstat.c: "exits should be exists"

On Tue, Apr 6, 2021 at 10:41 AM Fujii Masao wrote: > > > > On 2021/04/06 13:57, vignesh C wrote: > > Hi, > > > > While reviewing replication statistics I found a small typo. Attached > > patch for a typo in: > > src/backend/postmaster/pgstat.c > > Thanks for the report and patch! Pushed. >

Re: Support ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION ... syntax

On Sat, 03 Apr 2021 at 13:20, Bharath Rupireddy wrote: > On Sat, Apr 3, 2021 at 1:29 AM Peter Eisentraut > wrote: >> The code you have in merge_publications() to report all existing >> publications is pretty messy and is not properly internationalized. I >> think what you are trying to do

Re: subtransaction performance regression [kind of] due to snapshot caching

Hi, On 2021-04-06 00:47:13 -0400, Tom Lane wrote: > Andres Freund writes: > > The time in 14 is spent mostly below: > > - 94.58% 0.01% postgres postgres[.] CreateFunction > >- 94.57% CreateFunction > > - 94.49% ProcedureCreate > > - 90.95%

Re: Proposal: Save user's original authenticated identity for logging

On Mon, Apr 05, 2021 at 04:40:41PM +, Jacob Champion wrote: > This loses the test fixes I made in my v19 [1]; some of the tests on > HEAD aren't testing anything anymore. I've put those fixups into 0001, > attached. Argh, Thanks. The part about not checking after the error output when the

Re: typo fix in pgstat.c: "exits should be exists"

On 2021/04/06 13:57, vignesh C wrote: Hi, While reviewing replication statistics I found a small typo. Attached patch for a typo in: src/backend/postmaster/pgstat.c Thanks for the report and patch! Pushed. Regards, -- Fujii Masao Advanced Computing Technology Center Research and

typo fix in pgstat.c: "exits should be exists"

Hi, While reviewing replication statistics I found a small typo. Attached patch for a typo in: src/backend/postmaster/pgstat.c /* -* Check if the slot exits with the given name. It is possible that by +* Check if the slot exists

Re: Table refer leak in logical replication

On Tue, Apr 6, 2021 at 1:15 PM Amit Langote wrote: > > On Tue, Apr 6, 2021 at 1:01 PM houzj.f...@fujitsu.com > wrote: > > > > > insert into test values (6); > > > > > > > > > > It seems an issue about reference leak. Anyone can fix this? > > > > > > > > It seems ExecGetTriggerResultRel will

Re: subtransaction performance regression [kind of] due to snapshot caching

Andres Freund writes: > The time in 14 is spent mostly below: > - 94.58% 0.01% postgres postgres[.] CreateFunction >- 94.57% CreateFunction > - 94.49% ProcedureCreate > - 90.95% record_object_address_dependencies > - 90.93%

Re: Get memory contexts of an arbitrary backend process

On 2021/04/06 10:57, torikoshia wrote: I don't have any objections to your improvements. Thanks for the check! I pushed the patch. Thanks a lot! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION

subtransaction performance regression [kind of] due to snapshot caching

Hi, In a recent thread ([1]) I found a performance regression of the following statement DO $do$ BEGIN FOR i IN 1 .. 1 LOOP BEGIN EXECUTE $cf$CREATE OR REPLACE FUNCTION foo() RETURNS VOID LANGUAGE plpgsql AS $f$BEGIN frakbar; END;$f$;$cf$; EXCEPTION WHEN

Re: TRUNCATE on foreign table

On Mon, Apr 5, 2021 at 8:47 PM Kazutaka Onishi wrote: > > > Did you check that hash_destroy is not reachable when an error occurs > > on the remote server while executing truncate command? > > I've checked it and hash_destroy doesn't work on error. > > I just adding elog() to check this: > +

Re: Table refer leak in logical replication

On Tue, Apr 6, 2021 at 1:01 PM houzj.f...@fujitsu.com wrote: > > > > insert into test values (6); > > > > > > > > It seems an issue about reference leak. Anyone can fix this? > > > > > > It seems ExecGetTriggerResultRel will reopen the target table because it > > cannot find an existing one. > >

RE: Stronger safeguard for archive recovery not to miss data

On Tuesday, April 6, 2021 9:41 AM Fujii Masao > On 2021/04/05 23:54, osumi.takami...@fujitsu.com wrote: > >> This makes me think that we should document this risk Thought? > > +1. We should notify the risk when user changes > > the wal_level higher than minimal to minimal to invoke a

document that brin's autosummarize parameter is off by default

Hi everyone, Just noted that the default value of autosummarize reloption for brin indexes is not documented, or at least not well documented. I added the default value in create_index.sgml where other options mention their own defaults, also made a little change in brin.sgml to make it more

RE: Table refer leak in logical replication

> > > insert into test values (6); > > > > > > It seems an issue about reference leak. Anyone can fix this? > > > > It seems ExecGetTriggerResultRel will reopen the target table because it > cannot find an existing one. > > Storing the opened table in estate->es_opened_result_relations seems >

Re: Binary search in ScalarArrayOpExpr for OR'd constant arrays

On Sat, 20 Mar 2021 at 09:41, James Coleman wrote: > I've attached a cleaned up patch. Last CF it was listed in is > https://commitfest.postgresql.org/29/2542/ -- what's the appropriate > step to take here given it's an already existing patch, but not yet > moved into recent CFs? I had a look at

Re: ALTER TABLE ADD COLUMN fast default

> "Andrew" == Andrew Dunstan writes: Andrew> I'd be curious to know how this state came about. Me too, but available information is fairly sparse: PG 12.5, in a container, backing a (personal) instance of Gitlab; the only database admin operations should have been those done by Gitlab

Re: Table refer leak in logical replication

On Tue, Apr 6, 2021 at 10:15 AM houzj.f...@fujitsu.com wrote: > > > WARNING: relcache reference leak: relation "xxx" not closed. > > > > Example of the procedure: > > --publisher-- > > create table test (a int primary key); > > create publication pub for table test; > > > >

Re: New IndexAM API controlling index vacuum strategies

On Mon, Apr 5, 2021 at 2:44 PM Matthias van de Meent wrote: > This assertion is false, and should be a guarding if-statement. HOT > redirect pointers are not updated if the tuple they're pointing to is > vacuumed (i.e. when it was never committed) so this nextoffnum might > in a correctly working

Re: Asynchronous Append on postgres_fdw nodes.

Thanks for the patch. At Mon, 5 Apr 2021 17:15:47 +0900, Etsuro Fujita wrote in > On Fri, Apr 2, 2021 at 12:09 AM Tom Lane wrote: > > The buildfarm points out that this fails under valgrind. > > I easily reproduced it here: > > > > ==00:00:03:42.115 3410499== Syscall param epoll_wait(events)

Re: policies with security definer option for allowing inline optimization

This is great, thanks! It's great to have somewhere in the source to read about the optimizer! very cool! > > > I suppose if the > > get_group_ids_of_current_user() function is marked as STABLE, would the > > optimizer cache this value for every row in a SELECT that returned > > multiple rows? >

Re: Get memory contexts of an arbitrary backend process

On 2021-04-06 00:08, Fujii Masao wrote: On 2021/04/05 21:03, torikoshia wrote: On 2021-04-05 12:59, Fujii Masao wrote: On 2021/04/05 12:20, Zhihong Yu wrote: Thanks for reviewing! + * On receipt of this signal, a backend sets the flag in the signal + * handler, and then which causes the

RE: Table refer leak in logical replication

> BTW, it seems better to add a testcase for this ? I think the test for it can be added in src/test/subscription/t/003_constraints.pl, which is like what in my patch. Regards, Shi yu tests_for_table_refer_leak.diff Description: tests_for_table_refer_leak.diff

RE: Table refer leak in logical replication

> WARNING: relcache reference leak: relation "xxx" not closed. > > Example of the procedure: > --publisher-- > create table test (a int primary key); > create publication pub for table test; > > --subscriber-- > create table test (a int primary key); > create subscription sub

Table refer leak in logical replication

Hi I met a problem about trigger in logical replication. I created a trigger after inserting data at subscriber, but there is a warning in the log of subscriber when the trigger fired: WARNING: relcache reference leak: relation "xxx" not closed. Example of the procedure: --publisher--

Re: Stronger safeguard for archive recovery not to miss data

On 2021/04/05 23:49, osumi.takami...@fujitsu.com wrote: Some minor comments. Thanks for the review! (1) + # Confirm that the archive recovery fails with an error + my $logfile = slurp_file($recovery_node->logfile()); + ok( $logfile =~ + qr/FATAL: WAL was

Re: New IndexAM API controlling index vacuum strategies

Hi, On 2021-04-05 17:18:37 -0700, Peter Geoghegan wrote: > On Mon, Apr 5, 2021 at 5:09 PM Peter Geoghegan wrote: > > Oh yeah. "static BufferAccessStrategy vac_strategy" is guaranteed to > > be initialized to 0, simply because it's static and global. That > > explains it. > > So do we need to

Re: New IndexAM API controlling index vacuum strategies

On Mon, Apr 5, 2021 at 5:09 PM Peter Geoghegan wrote: > Oh yeah. "static BufferAccessStrategy vac_strategy" is guaranteed to > be initialized to 0, simply because it's static and global. That > explains it. So do we need to allocate a strategy in workers now, or leave things as they are/were?

RE: Stronger safeguard for archive recovery not to miss data

On Tuesday, April 6, 2021 8:32 AM Osumi, Takamichi/大墨 昂道 > On Monday, April 5, 2021 11:49 PM osumi.takami...@fujitsu.com > > > On Mon Apr 5, 2021 12:35 PM Fujii Masao > > wrote: > > > >>> By the way, when I build postgres with this patch and > > > >>> enable-coverage option, the results of RT

Re: New IndexAM API controlling index vacuum strategies

On Mon, Apr 5, 2021 at 5:00 PM Andres Freund wrote: > What do you mean with "appear to work"? Isn't, in 13, the only > consequence of vac_strategy not being "propagated" that we'll not use a > strategy in parallel workers? Presumably that was hard to notice > because most people don't run manual

Re: New IndexAM API controlling index vacuum strategies

Hi, On 2021-04-05 16:53:58 -0700, Peter Geoghegan wrote: > REL_13_STABLE will need to be considered separately. I still haven't > figured out how this ever appeared to work for this long. The > vac_strategy/bstrategy state simply wasn't propagated at all. What do you mean with "appear to work"?

Re: New IndexAM API controlling index vacuum strategies

On Mon, Apr 5, 2021 at 4:29 PM Tom Lane wrote: > Peter Geoghegan writes: > > Do you think that it's okay that we rely on the propagation of global > > state to parallel workers on Postgres 13? Don't we need something like > > my fixup commit 49f49def on Postgres 13 as well? At least for the > >

Re: postgres_fdw: IMPORT FOREIGN SCHEMA ... LIMIT TO (partition)

On 2021/03/29 2:39, Bernd Helmle wrote: Am Mittwoch, dem 24.03.2021 um 17:32 +0100 schrieb Bernd Helmle: Yes, but it should be noted that the main reason that was mentioned as a reason to exclude partitions is to not cause table catalog bloat, and I argue that this argument is not as solid

Re: New IndexAM API controlling index vacuum strategies

On Tue, Apr 6, 2021 at 8:29 AM Tom Lane wrote: > > Peter Geoghegan writes: > > Do you think that it's okay that we rely on the propagation of global > > state to parallel workers on Postgres 13? Don't we need something like > > my fixup commit 49f49def on Postgres 13 as well? At least for the >

RE: Stronger safeguard for archive recovery not to miss data

On Monday, April 5, 2021 11:49 PM osumi.takami...@fujitsu.com > On Mon Apr 5, 2021 12:35 PM Fujii Masao > wrote: > > >>> By the way, when I build postgres with this patch and > > >>> enable-coverage option, the results of RT becomes unstable. Does > > >>> someone know the > > >> reason ? > >

Re: New IndexAM API controlling index vacuum strategies

Peter Geoghegan writes: > Do you think that it's okay that we rely on the propagation of global > state to parallel workers on Postgres 13? Don't we need something like > my fixup commit 49f49def on Postgres 13 as well? At least for the > EXEC_BACKEND case, I think. Uh ... *what* propagation of

Re: [PATCH] Covering SPGiST index

Pavel Borisov writes: > In a v14 I forgot to add the test. PFA v15 I've committed this with a lot of mostly-cosmetic changes. The not-so-cosmetic bits had to do with confusion between the input data type and the leaf type, which isn't really your fault because it was there before :-(. One note

Re: New IndexAM API controlling index vacuum strategies

On Mon, Apr 5, 2021 at 4:30 AM Masahiko Sawada wrote: > Did you try the change around parallel_process_one_index() that I > suggested in the previous reply[1]? If we don't change the logic, we > need to update the above comment. Previously, we update stats[idx] in > vacuum_one_index() (renamed to

Re: New IndexAM API controlling index vacuum strategies

On Sun, 4 Apr 2021 at 04:00, Peter Geoghegan wrote: > > On Thu, Apr 1, 2021 at 8:25 PM Peter Geoghegan wrote: > > I've also found a way to further simplify the table-without-indexes > > case: make it behave like a regular two-pass/has-indexes VACUUM with > > regard to visibility map stuff when

Re: Have I found an interval arithmetic bug?

> On 05-Apr-2021, at 13:35, Bruce Momjian wrote: > > On Mon, Apr 5, 2021 at 01:06:36PM -0700, Bryn Llewellyn wrote: >>> On 05-Apr-2021, at 11:37, Bruce Momjian wrote On: >>> Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote : >> >> It seems to me that this whole business is an

Re: Have I found an interval arithmetic bug?

On Mon, Apr 5, 2021 at 01:06:36PM -0700, Bryn Llewellyn wrote: > > On 05-Apr-2021, at 11:37, Bruce Momjian wrote On: > > Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote : > > It seems to me that this whole business is an irrevocable mess. The > original design could have

Table AM and DROP TABLE [ Was: Table AM and DDLs]

On Mon, Mar 22, 2021 at 12:16 AM Andres Freund wrote: > Hi, > > On 2021-03-03 22:15:18 +0100, Mats Kindahl wrote: > > On Tue, Feb 23, 2021 at 2:11 AM Andres Freund > wrote: > > Thanks for the answer and sorry about the late reply. > > Mine is even later ;) > :) Seems I keep the tradition. :)

Re: Stronger safeguard for archive recovery not to miss data

On 4/4/21 11:34 PM, Fujii Masao wrote: On 2021/04/04 11:58, osumi.takami...@fujitsu.com wrote: IMO it's better to comment why this server restart is necessary. As far as I understand correctly, this is necessary to ensure the WAL file containing the record about the change of wal_level (to

Re: Have I found an interval arithmetic bug?

On Mon, Apr 5, 2021 at 01:15:22PM -0500, Justin Pryzby wrote: > On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote: > > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote: > > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT > > > >

Re: [PATCH] New default role allowing to change per-role/database settings

Greetings Michael, * Michael Banck (michael.ba...@credativ.de) wrote: > Am Montag, den 08.03.2021, 20:54 +0500 schrieb Ibrar Ahmed: > > On Thu, Dec 31, 2020 at 6:16 PM Michael Banck > > wrote: > > > in today's world, some DBAs have no superuser rights, but we can > > > delegate them additional

Re: Have I found an interval arithmetic bug?

On Mon, Apr 05, 2021 at 02:01:58PM -0400, Bruce Momjian wrote: > On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote: > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-INTERVAL-INPUT > > > « …field values can have fractional parts; for example '1.5 week' or >

Re: Have I found an interval arithmetic bug?

On Mon, Apr 5, 2021 at 11:33:10AM -0500, Justin Pryzby wrote: > On Fri, Apr 02, 2021 at 10:21:26PM -0400, Bruce Momjian wrote: > > I wish I could figure out how to improve it any futher. What is odd is > > that I have never seen this reported as a problem before. I plan to > > apply this early

Re: New predefined roles- 'pg_read/write_all_data'

Greetings, * Stephen Frost (sfr...@snowman.net) wrote: > Updated patch attached. Will be playing with it a bit more but > generally feel like it's in pretty good shape. Unless there's anything > further on this, I'll likely commit it over the weekend. Weekend ended up being a bit busy, but

Re: Failed assertion on standby while shutdown

On 2021/04/05 16:30, Maxim Orlov wrote: Well done! In my view is just what it's needed. Thanks for the review! I pushed the patch. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION

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

On Sun, Apr 4, 2021 at 10:18:50PM +0800, Julien Rouhaud wrote: > On Fri, Apr 02, 2021 at 01:33:28PM +0800, Julien Rouhaud wrote: > > On Thu, Apr 01, 2021 at 03:27:11PM -0400, Bruce Momjian wrote: > > > > > > OK, I am happy with your design decisions, thanks. > > > > Thanks! While double

Re: Proposal: Save user's original authenticated identity for logging

On Mon, 2021-04-05 at 14:47 +0900, Michael Paquier wrote: > On Sat, Apr 03, 2021 at 09:30:25PM +0900, Michael Paquier wrote: > > Slight rebase for this one to take care of the updates with the SSL > > error messages. > > I have been looking again at that and applied it as c50624cd after > some

Re: Have I found an interval arithmetic bug?

On Fri, Apr 02, 2021 at 10:21:26PM -0400, Bruce Momjian wrote: > I wish I could figure out how to improve it any futher. What is odd is > that I have never seen this reported as a problem before. I plan to > apply this early next week for PG 14. On Fri, Apr 02, 2021 at 01:05:42PM -0700, Bryn

Re: ALTER TABLE ADD COLUMN fast default

Zhihong Yu writes: >> if (found != ncheck) > Since there is check on found being smaller than ncheck inside the loop, > the if condition can be written as: > if (found < ncheck) Doesn't really seem like an improvement? Nor am I excited about renaming these "found" variables,

Re: ALTER TABLE ADD COLUMN fast default

Andrew Dunstan writes: > On 4/4/21 6:50 PM, Tom Lane wrote: >> Meh. "pg_class.relchecks is inconsistent with the number of entries >> in pg_constraint" does not seem to me like a scary enough situation >> to justify a panic response. Maybe there's an argument for failing >> at the point where

Re: Additional Chapter for Tutorial - arch-dev.sgml

On 2021-Apr-05, Jürgen Purtz wrote: > In addition to this chain Erik introduced in November within the same thread > some changes to the chapter "Overview of Query Handling", which subsequently > was expanded by Heikki and me with the sequence of > 'arch-dev.sgml.x.diff' files. This is what I

Re: Replication slot stats misgivings

On Sat, Apr 3, 2021 at 11:07 PM vignesh C wrote: > > On Fri, Apr 2, 2021 at 9:29 AM Masahiko Sawada wrote: > > > > On Fri, Apr 2, 2021 at 1:55 AM vignesh C wrote: > > > > > > On Thu, Apr 1, 2021 at 5:58 PM Amit Kapila > > > wrote: > > > > > > > > On Thu, Apr 1, 2021 at 3:43 PM vignesh C

Re: TRUNCATE on foreign table

> Did you check that hash_destroy is not reachable when an error occurs > on the remote server while executing truncate command? I've checked it and hash_destroy doesn't work on error. I just adding elog() to check this: + elog(NOTICE,"destroyed"); + hash_destroy(ft_htab); Then I've checked by

Re: Get memory contexts of an arbitrary backend process

On 2021/04/05 21:03, torikoshia wrote: On 2021-04-05 12:59, Fujii Masao wrote: On 2021/04/05 12:20, Zhihong Yu wrote: Thanks for reviewing! + * On receipt of this signal, a backend sets the flag in the signal + * handler, and then which causes the next CHECK_FOR_INTERRUPTS() I think

RE: Stronger safeguard for archive recovery not to miss data

On Monday, April 5, 2021 9:16 PM Fujii Masao wrote: > On 2021/04/05 16:13, Kyotaro Horiguchi wrote: > > At Mon, 5 Apr 2021 12:34:53 +0900, Fujii Masao > > wrote in > >> > >> > >> On 2021/04/04 11:58, osumi.takami...@fujitsu.com wrote: > IMO it's better to comment why this server restart

RE: Stronger safeguard for archive recovery not to miss data

On Mon Apr 5, 2021 12:35 PM Fujii Masao wrote: > On 2021/04/04 11:58, osumi.takami...@fujitsu.com wrote: > >> IMO it's better to comment why this server restart is necessary. > >> As far as I understand correctly, this is necessary to ensure the WAL > >> file containing the record about the

Re: use AV worker items infrastructure for GIN pending list's cleanup

On Mon, Apr 05, 2021 at 10:41:22AM -0300, Euler Taveira wrote: > On Mon, Apr 5, 2021, at 3:31 AM, Jaime Casanova wrote: > > When AV worker items where introduced 4 years ago, i was suggested that > > it could be used for other things like cleaning the pending list of GIN > > index when it reaches

Re: TRUNCATE on foreign table

On Mon, Apr 5, 2021 at 7:38 PM Kazutaka Onishi wrote: > > 3) I think we need truncatable behaviour that is consistent with updatable. > > It's not correct. "truncatable" option works the same as "updatable". > I've confirmed that the table can be truncated with the combination: > truncatable on

Re: TRUNCATE on foreign table

Thank you for your comments. I've attached v13. > Here are some more comments on the v12 patch: > I still don't understand why we need sum(id), not count(*). Am I > missing something here? The value of "id" is used for checking whether correct records are truncated or not. For instance, on

Re: Replication slot stats misgivings

On Mon, Apr 5, 2021 at 12:44 PM Bharath Rupireddy wrote: > > On Sat, Apr 3, 2021 at 11:12 PM vignesh C wrote: > > Here pg_stat_replication_slots will not have enought slots. I changed > > it to below: > > errmsg("skipping \"%s\" replication slot statistics as > > pg_stat_replication_slots does

Re: Logical Replication - improve error message while adding tables to the publication in check_publication_add_relation

On Mon, Apr 5, 2021 at 6:41 PM Euler Taveira wrote: > Here's the v4 patch reabsed on the latest master, please review it further. > > /* UNLOGGED and TEMP relations cannot be part of publication. */ > if (!RelationIsPermanent(targetrel)) > - ereport(ERROR, > -

Re: ModifyTable overheads in generic plans

On Mon, Apr 5, 2021 at 1:43 AM Tom Lane wrote: > Amit Langote writes: > > On Sun, Apr 4, 2021 at 10:20 AM Tom Lane wrote: > >> In some desultory performance testing here, it seemed like a > >> significant part of the cost is ExecOpenIndices, and I don't see > >> a reason offhand why we could

Re: use AV worker items infrastructure for GIN pending list's cleanup

On Mon, Apr 5, 2021, at 3:31 AM, Jaime Casanova wrote: > When AV worker items where introduced 4 years ago, i was suggested that > it could be used for other things like cleaning the pending list of GIN > index when it reaches gin_pending_list_limit instead of making user > visible operation pay

Re: ALTER TABLE ADD COLUMN fast default

On 4/4/21 6:50 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 4/4/21 12:05 PM, Tom Lane wrote: >>> I made CheckConstraintFetch likewise not install its array until >>> it's done. I notice that it is throwing elog(ERROR) not WARNING >>> for the equivalent cases of not finding the right

Re: badly calculated width of emoji in psql

po 5. 4. 2021 v 7:07 odesílatel Kyotaro Horiguchi napsal: > At Fri, 2 Apr 2021 11:51:26 +0200, Pavel Stehule > wrote in > > with this patch, the formatting is correct > > I think the hardest point of this issue is that we don't have a > reasonable authoritative source that determines character

Re: Logical Replication - improve error message while adding tables to the publication in check_publication_add_relation

On Mon, Apr 5, 2021, at 12:27 AM, Bharath Rupireddy wrote: > On Fri, Mar 26, 2021 at 9:25 AM Bharath Rupireddy > > wrote: > > Here's the v3 patch rebased on the latest master. > > Here's the v4 patch reabsed on the latest master, please review it

Re: [EXTERNAL] Re: Crash in record_type_typmod_compare

Hi Andres, Please see the updated patch, do you mean something like this? (there might be a simpler way for doing this) Best, Talha. From: Andres Freund Sent: Wednesday, March 31, 2021 10:49 PM To: Sait Talha Nisanci Cc: pgsql-hackers ; Metin Doslu Subject:

Re: Stronger safeguard for archive recovery not to miss data

On 2021/04/05 16:13, Kyotaro Horiguchi wrote: At Mon, 5 Apr 2021 12:34:53 +0900, Fujii Masao wrote in On 2021/04/04 11:58, osumi.takami...@fujitsu.com wrote: IMO it's better to comment why this server restart is necessary. As far as I understand correctly, this is necessary to ensure

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

On Mon, Apr 5, 2021, at 4:06 AM, Amit Kapila wrote: > I have made few minor changes in the attached. (a) Initialize the > streaming message callback API, (b) update docs to reflect that XID > can be sent for streaming of in-progress transactions, I see that the > same information needs to be

Re: pgbench - add pseudo-random permutation function

Hello Dean, I think that permute should only use integer operations. I'd suggest to use one of the integer variants instead of going through a double computation and casting back to int. The internal state is based on integers, I do not see the added value of going through floats, possibly

Re: Get memory contexts of an arbitrary backend process

On 2021-04-05 12:59, Fujii Masao wrote: On 2021/04/05 12:20, Zhihong Yu wrote: Thanks for reviewing! + * On receipt of this signal, a backend sets the flag in the signal + * handler, and then which causes the next CHECK_FOR_INTERRUPTS() I think the 'and then' is not needed: Although I

Re: Flaky vacuum truncate test in reloptions.sql

On Mon, Apr 5, 2021 at 5:00 AM Arseny Sher wrote: > > > On Fri, Apr 2, 2021 at 9:46 AM Michael Paquier wrote: > > > Okay, applied and back-patched down to 12 then. > > Thank you both. Unfortunately and surprisingly, the test still fails > (perhaps even rarer, once in several hundred runs) under

Re: New IndexAM API controlling index vacuum strategies

On Sun, Apr 4, 2021 at 11:00 AM Peter Geoghegan wrote: > > On Thu, Apr 1, 2021 at 8:25 PM Peter Geoghegan wrote: > > I've also found a way to further simplify the table-without-indexes > > case: make it behave like a regular two-pass/has-indexes VACUUM with > > regard to visibility map stuff

Re: [Patch] ALTER SYSTEM READ ONLY

On Mon, Apr 5, 2021 at 11:02 AM Amul Sul wrote: > > Attached is the rebase version for the latest master head(commit # > 9f6f1f9b8e6). Some minor comments on 0001: Isn't it "might not be running"? + errdetail("Checkpointer might not running."), Isn't it "Try again after

Re: Why reset pgstat during recovery

 On 2021/04/02 18:41, 蔡梦娟(玊于) wrote: > > Hi, all > > I want to know why call pgstat_reset_all function during recovery > process, under what circumstances the data will be invalid after recovery? If my understanding is right, PITR is the case. Now, the stats files are generated as a

Re: shared memory stats: high level design decisions: consistency, dropping

Hi, I did end up implementing the configurable fetch consistency. Seems to work well, and it's not that much code after a bunch of other cleanups. See below the quoted part at the bottom. I just posted the latest iteration of that code at

Re: Is it useful to record whether plans are generic or custom?

On 2021-03-26 17:46, Fujii Masao wrote: On 2021/03/26 0:33, torikoshia wrote: On 2021-03-25 22:14, Fujii Masao wrote: On 2021/03/23 16:32, torikoshia wrote: On 2021-03-05 17:47, Fujii Masao wrote: Thanks for your comments! Thanks for updating the patch! PostgreSQL Patch Tester reported

Re: Asynchronous Append on postgres_fdw nodes.

On Fri, Apr 2, 2021 at 12:09 AM Tom Lane wrote: > The buildfarm points out that this fails under valgrind. > I easily reproduced it here: > > ==00:00:03:42.115 3410499== Syscall param epoll_wait(events) points to > unaddressable byte(s) > ==00:00:03:42.115 3410499==at 0x58E926B: epoll_wait

RE: Stronger safeguard for archive recovery not to miss data

From: Kyotaro Horiguchi > I didn't see that, but found the following article. > > https://stackoverflow.com/questions/2590794/gcov-warning-merge-mismat > ch-for-summaries ... > It seems like your working directory needs some cleanup. That could very well be. It'd be safer to run "make

Re: Stronger safeguard for archive recovery not to miss data

At Mon, 5 Apr 2021 07:04:09 +, "tsunakawa.ta...@fujitsu.com" wrote in > From: osumi.takami...@fujitsu.com > > By the way, when I build postgres with this patch and enable-coverage > > option, > > the results of RT becomes unstable. Does someone know the reason ? > > When it fails, I get

Re: Failed assertion on standby while shutdown

On 2021-04-01 15:02, Fujii Masao wrote: On 2021/03/31 19:51, Maxim Orlov wrote: On 2021-03-30 20:44, Maxim Orlov wrote: The following review has been posted through the commitfest application: make installcheck-world:  tested, passed Implements feature:   tested, passed Spec compliant:

Re: Replication slot stats misgivings

On Sat, Apr 3, 2021 at 11:12 PM vignesh C wrote: > Here pg_stat_replication_slots will not have enought slots. I changed > it to below: > errmsg("skipping \"%s\" replication slot statistics as > pg_stat_replication_slots does not have enough slots" > Thoughts? WFM. > > 3) Should we change the

Re: Stronger safeguard for archive recovery not to miss data

At Mon, 5 Apr 2021 12:34:53 +0900, Fujii Masao wrote in > > > On 2021/04/04 11:58, osumi.takami...@fujitsu.com wrote: > >> IMO it's better to comment why this server restart is necessary. > >> As far as I understand correctly, this is necessary to ensure the WAL > >> file > >> containing the

Re: Any objections to implementing LogicalDecodeMessageCB for pgoutput?

On Sat, Apr 3, 2021 at 5:26 AM Euler Taveira wrote: > > On Thu, Apr 1, 2021, at 7:19 AM, Amit Kapila wrote: > > This new patch set version has 2 patches that is because there are 2 separate > changes: parse_output_parameters() refactor and logical decoding message > support. > I have made few

RE: Stronger safeguard for archive recovery not to miss data

From: osumi.takami...@fujitsu.com > By the way, when I build postgres with this patch and enable-coverage option, > the results of RT becomes unstable. Does someone know the reason ? > When it fails, I get stderr like below > > t/001_start_stop.pl .. 10/24 > # Failed test 'pg_ctl start: no

use AV worker items infrastructure for GIN pending list's cleanup

Hi, When AV worker items where introduced 4 years ago, i was suggested that it could be used for other things like cleaning the pending list of GIN index when it reaches gin_pending_list_limit instead of making user visible operation pay the price. That never happened though. So, here is a

Re: [PATCH] Implement motd for PostgreSQL

On Sun, Apr 4, 2021, at 20:42, Dagfinn Ilmari Mannsåker wrote: > Fabien COELHO mailto:coelho%40cri.ensmp.fr>> writes: > > >>> The actual source looks pretty straightforward. I'm wondering whether pg > >>> style would suggest to write motd != NULL instead of just motd. > >> > >> That's what I had