Re: TRUNCATE on foreign table

On 2021/04/26 13:52, Bharath Rupireddy wrote: On Fri, Apr 23, 2021 at 9:50 PM Fujii Masao wrote: Thanks for the review! I fixed this. Thanks for the updated patches. In docs v4 patch, I think we can combine below two lines into a single line: + supported by the foreign data wrapper,

Re: [PATCH] Re: pg_identify_object_as_address() doesn't support pg_event_trigger oids

On Tue, 27 Apr 2021 at 13:16, Joel Jacobson wrote: > On Mon, Apr 26, 2021, at 10:30, Michael Paquier wrote: >> On Fri, Apr 23, 2021 at 09:33:36AM +0200, Joel Jacobson wrote: >> > Also, since this is a problem also in v13 maybe this should also be >> > back-ported? I think it's a bug since both

Re: Skip temporary table schema name from explain-verbose output.

On Tue, Apr 27, 2021 at 10:51 AM Amul Sul wrote: > > Hi, > > Temporary tables usually gets a unique schema name, see this: > > postgres=# create temp table foo(i int); > CREATE TABLE > postgres=# explain verbose select * from foo; >QUERY PLAN >

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Tue, Apr 27, 2021 at 8:07 AM Andres Freund wrote: > > Hi, > > On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote: > > On 4/26/21 9:27 PM, Andres Freund wrote: > > > On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote: > > > > I'm not sure what to do about this :-( I don't have any ideas about how

Re: [BUG] "FailedAssertion" reported when streaming in logical replication

On Mon, Apr 26, 2021 at 7:52 PM Dilip Kumar wrote: > > On Mon, Apr 26, 2021 at 6:59 PM Amit Kapila wrote: > > > > On Mon, Apr 26, 2021 at 5:55 PM Dilip Kumar wrote: > > > > > > I am able to reproduce this and I think I have done the initial > > > investigation. > > > > > > The cause of the

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 9:48 AM vignesh C wrote: > > On Tue, Apr 27, 2021 at 9:43 AM Amit Kapila wrote: > > > > On Tue, Apr 27, 2021 at 9:17 AM Masahiko Sawada > > wrote: > > > > > > On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote: > > > > > > > > > > And I think there is > > > > > > also a

Skip temporary table schema name from explain-verbose output.

Hi, Temporary tables usually gets a unique schema name, see this: postgres=# create temp table foo(i int); CREATE TABLE postgres=# explain verbose select * from foo; QUERY PLAN - Seq Scan on pg_temp_3.foo

Re: [PATCH] Re: pg_identify_object_as_address() doesn't support pg_event_trigger oids

On Mon, Apr 26, 2021, at 10:30, Michael Paquier wrote: > On Fri, Apr 23, 2021 at 09:33:36AM +0200, Joel Jacobson wrote: > > Also, since this is a problem also in v13 maybe this should also be > > back-ported? I think it's a bug since both > > pg_identify_object_as_address() and event triggers

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 1:18 PM vignesh C wrote: > > On Tue, Apr 27, 2021 at 9:43 AM Amit Kapila wrote: > > > > On Tue, Apr 27, 2021 at 9:17 AM Masahiko Sawada > > wrote: > > > > > > On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote: > > > > > > > > > > And I think there is > > > > > > also a

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 9:43 AM Amit Kapila wrote: > > On Tue, Apr 27, 2021 at 9:17 AM Masahiko Sawada wrote: > > > > On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote: > > > > > > > > And I think there is > > > > > also a risk to increase shared memory when we want to add other > > > > >

Re: Truncate in synchronous logical replication failed

On Mon, Apr 26, 2021 at 12:37 PM Japin Li wrote: > > On Mon, 26 Apr 2021 at 12:49, Amit Kapila wrote: > > On Fri, Apr 23, 2021 at 7:18 PM osumi.takami...@fujitsu.com > > wrote: > >> > > > > The latest patch looks good to me. I have made a minor modification > > and added a commit message in the

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 9:17 AM Masahiko Sawada wrote: > > On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote: > > > > > > And I think there is > > > > also a risk to increase shared memory when we want to add other > > > > statistics in the future. > > > > > > > > > > Yeah, so do you think it is

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Sat, Apr 24, 2021 at 12:53 PM Amit Kapila wrote: > > On Fri, Apr 23, 2021 at 6:45 PM Tom Lane wrote: > > > > Greg Nancarrow writes: > > > I'm curious. The FmgrBuiltin struct includes the "strict" flag, so > > > that would "lock down the value" of the strict flag, wouldn't it? > > > > It

