Re: Parallel INSERT SELECT take 2

On Tue, May 11, 2021 at 10:41 PM houzj.f...@fujitsu.com wrote: > > Attaching new version patches with the following changes: > > 0001 > Add a new function pg_get_max_parallel_hazard('table_name') returns char('s', > 'u', 'r') > which indicate whether it is safe, unsafe, or restricted to perform a

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 08:58:45AM +0200, Pavel Stehule wrote: > > I don't like the idea of implicit force enabling any feature flag, but it > is better than current design. But it doesn't look like a robust solution. > > Does it mean that if somebody disables computed_query_id, then > pg_stat_st

Re: Feedback on table expansion hook (including patch)

Hello, > Thank you all for the feedback and insights. > > Yes, the intention is to *replace* expand_inherited_rtentry() in the same way > planner_hook replaces standard_planner(). > This patch is really useful. We are working on developing hypothetical partitioning as a feature of HypoPG[1][2],

Re: compute_query_id and pg_stat_statements

st 12. 5. 2021 v 9:13 odesílatel Julien Rouhaud napsal: > On Wed, May 12, 2021 at 08:58:45AM +0200, Pavel Stehule wrote: > > > > I don't like the idea of implicit force enabling any feature flag, but it > > is better than current design. But it doesn't look like a robust > solution. > > > > Does

Re: GetSubscriptionRelations declares too many scan keys

On Tue, May 11, 2021 at 04:50:46PM +0900, Michael Paquier wrote: > And that makes the code slightly easier to follow. Yeah, that's better this way, so applied. -- Michael signature.asc Description: PGP signature

Re: Feedback on table expansion hook (including patch)

On Wed, May 12, 2021 at 04:48:29PM +0900, yuzuko wrote: > Hello, > > > Thank you all for the feedback and insights. > > > > Yes, the intention is to *replace* expand_inherited_rtentry() in the same > > way planner_hook replaces standard_planner(). > > > > This patch is really useful. We are wor

Re: OOM in spgist insert

ср, 12 мая 2021 г. в 11:09, Dilip Kumar : > While testing something on spgist I found that at certain point while > inserting in spgist it is going for doPickSplit, but even after split > is is not able to find a place to insert a tuple and it keeping going > in that loop infinitely it seems and f

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 09:51:26AM +0200, Pavel Stehule wrote: > > If I understand well, then computed_query_id does not make sense for > pg_stat_statemenst, because this extension always requires it. No, pg_stat_statements requires *a* queryid, not specifially *our* queryid. > Cannot be better

Re: OOM in spgist insert

On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov wrote: > ср, 12 мая 2021 г. в 11:09, Dilip Kumar : > >> While testing something on spgist I found that at certain point while >> inserting in spgist it is going for doPickSplit, but even after split >> is is not able to find a place to insert a tuple

Re: OOM in spgist insert

ср, 12 мая 2021 г. в 12:36, Dilip Kumar : > On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov > wrote: > >> ср, 12 мая 2021 г. в 11:09, Dilip Kumar : >> >>> While testing something on spgist I found that at certain point while >>> inserting in spgist it is going for doPickSplit, but even after split

Re: OOM in spgist insert

ср, 12 мая 2021 г. в 12:39, Pavel Borisov : > ср, 12 мая 2021 г. в 12:36, Dilip Kumar : > >> On Wed, 12 May 2021 at 1:43 PM, Pavel Borisov >> wrote: >> >>> ср, 12 мая 2021 г. в 11:09, Dilip Kumar : >>> While testing something on spgist I found that at certain point while inserting in sp

Re: compute_query_id and pg_stat_statements

st 12. 5. 2021 v 10:14 odesílatel Julien Rouhaud napsal: > On Wed, May 12, 2021 at 09:51:26AM +0200, Pavel Stehule wrote: > > > > If I understand well, then computed_query_id does not make sense for > > pg_stat_statemenst, because this extension always requires it. > > No, pg_stat_statements requ

Re: OOM in spgist insert

On Wed, May 12, 2021 at 2:21 PM Pavel Borisov wrote: >> >> PFA v1 patch. Does this help? > > I've made a mistake in attributes count in v1. PFA v2 V2 works. Thanks for fixing this quickly, I think you can add a comment for the new error condition you added. -- Regards, Dilip Kumar Enterprise

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote: > > My second proposal can work for your example too. pg_stat_statements have > to require any active queryid computing. And when it is not available, then > the exception should be raised. > > The custom queryid can return null, and

Re: GetSubscriptionRelations declares too many scan keys

On Wed, May 12, 2021 at 5:52 PM Michael Paquier wrote: > > On Tue, May 11, 2021 at 04:50:46PM +0900, Michael Paquier wrote: > > And that makes the code slightly easier to follow. > > Yeah, that's better this way, so applied. Thanks! -- Kind Regards, Peter Smith. Fujitsu Australia

Re: compute_query_id and pg_stat_statements

At Wed, 12 May 2021 14:05:16 +0800, Julien Rouhaud wrote in > On Wed, May 12, 2021 at 02:33:35PM +0900, Kyotaro Horiguchi wrote: > > At Wed, 12 May 2021 10:42:01 +0800, Julien Rouhaud > > wrote in > > > > > > I don't think that this approach would cope well for people who want a > > > query

Re: compute_query_id and pg_stat_statements

At Wed, 12 May 2021 17:30:26 +0800, Julien Rouhaud wrote in > On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote: > > > > My second proposal can work for your example too. pg_stat_statements have > > to require any active queryid computing. And when it is not available, then > > the

Re: compute_query_id and pg_stat_statements

At Wed, 12 May 2021 18:39:27 +0900 (JST), Kyotaro Horiguchi wrote in > At Wed, 12 May 2021 17:30:26 +0800, Julien Rouhaud wrote > in > > On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote: > > > > > > My second proposal can work for your example too. pg_stat_statements have > > >

Re: compute_query_id and pg_stat_statements

st 12. 5. 2021 v 11:39 odesílatel Kyotaro Horiguchi napsal: > At Wed, 12 May 2021 17:30:26 +0800, Julien Rouhaud > wrote in > > On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote: > > > > > > My second proposal can work for your example too. pg_stat_statements > have > > > to require

Re: Inherited UPDATE/DELETE vs async execution

Amit-san, On Tue, May 11, 2021 at 9:53 PM Amit Langote wrote: > On Tue, May 11, 2021 at 5:56 PM Etsuro Fujita wrote: > > On Mon, May 10, 2021 at 9:21 PM Amit Langote > > wrote: > > > On Sat, May 8, 2021 at 1:21 AM Etsuro Fujita > > > wrote: > > > > To > > > > fix, I think we should modify

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 11:42:12AM +0200, Pavel Stehule wrote: > st 12. 5. 2021 v 11:39 odesílatel Kyotaro Horiguchi > napsal: > > > At Wed, 12 May 2021 17:30:26 +0800, Julien Rouhaud > > wrote in > > > On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote: > > > > > > > > My second prop

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 06:37:24PM +0900, Kyotaro Horiguchi wrote: > At Wed, 12 May 2021 14:05:16 +0800, Julien Rouhaud wrote > in > > > > And if I'm not mistaken, pg_store_plans also wants a different queryid > > implementation, but has to handle a secondary queryid on top of it > > (https://g

Re: wal stats questions

On 2021/05/11 18:46, Masahiro Ikeda wrote: On 2021/05/11 16:44, Fujii Masao wrote: On 2021/04/28 9:10, Masahiro Ikeda wrote: On 2021/04/27 21:56, Fujii Masao wrote: On 2021/04/26 10:11, Masahiro Ikeda wrote: First patch has only the changes for pg_stat_wal view. ("v6-0001-performa

Re: proposal - psql - use pager for \watch command

Hi st 21. 4. 2021 v 8:52 odesílatel Pavel Stehule napsal: > > > st 21. 4. 2021 v 8:49 odesílatel Thomas Munro > napsal: > >> On Wed, Apr 21, 2021 at 6:33 PM Pavel Stehule >> wrote: >> > here is an rebase of Thomas's implementation >> >> Thanks. I finished up not committing that one for 14 bec

Re: Replication slot stats misgivings

On Wed, May 12, 2021 at 1:19 PM vignesh C wrote: > > On Wed, May 12, 2021 at 9:08 AM Amit Kapila wrote: > > > > On Wed, May 12, 2021 at 7:53 AM Amit Kapila wrote: > > > > > > On Wed, May 12, 2021 at 4:00 AM Masahiko Sawada > > > wrote: > > > > > > > > Ugh, since by commit 592f00f8de we send sl

RFC: Logging plan of the running query

Hi, During the discussion about memory contexts dumping[1], there was a comment that exposing not only memory contexts but also query plans and untruncated query string would be useful. I also feel that it would be nice when thinking about situations such as troubleshooting a long-running query

Re: OOM in spgist insert

> > V2 works. Thanks for fixing this quickly, I think you can add a > comment for the new error condition you added. > Added comments. PFA v3 -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com v3-0001-When-there-are-INCLUDEd-columns-in-

Re: OOM in spgist insert

On Wed, May 12, 2021 at 5:11 PM Pavel Borisov wrote: >> >> V2 works. Thanks for fixing this quickly, I think you can add a >> comment for the new error condition you added. > > Added comments. PFA v3 Thanks. + * + * For indexes with INCLUDEd columns we do not know whether we can reduce + * ind

Re: OOM in spgist insert

> > INCLUDEd -> why you have used a mixed case here? > It is current practice to call INCLUDE columns in capital, you can find many places in the current code. But case mixture can be avoided indeed )) PFA v4 v4-0001-When-there-are-INCLUDEd-columns-in-SpGist-check-t.patch Description: Binary dat