Re: logical replication empty transactions

On Mon, Apr 26, 2021 at 4:29 PM Peter Smith wrote: > The v4 patch applied cleanly. > > make check-world completed successfully. > > So this patch v4 looks LGTM, apart from the following 2 nitpick comments: > > == > > 1. Suggest to add a blank line after the (void)txn; ? > > @@ -345,10

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 11:31 AM vignesh C wrote: > > On Mon, Apr 26, 2021 at 8:42 AM Amit Kapila wrote: > > > > On Mon, Apr 26, 2021 at 8:01 AM Masahiko Sawada > > wrote: > > > > > > On Fri, Apr 23, 2021 at 6:15 PM Amit Kapila > > > wrote: > > > > > > > > On Mon, Apr 19, 2021 at 4:28 PM

Re: Parallel INSERT SELECT take 2

On Tue, Apr 27, 2021 at 8:12 AM Amit Kapila wrote: > On Tue, Apr 27, 2021 at 7:45 AM Greg Nancarrow wrote: > > > > On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy > > wrote: > > > > > > > > > I still feel that why we shouldn't limit the declarative approach to > > > only partitioned tables?

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

On Wed, Apr 21, 2021 at 12:13 PM Peter Smith wrote: > > On Tue, Apr 20, 2021 at 3:45 PM Peter Smith wrote: > > > > Please find attached the latest patch set v73`* > > > > Differences from v72* are: > > > > * Rebased to HEAD @ today (required because v72-0001 no longer applied > > cleanly) > > >

Re: Parallel INSERT SELECT take 2

On Tue, Apr 27, 2021 at 7:45 AM Greg Nancarrow wrote: > > On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy > wrote: > > > > > > I still feel that why we shouldn't limit the declarative approach to > > only partitioned tables? And for normal tables, possibly with a > > minimal cost(??), the

Re: Parallel INSERT SELECT take 2

On Tue, Apr 27, 2021 at 7:39 AM houzj.f...@fujitsu.com wrote: > > I'm thinking that when users say ALTER TABLE partioned_table SET PARALLEL > > TO 'safe';, we check all the partitions' and their associated objects' > > parallel > > safety? If all are parallel safe, then only we set

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 11:45 AM Amit Kapila wrote: > > On Tue, Apr 27, 2021 at 8:01 AM vignesh C wrote: > > > > On Mon, Apr 26, 2021 at 8:42 AM Amit Kapila wrote: > > > > > > On Mon, Apr 26, 2021 at 8:01 AM Masahiko Sawada > > > wrote: > > > > > > > > On Fri, Apr 23, 2021 at 6:15 PM Amit

Re: Replication slot stats misgivings

On Tue, Apr 27, 2021 at 8:01 AM vignesh C wrote: > > On Mon, Apr 26, 2021 at 8:42 AM Amit Kapila wrote: > > > > On Mon, Apr 26, 2021 at 8:01 AM Masahiko Sawada > > wrote: > > > > > > On Fri, Apr 23, 2021 at 6:15 PM Amit Kapila > > > wrote: > > > > > > > > On Mon, Apr 19, 2021 at 4:28 PM

Re: SQL-standard function body

On Thu, Apr 22, 2021 at 04:04:18PM -0400, Jeff Janes wrote: > This commit break line continuation prompts for unbalanced parentheses in > the psql binary. Skimming through this thread, I don't see that this is > intentional or has been noticed before. > > with psql -X > > Before: > > jjanes=#

Re: Parallel INSERT SELECT take 2

On Tue, Apr 27, 2021 at 7:45 AM Greg Nancarrow wrote: > > On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy > wrote: > > > > > > I still feel that why we shouldn't limit the declarative approach to > > only partitioned tables? And for normal tables, possibly with a > > minimal cost(??), the

Re: Replication slot stats misgivings

On Mon, Apr 26, 2021 at 8:42 AM Amit Kapila wrote: > > On Mon, Apr 26, 2021 at 8:01 AM Masahiko Sawada wrote: > > > > On Fri, Apr 23, 2021 at 6:15 PM Amit Kapila wrote: > > > > > > On Mon, Apr 19, 2021 at 4:28 PM vignesh C wrote: > > > > > > > > I have made the changes to update the

Re: Parallel INSERT SELECT take 2

On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy wrote: > > > I still feel that why we shouldn't limit the declarative approach to > only partitioned tables? And for normal tables, possibly with a > minimal cost(??), the server can do the safety checking. I know this > feels a little

RE: Parallel INSERT SELECT take 2

> > Currently, index expression and predicate are stored in text format. > > We need to use stringToNode(expression/predicate) to parse it. > > Some committers think doing this twice does not look good, unless we > > found some ways to pass parsed info to the executor to avoid the second > parse.

Re: Addition of authenticated ID to pg_stat_activity

On Tue, Apr 27, 2021 at 09:26:11AM +0800, Julien Rouhaud wrote: > -1. It's already annoying enough to have to type "WHERE pid != > pg_backend_pid()" to exclude my own backend, and I usually need it quite > often. > Unless we add some new view which integrate that, something like >

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Mon, Apr 26, 2021 at 10:31 PM Tomas Vondra wrote: > > Hi, > > I took a look at this today, as I committed 39b66a91b back in January. I > can reproduce the issue, with just 1M rows the before/after timings are > roughly 480ms and 620ms on my hardware. > > Unfortunately, the v3 patch does not

Re: Addition of authenticated ID to pg_stat_activity

On Tue, Apr 27, 2021 at 09:59:18AM +0900, Michael Paquier wrote: > > I am wondering if we should take this as an occasion to move some data > out of pg_stat_activity into a separate biew, dedicated to the data > related to the connection that remains set to the same value for the > duration of a

Re: Transactions involving multiple postgres foreign servers, take 2

On 2021/03/17 12:03, Masahiko Sawada wrote: > I've attached the updated version patch set. Thanks for updating the patches! I'm now restarting to review of 2PC because I'd like to use this feature in PG15. I think the following logic of resolving and removing the fdwxact entries by the

Re: Addition of authenticated ID to pg_stat_activity

On Mon, Apr 26, 2021 at 03:21:46PM -0400, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: >> I'm getting a bit worried about the incremental increase in >> pg_stat_activity width - it's probably by far the view that's most >> viewed interactively. I think we need to be careful

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 9:10 PM Bharath Rupireddy wrote: > > I found another problem with collationcmds.c is that it doesn't error > out if some of the options are specified more than once, something > like below. I think the option checking "for loop" in DefineCollation > needs to be reworked. >

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 9:24 PM Alvaro Herrera wrote: > > On 2021-Apr-26, Bharath Rupireddy wrote: > > > I agree that we can just be clear about the problem. Looks like the > > majority of the errors "conflicting or redundant options" are for > > redundant options. So, wherever "conflicting or

Re: Parallel INSERT SELECT take 2

On Mon, Apr 26, 2021 at 4:56 PM houzj.f...@fujitsu.com wrote: > > > The parallel attributes in table means the parallel safety when user does > > > some > > data-modification operations on it. > > > So, It only limit the use of parallel plan when using > > > INSERT/UPDATE/DELETE. > > > > In

Bug fix for tab completion of ALTER TABLE ... VALIDATE CONSTRAINT ...

Folks, I noticed that $subject completes with already valid constraints, please find attached a patch that fixes it. I noticed that there are other places constraints can be validated, but didn't check whether similar bugs exist there yet. Best, David. -- David Fetter http://fetter.org/ Phone:

Do we have a way to dynamically make a callback stub?

Hi, A lot of the APIs in PostgreSQL that accept a callback follow the familiar idiom of an extra void* argument allowing a single static callback address to be multiplexed. But not all of them do. For example, if I wanted to expose the possibility of defining GUCs from code written in my PL, I

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Sorry, I forgot to update some comments in that version. Fixed here. -- Álvaro Herrera39°49'30"S 73°17'W >From cb6d9e026624656e826ea880716ee552b15203a8 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Mon, 26 Apr 2021 14:53:04 -0400 Subject: [PATCH v2] Allow a

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Hi, On 2021-04-26 23:59:17 +0200, Tomas Vondra wrote: > On 4/26/21 9:27 PM, Andres Freund wrote: > > On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote: > > > I'm not sure what to do about this :-( I don't have any ideas about how to > > > eliminate this overhead, so the only option I see is

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On 4/26/21 9:27 PM, Andres Freund wrote: Hi, On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote: I'm not sure what to do about this :-( I don't have any ideas about how to eliminate this overhead, so the only option I see is reverting the changes in heap_insert. Unfortunately, that'd mean

Re: tab-complete for ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Apr-26, Justin Pryzby wrote: > On Thu, Apr 22, 2021 at 04:40:35PM -0400, Alvaro Herrera wrote: > > Would anyone oppose me pushing this for tab-completing the new keywords > > of ALTER TABLE .. DETACH PARTITION? > > +1 to apply tab completion for v14 Pushed. -- Álvaro Herrera

Re: Use simplehash.h instead of dynahash in SMgr

Hi, On 2021-04-26 22:44:13 +0300, Yura Sokolov wrote: > Even for Robin Hood hashing 0.9 fill factor is too high. It leads to too > much movements on insertion/deletion and longer average collision chain. That's true for modification heavy cases - but most hash tables in PG, including the smgr

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On 2021-Apr-26, Alvaro Herrera wrote: > > Please allow me to study the patch a bit more closely and get back tomorrow. > > Sure, thanks! Here's a more polished version. After trying the version with the elog(ERROR) when two detached partitions are present, I decided against it; it is unhelpful

Re: Use simplehash.h instead of dynahash in SMgr

Andres Freund писал 2021-04-26 21:46: Hi, On 2021-04-25 01:27:24 +0300, Yura Sokolov wrote: It is quite interesting result. Simplehash being open-addressing with linear probing is friendly for cpu cache. I'd recommend to define SH_FILLFACTOR with value lower than default (0.9). I believe 0.75

multi-version capable PostgresNode.pm

Just to complete the circle on this topic, which I intend to take up again during the next dev cycle, I have captured the current state of my work in a public git repo at . This can be cloned and used without having to change the core Postgres code, as

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Hi, On 2021-04-26 15:31:02 +0200, Tomas Vondra wrote: > I'm not sure what to do about this :-( I don't have any ideas about how to > eliminate this overhead, so the only option I see is reverting the changes > in heap_insert. Unfortunately, that'd mean inserts into TOAST tables won't > be frozen

Re: Addition of authenticated ID to pg_stat_activity

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2021-04-26 11:34:16 +0900, Michael Paquier wrote: > > 9afffcb has added the concept of authenticated identity to the > > information provided in log_connections for audit purposes, with this > > data stored in each backend's port. One

Re: Addition of authenticated ID to pg_stat_activity

Hi, On 2021-04-26 11:34:16 +0900, Michael Paquier wrote: > 9afffcb has added the concept of authenticated identity to the > information provided in log_connections for audit purposes, with this > data stored in each backend's port. One extra thing that can be > really useful for monitoring is

Re: Use simplehash.h instead of dynahash in SMgr

Hi, On 2021-04-25 01:27:24 +0300, Yura Sokolov wrote: > It is quite interesting result. Simplehash being open-addressing with > linear probing is friendly for cpu cache. I'd recommend to define > SH_FILLFACTOR with value lower than default (0.9). I believe 0.75 is > suitable most for such kind of

Re: compute_query_id and pg_stat_statements

On Mon, Apr 26, 2021 at 8:14 PM Andres Freund wrote: > > Hi, > > On 2021-04-26 13:43:31 -0400, Alvaro Herrera wrote: > > I think it's straightforward, if we decouple the tri-valued enum used > > for guc.c purposes from a separate boolean that actually enables the > > feature. GUC sets the

Re: compute_query_id and pg_stat_statements

Hi, On 2021-04-26 14:21:00 -0400, Tom Lane wrote: > Andres Freund writes: > That's sounding like a pretty sane design, actually. Not sure about > the shared-library-name-with-fixed-function-name detail, but certainly > it seems to be useful to separate "I need a query-id" from the details > of

Re: compute_query_id and pg_stat_statements

Andres Freund writes: > I think that's the right direction. I wonder though if we shouldn't go a > bit further. Have one guc that determines the "query id provider" (NULL > or a shared library), and one GUC that configures whether query-id is > computed (never, on-demand/auto, always). For the

Re: compute_query_id and pg_stat_statements

Hi, On 2021-04-26 13:43:31 -0400, Alvaro Herrera wrote: > I think it's straightforward, if we decouple the tri-valued enum used > for guc.c purposes from a separate boolean that actually enables the > feature. GUC sets the boolean to "off" initially when it sees the enum > as "auto", and then

Re: Issue in recent pg_stat_statements?

On 2021-04-26 12:53:30 -0500, David Christensen wrote: > On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud wrote: > > Using pg_stat_statements with a different query_id semantics without > > having to fork pg_stat_statements. > > > > I can see that argument for allowing alternatives, but the

Re: Issue in recent pg_stat_statements?

On Mon, Apr 26, 2021 at 12:18 PM Julien Rouhaud wrote: > On Mon, Apr 26, 2021 at 11:40 PM David Christensen > wrote: > >> > >> > Is this an expected change, or is this in fact broken? In previous > revisions, this was showing the INSERT and SELECT at the very least. I'm > unclear as to why

Re: pg_amcheck contrib application

> On Apr 23, 2021, at 3:01 PM, Mark Dilger wrote: > > I'll try to post something that accomplishes the changes to the reports that > you are looking for. The attached patch changes amcheck corruption reports as discussed upthread. This patch is submitted for the v14 development cycle as a

Re: compute_query_id and pg_stat_statements

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > On 2021-Apr-26, Tom Lane wrote: > > > Stephen Frost writes: > > > * Magnus Hagander (mag...@hagander.net) wrote: > > >> Thatäs why I suggested the three value one. Default to a mode where > > >> it's automatic, which is what the

Re: compute_query_id and pg_stat_statements

On 2021-Apr-26, Tom Lane wrote: > Stephen Frost writes: > > * Magnus Hagander (mag...@hagander.net) wrote: > >> Thatäs why I suggested the three value one. Default to a mode where > >> it's automatic, which is what the majority is going to want, but have > >> a way to explicitly turn it on. > >

Re: compute_query_id and pg_stat_statements

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Magnus Hagander (mag...@hagander.net) wrote: > >> Thatäs why I suggested the three value one. Default to a mode where > >> it's automatic, which is what the majority is going to want, but have > >> a way to

Re: compute_query_id and pg_stat_statements

Stephen Frost writes: > * Magnus Hagander (mag...@hagander.net) wrote: >> Thatäs why I suggested the three value one. Default to a mode where >> it's automatic, which is what the majority is going to want, but have >> a way to explicitly turn it on. > This is certainly fine with me too, though

Re: compute_query_id and pg_stat_statements

Greetings, * Magnus Hagander (mag...@hagander.net) wrote: > On Mon, Apr 26, 2021 at 6:56 PM Tom Lane wrote: > > Stephen Frost writes: > > > * Bruce Momjian (br...@momjian.us) wrote: > > >> Techically, pg_stat_statements can turn on compute_query_id when it is > > >> loaded, even if it is 'off'

Re: Issue in recent pg_stat_statements?

On Mon, Apr 26, 2021 at 11:40 PM David Christensen wrote: >> >> > Is this an expected change, or is this in fact broken? In previous >> > revisions, this was showing the INSERT and SELECT at the very least. I'm >> > unclear as to why the regression test is still passing, so want to verify >>

Re: ERROR: relation "sql_features" does not exist

po 26. 4. 2021 v 19:10 odesílatel Tom Lane napsal: > Pavel Stehule writes: > > I tried to write a query that does lateral join between > > information_schema.tables and pgstattuple function. > > > select * from information_schema.tables, lateral(select * from > > pgstattuple(table_name::name))

Re: compute_query_id and pg_stat_statements

On Tue, Apr 27, 2021 at 1:04 AM Magnus Hagander wrote: > > Thatäs why I suggested the three value one. Default to a mode where > it's automatic, which is what the majority is going to want, but have > a way to explicitly turn it on. Agreed, that also sounds like a sensible default.

Re: ERROR: relation "sql_features" does not exist

Pavel Stehule writes: > I tried to write a query that does lateral join between > information_schema.tables and pgstattuple function. > select * from information_schema.tables, lateral(select * from > pgstattuple(table_name::name)) s where table_type = 'BASE TABLE'; > The query finished by

Re: compute_query_id and pg_stat_statements

On Mon, Apr 26, 2021 at 7:00 PM Bruce Momjian wrote: > > On Mon, Apr 26, 2021 at 12:56:13PM -0400, Tom Lane wrote: > > Stephen Frost writes: > > > * Bruce Momjian (br...@momjian.us) wrote: > > >> Techically, pg_stat_statements can turn on compute_query_id when it is > > >> loaded, even if it is

Re: compute_query_id and pg_stat_statements

On Mon, Apr 26, 2021 at 6:56 PM Tom Lane wrote: > > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> Techically, pg_stat_statements can turn on compute_query_id when it is > >> loaded, even if it is 'off' in postgresql.conf, right? And > >> pg_stat_statements would know

Re: compute_query_id and pg_stat_statements

On Tue, Apr 27, 2021 at 12:56 AM Tom Lane wrote: > > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> Techically, pg_stat_statements can turn on compute_query_id when it is > >> loaded, even if it is 'off' in postgresql.conf, right? And > >> pg_stat_statements would know

Re: Synchronous commit behavior during network outage

Hello Andrey, I went through the thread for your patch and seems to me as an acceptable solution... > The only case patch does not handle is sudden backend crash - Postgres will recover without a restart. We also use a HA tool (Patroni). If the whole machine fails, it will find a new

Re: compute_query_id and pg_stat_statements

On Mon, Apr 26, 2021 at 12:56:13PM -0400, Tom Lane wrote: > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> Techically, pg_stat_statements can turn on compute_query_id when it is > >> loaded, even if it is 'off' in postgresql.conf, right? And > >> pg_stat_statements

ERROR: relation "sql_features" does not exist

Hi I tried to write a query that does lateral join between information_schema.tables and pgstattuple function. select * from information_schema.tables, lateral(select * from pgstattuple(table_name::name)) s where table_type = 'BASE TABLE'; The query finished by strange error postgres=# select

Re: compute_query_id and pg_stat_statements

Stephen Frost writes: > * Bruce Momjian (br...@momjian.us) wrote: >> Techically, pg_stat_statements can turn on compute_query_id when it is >> loaded, even if it is 'off' in postgresql.conf, right? And >> pg_stat_statements would know if an alternate hash method is being used, >> right? > +1 on

Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?

On Mon, 26 Apr 2021 at 15:55, Tom Lane wrote: > > I checked into the commit history (how'd we ever survive without "git > blame"?) and found that my argument above is actually wrong in detail. > Before cab5dc5da of 2013-10-18, rewriteTargetListIU expanded non-updated > columns for all views not

Re: compute_query_id and pg_stat_statements

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Mon, Apr 26, 2021 at 05:34:30PM +0200, Christoph Berg wrote: > > Re: Peter Eisentraut > > > > Agreed. If pg_stat_statements were zero-configuration today then > > > > this would be an annoying new burden, but it isn't. > > > > > > I

Re: compute_query_id and pg_stat_statements

On Mon, Apr 26, 2021 at 05:34:30PM +0200, Christoph Berg wrote: > Re: Peter Eisentraut > > > Agreed. If pg_stat_statements were zero-configuration today then > > > this would be an annoying new burden, but it isn't. > > > > I think people can understand "add pg_stat_statements to > >

Re: Enhanced error message to include hint messages for redundant options error

On 2021-Apr-26, Bharath Rupireddy wrote: > I agree that we can just be clear about the problem. Looks like the > majority of the errors "conflicting or redundant options" are for > redundant options. So, wherever "conflicting or redundant options" > exists: 1) change the message to "option \"%s\"

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 8:06 PM Alvaro Herrera wrote: > > On 2021-Apr-26, Bharath Rupireddy wrote: > > > Thanks! IMO, it is better to change the error message to "option > > \"%s\" specified more than once" instead of adding an error detail. > > Let's hear other hackers' opinions. > > Many other

Re: Issue in recent pg_stat_statements?

> > > Is this an expected change, or is this in fact broken? In previous > revisions, this was showing the INSERT and SELECT at the very least. I'm > unclear as to why the regression test is still passing, so want to verify > that I'm not doing something wrong in the testing. > > Yes, you want

Re: compute_query_id and pg_stat_statements

Re: Peter Eisentraut > > Agreed. If pg_stat_statements were zero-configuration today then > > this would be an annoying new burden, but it isn't. > > I think people can understand "add pg_stat_statements to > shared_preload_libraries" and "install the extension". You have to turn it > on

Re: Issue in recent pg_stat_statements?

On Mon, Apr 26, 2021 at 5:15 PM David Christensen wrote: > > -hackers, > > So in doing some recent work on pg_stat_statements, I notice that while the > regression test still passes on HEAD, it appears that 4f0b096 (per git > bisect) changed/broke how this works compared to historical versions.

Issue in recent pg_stat_statements?

-hackers, So in doing some recent work on pg_stat_statements, I notice that while the regression test still passes on HEAD, it appears that 4f0b096 (per git bisect) changed/broke how this works compared to historical versions. Essentially, when doing a fresh install of pg_stat_statements on a

Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?

Dean Rasheed writes: > On Mon, 26 Apr 2021 at 15:09, Tom Lane wrote: >> Thanks for looking at that. On reflection I think this must be so, >> because those rewriter mechanisms were designed long before we had >> trigger-updatable views, and rewriteTargetListIU has never added >> tlist items

Re: compute_query_id and pg_stat_statements

On 24.04.21 19:43, Tom Lane wrote: Bruce Momjian writes: That's a pretty weird API. I think we just need people to turn it on like they are doing when the configure pg_stat_statements anyway. pg_stat_statements already requires configuration anyway. Agreed. If pg_stat_statements were

Re: Enhanced error message to include hint messages for redundant options error

On 2021-Apr-26, Bharath Rupireddy wrote: > Thanks! IMO, it is better to change the error message to "option > \"%s\" specified more than once" instead of adding an error detail. > Let's hear other hackers' opinions. Many other places have the message "conflicting or redundant options", and then

Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?

On Mon, 26 Apr 2021 at 15:09, Tom Lane wrote: > > Thanks for looking at that. On reflection I think this must be so, > because those rewriter mechanisms were designed long before we had > trigger-updatable views, and rewriteTargetListIU has never added > tlist items like this for any other sort

Re: tab-complete for ALTER TABLE .. DETACH PARTITION CONCURRENTLY

On Thu, Apr 22, 2021 at 04:40:35PM -0400, Alvaro Herrera wrote: > Would anyone oppose me pushing this for tab-completing the new keywords > of ALTER TABLE .. DETACH PARTITION? +1 to apply tab completion for v14 -- Justin

Re: [BUG] "FailedAssertion" reported when streaming in logical replication

On Mon, Apr 26, 2021 at 6:59 PM Amit Kapila wrote: > > On Mon, Apr 26, 2021 at 5:55 PM Dilip Kumar wrote: > > > > I am able to reproduce this and I think I have done the initial > > investigation. > > > > The cause of the issue is that, this transaction has only one change > > and that change

Re: Does rewriteTargetListIU still need to add UPDATE tlist entries?

Amit Langote writes: > On Mon, Apr 26, 2021 at 9:40 AM Tom Lane wrote: >> I would think that this is a totally straightforward improvement, >> but there's one thing in the comments for rewriteTargetListIU that >> gives me a little pause: it says >> >> * We must do items 1,2,3 before firing

Re: How to test Postgres for any unaligned memory accesses?

On Fri, Apr 23, 2021 at 7:25 PM Tom Lane wrote: > > I'm not sure this is the right way. I would like to know whether there > > is a standard way of testing Postgres code for any unaligned memory > > accesses. Thanks. Any help would be appreciated. > > Per c.h, late-model compilers have options

RE: use pg_strncasecmp to replace strncmp when compare "pg_"

On Friday, April 23, 2021 2:06 PM, Tom Lane wrote >>Kyotaro Horiguchi writes: >> That doesn't matter at all for now since we match schema identifiers >> case-sensitively. Maybe it should be a part of the patch in [1]. > >Yeah --- maybe this'd make sense as part of a full patch to improve

RE: Support tab completion for upper character inputs in psql

Hi I've updated the patch to V7 based on the following comments. On Friday, April 23, 2021 11:58 AM, Kyotaro Horiguchi wrote >All usages of pg_string_tolower don't need a copy. >So don't we change the function to in-place converter? Refer to your later discussion with Tom. Keep the code as

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 7:02 PM vignesh C wrote: > > On Mon, Apr 26, 2021 at 5:49 PM Bharath Rupireddy > wrote: > > > > On Mon, Apr 26, 2021 at 5:29 PM vignesh C wrote: > > > > > > Hi, > > > > > > While reviewing one of the logical replication patches, I found that > > > we do not include hint

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 6:18 PM Dilip Kumar wrote: > > On Mon, Apr 26, 2021 at 5:49 PM Bharath Rupireddy > wrote: > > > > On Mon, Apr 26, 2021 at 5:29 PM vignesh C wrote: > > > > > > Hi, > > > > > > While reviewing one of the logical replication patches, I found that > > > we do not include

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 5:49 PM Bharath Rupireddy wrote: > > On Mon, Apr 26, 2021 at 5:29 PM vignesh C wrote: > > > > Hi, > > > > While reviewing one of the logical replication patches, I found that > > we do not include hint messages to display the actual option which has > > been specified

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Hi, I took a look at this today, as I committed 39b66a91b back in January. I can reproduce the issue, with just 1M rows the before/after timings are roughly 480ms and 620ms on my hardware. Unfortunately, the v3 patch does not really fix the issue for me. The timing with it applied is ~610ms

Re: [BUG] "FailedAssertion" reported when streaming in logical replication

On Mon, Apr 26, 2021 at 5:55 PM Dilip Kumar wrote: > > On Mon, Apr 26, 2021 at 1:26 PM Dilip Kumar wrote: > > > > On Mon, 26 Apr 2021 at 12:45 PM, tanghy.f...@fujitsu.com > > wrote: > >> > >> Hi > >> > >> I think I may found a bug when using streaming in logical replication. > >> Could anyone

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 5:49 PM Bharath Rupireddy wrote: > > On Mon, Apr 26, 2021 at 5:29 PM vignesh C wrote: > > > > Hi, > > > > While reviewing one of the logical replication patches, I found that > > we do not include hint messages to display the actual option which has > > been specified

Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Hello Amit, On 2021-Apr-26, Amit Langote wrote: > On Sat, Apr 24, 2021 at 8:31 AM Alvaro Herrera > wrote: > > I haven't added a mechanism to verify this; but with asserts on, this > > patch will crash if you have more than one. I think the behavior is not > > necessarily sane with asserts

Re: [BUG] "FailedAssertion" reported when streaming in logical replication

On Mon, Apr 26, 2021 at 1:26 PM Dilip Kumar wrote: > > On Mon, 26 Apr 2021 at 12:45 PM, tanghy.f...@fujitsu.com > wrote: >> >> Hi >> >> I think I may found a bug when using streaming in logical replication. Could >> anyone please take a look at this? >> >> Here's what I did to produce the

Re: Enhanced error message to include hint messages for redundant options error

On Mon, Apr 26, 2021 at 5:29 PM vignesh C wrote: > > Hi, > > While reviewing one of the logical replication patches, I found that > we do not include hint messages to display the actual option which has > been specified more than once in case of redundant option error. I > felt including this

Re: Dumping/restoring fails on inherited generated column

On 05.02.21 15:18, Peter Eisentraut wrote: Anyway, I figured out how to take account of generation expressions with different column orders.  I used the same approach that we use for check constraints.  The attached patch is good to go from my perspective. Dusting this off ... this patch

  1   2   >