Re: RFC: Logging plan of the running query

st 12. 5. 2021 v 13:24 odesílatel torikoshia napsal: > Hi, > > During the discussion about memory contexts dumping[1], there > was a comment that exposing not only memory contexts but also > query plans and untruncated query string would be useful. > > I also feel that it would be nice when think

Re: Query regarding RANGE Partitioning

Hi Nitin, On Sat, May 8, 2021 at 5:20 PM Nitin Jadhav wrote: > Thanks Ashutosh and Jeevan for replying. > > > "When creating a range partition, the lower bound specified with > > FROM is an inclusive bound, whereas the upper bound specified with > > TO is an exclusive bound. That is, the values

Re: proposal - psql - use pager for \watch command

st 12. 5. 2021 v 12:25 odesílatel Pavel Stehule napsal: > Hi > > st 21. 4. 2021 v 8:52 odesílatel Pavel Stehule > napsal: > >> >> >> st 21. 4. 2021 v 8:49 odesílatel Thomas Munro >> napsal: >> >>> On Wed, Apr 21, 2021 at 6:33 PM Pavel Stehule >>> wrote: >>> > here is an rebase of Thomas's impl

Re: RFC: Logging plan of the running query

On Wed, May 12, 2021 at 4:54 PM torikoshia wrote: > > Hi, > > During the discussion about memory contexts dumping[1], there > was a comment that exposing not only memory contexts but also > query plans and untruncated query string would be useful. > > I also feel that it would be nice when thinkin

Re: RFC: Logging plan of the running query

On Wed, 12 May 2021 at 13:24, torikoshia wrote: > > Hi, > > During the discussion about memory contexts dumping[1], there > was a comment that exposing not only memory contexts but also > query plans and untruncated query string would be useful. > > I also feel that it would be nice when thinking

Do we need to rethink how to parallelize regression tests to speedup CLOBBER_CACHE_ALWAYS?

Right now Tom is doing a bit of work to try and improve the performance of regression test runs with CLOBBER _CACHE_ALWAYS. I'm on board with making this go faster too. I did a CLOBBER_CACHE_ALWAYS_RUN today and it took my machine almost 7 hours to complete. I occasionally checked top -c and was

Re: parallel vacuum - few questions on docs, comments and code

On Tue, May 11, 2021 at 6:31 PM Justin Pryzby wrote: > > 4) IIUC, below comment says that even if PARALLEL 0 is specified with > > VACUUM command, there are chances that the indexes are vacuumed in > > parallel. Isn't it a bit unusual that a user specified 0 workers but > > still the system is pic

Re: parallel vacuum - few questions on docs, comments and code

On Wed, May 12, 2021 at 9:48 AM Amit Kapila wrote: > > On Tue, May 11, 2021 at 6:31 PM Justin Pryzby wrote: > > > > On Tue, May 11, 2021 at 05:37:50PM +0530, Bharath Rupireddy wrote: > > > 3) Should the Assert(nindexes > 0); in begin_parallel_vacuum just be > > > Assert(nindexes > 1); as this fun

Re: parallel vacuum - few questions on docs, comments and code

On Wed, May 12, 2021 at 11:10 AM Amit Kapila wrote: > > On Tue, May 11, 2021 at 5:38 PM Bharath Rupireddy > wrote: > > > > I was going through the parallel vacuum docs and code. I found below > > things, please someone clarify: > > > > 1) I see that a term "parallel degree" is used in the docs,

Re: Corrected documentation of data type for the logical replication message formats.

On Wed, May 12, 2021 at 3:36 AM Peter Smith wrote: > > On Wed, May 12, 2021 at 1:02 AM vignesh C wrote: > > > > Thanks for the comments, Attached v3 patch has the changes as suggested. > > This v3 mostly looks good to me now except for some minor comments > about the flags. > > ~~~ > > 1. Commit

Re: Feedback on table expansion hook (including patch)

(Sorry about being very late to this thread.) On Sun, Mar 7, 2021 at 3:09 AM Tom Lane wrote: > Peter Eisentraut writes: > > On 07.05.20 10:11, Erik Nordström wrote: > >> I am looking for feedback on the possibility of adding a table expansion > >> hook to PostgreSQL (see attached patch). > > > U

Re: Do we need to rethink how to parallelize regression tests to speedup CLOBBER_CACHE_ALWAYS?

David Rowley writes: > Right now we start 1 backend for each test in a parallel group then > wait for the final backend to complete before running the next group. > Is a particular reason for it to work that way? There are a whole lot of cases where test Y depends on an earlier test X. Some of t

Re: RFC: Logging plan of the running query

On Wed, May 12, 2021 at 08:24:04PM +0900, torikoshia wrote: > Hi, > > During the discussion about memory contexts dumping[1], there > was a comment that exposing not only memory contexts but also > query plans and untruncated query string would be useful. > > I also feel that it would be nice whe

Re: OOM in spgist insert

On Wed, May 12, 2021 at 5:35 PM Pavel Borisov wrote: >> >> INCLUDEd -> why you have used a mixed case here? > > It is current practice to call INCLUDE columns in capital, you can find many > places in the current code. But case mixture can be avoided indeed )) > PFA v4 Okay, that makes sense.

Re: PG 14 release notes, first draft

On Tue, May 11, 2021 at 10:45:04PM -0400, Bruce Momjian wrote: > On Tue, May 11, 2021 at 05:13:21PM -0500, Justin Pryzby wrote: > > On Tue, May 11, 2021 at 10:35:23AM -0400, Bruce Momjian wrote: > > > > | Allow more than the common name (CN) to be matched for client > > > > certificate authenticat

Re: Query regarding RANGE Partitioning

Hi Amit, > Thanks Jeevan, that's right. > Another way to look at this: the partition key (100, 0) would be > insertable into r3, because the key satisfies its proposed exclusive > upper bound (< (100, 200)). The same key is also insertable into r1, > because it satisfies the latter's inclusive u

Re: Extending amcheck to check toast size and compression

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed This patch looks good to me. Considering a positive response

Re: Extending amcheck to check toast size and compression

Hi hackers, > make installcheck-world: tested, failed > Implements feature: tested, failed > Spec compliant: tested, failed > Documentation:tested, failed Very sorry about these "failed" checkboxes. Didn't use the commitfest webapp for a while. The patch is fine. > T

Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

Hi! I am trying to understand the behaviour of the query planner regarding the push-down of the conditions "through" the join. Lets say that I have tables a(adate date, aval text) and b(bdate date, bval text), and I create a view: create view v as select a.adate, a.aval, b.bval from a join b o

Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?

Dmitry Astapov writes: > I am trying to understand the behaviour of the query planner regarding the > push-down of the conditions "through" the join. I think your mental model is wrong. What's actually happening here is that the planner uses equivalence classes to deduce implied conditions. That

Re: RFC: Logging plan of the running query

On Wed, 2021-05-12 at 18:03 +0530, Bharath Rupireddy wrote: > On Wed, May 12, 2021 at 4:54 PM torikoshia wrote: > > During the discussion about memory contexts dumping[1], there > > was a comment that exposing not only memory contexts but also > > query plans and untruncated query string would be

alter subscription drop publication fixes

Hi, While I was reviewing one of the logical decoding features, I found a few issues in alter subscription drop publication. Alter subscription drop publication does not support copy_data option, that needs to be removed from tab completion. Dropping all the publications present in the subscript

Re: Transactions involving multiple postgres foreign servers, take 2

On Mon, May 10, 2021 at 9:38 PM Masahiko Sawada wrote: > On Mon, May 3, 2021 at 11:11 PM Zhihong Yu wrote: > > > > > > > > On Mon, May 3, 2021 at 5:25 AM Masahiko Sawada > wrote: > >> > >> On Sun, May 2, 2021 at 1:23 AM Zhihong Yu wrote: > >> > > >> > > >> > > >> > On Fri, Apr 30, 2021 at 9:09

Re: alter subscription drop publication fixes

On Wed, May 12, 2021 at 9:55 PM vignesh C wrote: > While I was reviewing one of the logical decoding features, I found a > few issues in alter subscription drop publication. Thanks! > Alter subscription drop publication does not support copy_data option, > that needs to be removed from tab compl

Re: PG 14 release notes, first draft

On Wed, May 12, 2021 at 09:15:55AM +0530, Amit Kapila wrote: > On Tue, May 11, 2021 at 6:43 PM Jonathan S. Katz wrote: > > I was going to post a question about the above bullet point(s), so this > > clarification helps -- thanks! > > > > Two comments on the above: > > > > 1. I do believe ther eis

Re: PG 14 release notes, first draft

On Wed, May 12, 2021 at 09:18:27AM +0530, Amit Kapila wrote: > On Wed, May 12, 2021 at 2:36 AM Bruce Momjian wrote: > > > > > > OK, I added this: > > > > > > > > > > > > Allow logical decoding to more efficently process cache > > invalidation messages > >

naming of async_mode parameter

Hi, Etsuro-san: I was looking at Fix EXPLAIN ANALYZE for async-capable nodes. which adds the following parameter / field: + boolasync_mode; /* true if node is in async mode */ async_mode implies an enum: {sync, async} Since there are only two values, the data type is bool. I thin

Re: PG 14 release notes, first draft

On Wed, May 12, 2021 at 10:06:05AM -0500, Justin Pryzby wrote: > On Tue, May 11, 2021 at 10:45:04PM -0400, Bruce Momjian wrote: > > OK, so this is where I am confused. I searched for distinguished name > > (DN) and came up with DN being a concatentation of all the fields > > provided to the certif

Re: PG 14 release notes, first draft

On Tue, May 11, 2021 at 11:57:10AM +0900, Amit Langote wrote: > On Mon, May 10, 2021 at 11:40 PM Justin Pryzby wrote: > > 86dc90056d Rework planning and execution of UPDATE and DELETE. > > a1115fa078 Postpone some more stuff out of ExecInitModifyTable. > > c5b7ba4e67 Postpone some stuff out of Exe

Re: Some other CLOBBER_CACHE_ALWAYS culprits

Hi, On 2021-05-11 19:02:00 -0700, Andres Freund wrote: > I don't think we'd loose a lot of practical coverage if we avoided > rebuilding non-accessed relcache entries eagerly during cache > lookups. What coverage do we e.g. gain by having a single > SearchCatCacheMiss() triggering rebuilding the r

Re: seawasp failing, maybe in glibc allocator

Possibly I have just added "ulimit -c unlimited" in the script, we should see the effect on next round. for def5b065 it ended on on the contrib ltree test: 2021-05-12 20:12:52.528 CEST [3042602:410] pg_regress/ltree LOG: disconnection: session time: 0:00:13.426 user=buildfarm database=co

Always bump PG_CONTROL_VERSION?

Hackers, I would like to propose bumping PG_CONTROL_VERSION with each release even if there are no changes to the ControlFileData struct. Historically PG_CONTROL_VERSION has only been bumped when there were changes to ControlFileData. pgBackRest uses PG_CONTROL_VERSION to identify the versio

Re: Always bump PG_CONTROL_VERSION?

On 2021-May-12, David Steele wrote: > pgBackRest uses PG_CONTROL_VERSION to identify the version of PostgreSQL > when it is not running. If PG_CONTROL_VERSION does not change from a prior > version then we also use CATALOG_VERSION_NO to uniquely identify the > version. Why don't you use the PG_VE

Re: Always bump PG_CONTROL_VERSION?

Hi, On 2021-05-12 14:58:11 -0400, David Steele wrote: > pgBackRest uses PG_CONTROL_VERSION to identify the version of PostgreSQL > when it is not running. If PG_CONTROL_VERSION does not change from a prior > version then we also use CATALOG_VERSION_NO to uniquely identify the > version. Why aren'

Re: PG 14 release notes, first draft

On Tue, May 11, 2021 at 05:47:27PM -0400, Álvaro Herrera wrote: > On 2021-May-11, Bruce Momjian wrote: > > > > 86dc90056d Rework planning and execution of UPDATE and DELETE. > > > a1115fa078 Postpone some more stuff out of ExecInitModifyTable. > > > c5b7ba4e67 Postpone some stuff out of ExecInitMo

Re: Granting control of SUSET gucs to non-superusers

On Wed, May 12, 2021 at 11:59 AM Mark Dilger wrote: > I didn't bother updating the docs yet, as I doubt the set of privileges/roles > in this patch will survive contact with this list. They are: > > [ various things ] Interesting classification. I think the trick here is going to be to figure o

Re: Always bump PG_CONTROL_VERSION?

On 5/12/21 3:21 PM, Alvaro Herrera wrote: On 2021-May-12, David Steele wrote: pgBackRest uses PG_CONTROL_VERSION to identify the version of PostgreSQL when it is not running. If PG_CONTROL_VERSION does not change from a prior version then we also use CATALOG_VERSION_NO to uniquely identify the

Re: [PATCH] Full support for index LP_DEAD hint bits on standby

Hello, Antonin. > My review that started in [1] continues here. Thanks a lot for the review. > (Please note that code.patch does not apply to the current master branch.) Rebased. > Especially for the problem discussed in [1] it should be > explained what would happen if kill_prior_tuple_min_lsn

Re: Always bump PG_CONTROL_VERSION?

David Steele writes: > On 5/12/21 3:21 PM, Alvaro Herrera wrote: >> Why don't you use the PG_VERSION file in the datadir? > Mostly because there is other data we need in pg_control and it is > simpler to read one file than two. I'm disinclined to change the longstanding rule in this area for a

Re: Always bump PG_CONTROL_VERSION?

Hi, On 2021-05-12 16:18:16 -0400, Tom Lane wrote: > Even if we did change the rule going forward, you'd still need to > do it properly for existing releases, so I don't see that you're > going to save anything. It turns out that the last time a major version didn't have a unique control file vers

Re: Always bump PG_CONTROL_VERSION?

On 5/12/21 4:18 PM, Tom Lane wrote: David Steele writes: On 5/12/21 3:21 PM, Alvaro Herrera wrote: Why don't you use the PG_VERSION file in the datadir? Mostly because there is other data we need in pg_control and it is simpler to read one file than two. I'm disinclined to change the long

Re: [Patch] ALTER SYSTEM READ ONLY

On Wed, May 12, 2021 at 1:39 AM Dilip Kumar wrote: > Your idea makes sense, but IMHO, if we are first writing > XLogAcceptWrites() and then pushing out the barrier, then I don't > understand the meaning of having state #4. I mean whenever any > backend receives the barrier the system will always

SearchCatCacheList()/SearchSysCacheList() is O(n)

Hi, When working on the shared memory stats patch I needed to manufacture having a lot of stats entries. It seemed cheaper to create functions than relations, for fairly obvious reasons. That required calling the functions too get those entries. My first attempt ran into the following issue: --

Re: SearchCatCacheList()/SearchSysCacheList() is O(n)

Andres Freund writes: > The problem is that SearchCatCacheList() is not actually a hash table - > there are no buckets, in contrast to SearchCatCacheList(). Uh, what did you mean to compare to there? > Tom, any chance you remember if this was an oversight, or whether you > just considered this t

Re: SearchCatCacheList()/SearchSysCacheList() is O(n)

Hi, On 2021-05-12 17:26:28 -0400, Tom Lane wrote: > Andres Freund writes: > > The problem is that SearchCatCacheList() is not actually a hash table - > > there are no buckets, in contrast to SearchCatCacheList(). > > Uh, what did you mean to compare to there? Oops, copy-and-paste failure. I was

Re: SearchCatCacheList()/SearchSysCacheList() is O(n)

Andres Freund writes: > It's not an individual "result" list that's the issue. In my example > they're all exactly one element long. The problem is that CatCache->list > has one element for each cached SearchCatCacheList() result, and that > for every SearchCatCacheList() we linearly search throug

Re: Do we need to rethink how to parallelize regression tests to speedup CLOBBER_CACHE_ALWAYS?

On Thu, 13 May 2021 at 01:50, Tom Lane wrote: > There are a whole lot of cases where test Y depends on an earlier test X. > Some of those dependencies are annotated in parallel_schedule, but I fear > most are not. > > If we had a full list of such dependencies then we could imagine building > a jo

Re: PG 14 release notes, first draft

On 2021-May-12, Bruce Momjian wrote: > OK, I added it into the existing entry: > > > > > > Allow subscripting of jsonb (Dmitry Dolgov) > > > > Subscripting can be used to extract from and assign to jsonb documents. > Subscripting

Re: PG 14 release notes, first draft

On 2021-May-10, Bruce Momjian wrote: > I reworeded it to: > > > > > > Limit the ways password_encryption can enable md5 hashing (Peter > Eisentraut) > > > > Previously on/true/yes/1 values enabled md5. Now, only the string md5 > does

Re: Replacing pg_depend PIN entries with a fixed range check

I wrote: > In view of the discussion at [1], there's more pressure on the OID supply > above 10K than I'd realized. While I don't have any good ideas about > eliminating the problem altogether, I did have a thought that would remove > the extra buffer zone created by my first-draft patch in this t

Re: AlterSubscription_refresh "wrconn" wrong variable?

On 2021-May-10, Peter Smith wrote: > PSA v5 of the patch. It is the same as v4 but with the v4-0001 part > omitted because that was already pushed. Thanks, I have pushed this. -- Álvaro Herrera39°49'30"S 73°17'W

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

You can avoid duplicating the ereport like this: + ereport(ERROR, + (errcode(ERRCODE_SYNTAX_ERROR), +errmsg("option \"%s\" specified more than once", defel->defname), +parser ? parser_errpo

Re: wal stats questions

On 2021/05/12 19:19, Fujii Masao wrote: > > > On 2021/05/11 18:46, Masahiro Ikeda wrote: >> >> >> On 2021/05/11 16:44, Fujii Masao wrote: >>> >>> >>> On 2021/04/28 9:10, Masahiro Ikeda wrote: On 2021/04/27 21:56, Fujii Masao wrote: > > > On 2021/04/26 10:11, Masahiro

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 05:30:26PM +0800, Julien Rouhaud wrote: > On Wed, May 12, 2021 at 10:57:25AM +0200, Pavel Stehule wrote: > > > > My second proposal can work for your example too. pg_stat_statements have > > to require any active queryid computing. And when it is not available, then > > the

Re: Corrected documentation of data type for the logical replication message formats.

On Wed, May 12, 2021 at 11:09 PM vignesh C wrote: ... > > Thanks for the comments. Attached v4 patch has the fix for the same. > I have not tried this patch so I cannot confirm whether it applies or renders OK, but just going by the v4 content this now LGTM. Kind Regards, Peter Smith. F

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 05:51:49PM +0800, Julien Rouhaud wrote: > On Wed, May 12, 2021 at 11:42:12AM +0200, Pavel Stehule wrote: > > this check just can check if there is "any" query-id provider. In this > > context is not important if it is buildin or external > > Yes, the idea is that if you exe

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 08:36:18PM -0400, Bruce Momjian wrote: > On Wed, May 12, 2021 at 05:51:49PM +0800, Julien Rouhaud wrote: > > On Wed, May 12, 2021 at 11:42:12AM +0200, Pavel Stehule wrote: > > > this check just can check if there is "any" query-id provider. In this > > > context is not impor

Re: compute_query_id and pg_stat_statements

At Wed, 12 May 2021 18:09:30 +0800, Julien Rouhaud wrote in > On Wed, May 12, 2021 at 06:37:24PM +0900, Kyotaro Horiguchi wrote: > > At Wed, 12 May 2021 14:05:16 +0800, Julien Rouhaud > > wrote in > > > > > > And if I'm not mistaken, pg_store_plans also wants a different queryid > > > implem

Re: compute_query_id and pg_stat_statements

At Wed, 12 May 2021 20:36:18 -0400, Bruce Momjian wrote in > On Wed, May 12, 2021 at 05:51:49PM +0800, Julien Rouhaud wrote: > > On Wed, May 12, 2021 at 11:42:12AM +0200, Pavel Stehule wrote: > > > this check just can check if there is "any" query-id provider. In this > > > context is not importa

Re: compute_query_id and pg_stat_statements

On Thu, May 13, 2021 at 08:52:36AM +0800, Julien Rouhaud wrote: > On Wed, May 12, 2021 at 08:36:18PM -0400, Bruce Momjian wrote: > > The problem with compute_query_id=auto is that there is no way to know > > if the query id is actually enabled, unless you guess from the installed > > extensions, or

RE: Parallel scan with SubTransGetTopmostTransaction assert coredump

Hi Andres, Thanks for you replay. And If you still cannot reproduce it in 2 minitus. Could you run pgbench longer time, such as 30 or 60 minutes. This coredump, It should be from parallel scan only. For normal scan(without parallel), SubTransGetTopmostTransaction assert(HeapTuple

Re: compute_query_id and pg_stat_statements

On Thu, May 13, 2021 at 09:59:43AM +0900, Kyotaro Horiguchi wrote: > > The query_id of its own is provided because pg_stat_statements did not > expose query_id. And it has been preserved only for the case the > plugin is used without pg_stat_statements activated. Now that the > in-core query_id i

Re: compute_query_id and pg_stat_statements

At Thu, 13 May 2021 09:59:43 +0900 (JST), Kyotaro Horiguchi wrote in > How about adding a GUC_INTERNAL "current_query_provider" or such? On the second thought, I wonder why we don't just call JumbleQuery in pgss_post_parse_analyze when compute_query_id is "off". We can think this behavior as t

Re: compute_query_id and pg_stat_statements

On Wed, May 12, 2021 at 09:13:25PM -0400, Bruce Momjian wrote: > On Thu, May 13, 2021 at 08:52:36AM +0800, Julien Rouhaud wrote: > > > > Well, as implemented you can get the value of compute_query_id, and if it's > > still "auto" then it's not enabled as calling queryIdWanted() would turn it > >

Re: Remove "FROM" in "DELETE FROM" when using tab-completion

On Tue, May 11, 2021 at 10:48:16AM +, tanghy.f...@fujitsu.com wrote: > Thanks for your kindly explanation. That's really nice of you. > Understand now. Thanks for the updated patch. Applied as of 1906cc0. -- Michael signature.asc Description: PGP signature

Re: compute_query_id and pg_stat_statements

On Thu, May 13, 2021 at 10:51:52AM +0900, Kyotaro Horiguchi wrote: > At Thu, 13 May 2021 09:59:43 +0900 (JST), Kyotaro Horiguchi > wrote in > > How about adding a GUC_INTERNAL "current_query_provider" or such? > > On the second thought, I wonder why we don't just call JumbleQuery in > pgss_post

Re: Always bump PG_CONTROL_VERSION?

On Wed, May 12, 2021 at 01:30:27PM -0700, Andres Freund wrote: > That said, I don't think it's a good practice to use the control file > version as an identifier for the major version. Who knows, it might be > necessary to add an optional new format in a minor version at some point > or such crazyn

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Tue, May 11, 2021 at 02:46:35PM -0400, Andrew Dunstan wrote: > On 5/11/21 2:23 PM, Alvaro Herrera wrote: >> Yes, reverting has its place. Moreover, threats of reversion have their >> place. People should definitely be working towards finding solutions to >> the problems in their commits lest t

Re: Always bump PG_CONTROL_VERSION?

On Thu, May 13, 2021 at 11:04:54AM +0900, Michael Paquier wrote: > On Wed, May 12, 2021 at 01:30:27PM -0700, Andres Freund wrote: > > That said, I don't think it's a good practice to use the control file > > version as an identifier for the major version. Who knows, it might be > > necessary to add

Re: Performance degradation of REFRESH MATERIALIZED VIEW

Hi, On 2021-05-13 11:12:43 +0900, Michael Paquier wrote: > If that's the consensus reached, that's fine by me as long as we don't > keep a 25% performance regression. Now, looking at the patch > proposed, I have to admit that this looks like some redesign of an > existing feature, so that stresse

Re: compute_query_id and pg_stat_statements

At Thu, 13 May 2021 10:02:45 +0800, Julien Rouhaud wrote in > On Thu, May 13, 2021 at 10:51:52AM +0900, Kyotaro Horiguchi wrote: > > At Thu, 13 May 2021 09:59:43 +0900 (JST), Kyotaro Horiguchi > > wrote in > > > How about adding a GUC_INTERNAL "current_query_provider" or such? > > > > On the

  1   2   >