Re: Alias collision in `refresh materialized view concurrently`

On Wed, Jun 02, 2021 at 03:44:45PM +0530, Bharath Rupireddy wrote: > Thanks.The changes with that approach are very minimal. PSA v5 and let > me know if any more changes are needed. Simple enough, so applied and back-patched. It took 8 years for somebody to complain about the current aliases, so

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On Thu, 3 Jun 2021 at 16:17, Tom Lane wrote: > > David Rowley writes: > > There are quite a few other places in that file that should be using > > DatumGetCString() instead of DatumGetPointer(). > > Should we fix those too for PG14? > > +1. I'm surprised we are not getting compiler warnings. I'

Re: security_definer_search_path GUC

On Thu, Jun 3, 2021, at 00:55, Marko Tiikkaja wrote: > On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote: >> __But if running a recent PostgreSQL version, with support for extensions, I >> think an even cleaner solution >> would be to package such compatibility versions in a "compat" extension,

Re: Transactions involving multiple postgres foreign servers, take 2

On 2021/05/25 21:59, Masahiko Sawada wrote: > On Fri, May 21, 2021 at 5:48 PM Masahiro Ikeda > wrote: >> >> On 2021/05/21 13:45, Masahiko Sawada wrote: >>> >>> Yes. We also might need to be careful about the order of foreign >>> transaction resolution. I think we need to resolve foreign> trans

Re: Race condition in recovery?

At Tue, 1 Jun 2021 16:45:52 -0400, Robert Haas wrote in > On Fri, May 28, 2021 at 2:05 AM Kyotaro Horiguchi > wrote: > > Mmmm. That looks like meaning that we don't intend to support the > > Dilip's case, and means that we support the use of > > archive-command-copies-only-other-than-wal-segmen

Re: Documentation missing for PGSSLCRLDIR

At Thu, 3 Jun 2021 12:13:22 +0900, Michael Paquier wrote in > Hi all, > > I have noticed that the documentation for PGSSLCRLDIR is missing. > That seems like an oversight in f5465fa. > > Thoughts? Ugg.. Thanks for finding that. I don't find a similar mistake in the same page. regards. --

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On Thu, 3 Jun 2021 at 15:06, David Rowley wrote: > > On Thu, 3 Jun 2021 at 15:01, Michael Paquier wrote: > > As you already did > > 110d817, perhaps you would prefer taking care of it? > > Ok. I'll take care of it. Pushed. David

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

David Rowley writes: > There are quite a few other places in that file that should be using > DatumGetCString() instead of DatumGetPointer(). > Should we fix those too for PG14? +1. I'm surprised we are not getting compiler warnings. regards, tom lane

Re: locking [user] catalog tables vs 2pc vs logical rep

On Thu, Jun 3, 2021 at 9:18 AM osumi.takami...@fujitsu.com wrote: > > On Tuesday, June 1, 2021 4:33 PM Peter Smith > > To: Andres Freund > > Cc: PostgreSQL-development ; Amit Kapila > > ; Markus Wanner > > > > Subject: Re: locking [user] catalog tables vs 2pc vs logical rep > > > > Hi. > > > >

Re: Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command

On Thu, Jun 3, 2021 at 4:48 AM Jeff Davis wrote: > > Commit 19890a064 changed pg_create_logical_replication_slot() to allow > decoding of two-phase transactions, but did not extend the > CREATE_REPLICATION_SLOT command to support it. Strangely, it does > extend the CreateReplicationSlotCmd struct

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On Thu, 3 Jun 2021 at 15:06, David Rowley wrote: > > On Thu, 3 Jun 2021 at 15:01, Michael Paquier wrote: > > As you already did > > 110d817, perhaps you would prefer taking care of it? > > Ok. I'll take care of it. I looked at this and couldn't help but notice how the following used DatumGetPoin

RE: locking [user] catalog tables vs 2pc vs logical rep

On Tuesday, June 1, 2021 4:33 PM Peter Smith > To: Andres Freund > Cc: PostgreSQL-development ; Amit Kapila > ; Markus Wanner > > Subject: Re: locking [user] catalog tables vs 2pc vs logical rep > > Hi. > > The attached PG docs patch about catalog deadlocks was previously > implemented in anot

Documentation missing for PGSSLCRLDIR

Hi all, I have noticed that the documentation for PGSSLCRLDIR is missing. That seems like an oversight in f5465fa. Thoughts? -- Michael diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 2fc638c376..e1fc7f1f2b 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@

Re: TAP tests still sensitive to various PG* environment variables

On Wed, Jun 02, 2021 at 10:39:56AM +0200, Daniel Gustafsson wrote: > Seems like a good idea, to keep test invocation stable across branches, minus > PGSSLCRLDIR and PGSSLSNI which are only available in HEAD etc. Right. This took me a couple of hours to make consistent across all the branches. Af

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On Thu, 3 Jun 2021 at 15:01, Michael Paquier wrote: > As you already did > 110d817, perhaps you would prefer taking care of it? Ok. I'll take care of it. Thanks David

Re: Re[3]: On login trigger: take three

On Fri, May 21, 2021 at 2:46 PM Greg Nancarrow wrote: > > On Thu, May 20, 2021 at 2:45 PM Ivan Panchenko wrote: > > > > I have upgraded the patch for the 14th version. > > > > I have some feedback on the patch: > I've attached an updated version of the patch. I've applied my review comments and

Re: What to call an executor node which lazily caches tuples in a hash table? (GUC)

On Thu, 3 Jun 2021 at 14:36, Justin Pryzby wrote: > > You started the thread about what to call the node, but what about its GUC? > > Should it be enable_result_cache instead of enable_resultcache? > > See also Robert's opinion last year about enable_incrementalsort and > "economizing on undersco

Re: TAP tests still sensitive to various PG* environment variables

On Wed, Jun 02, 2021 at 03:43:46PM -0400, Andrew Dunstan wrote: > Let's change it to something like: > > my @scrubkeys = qw ( PGCHANNELBINDING >    PGCLIENTENCODING PGCONNECT_TIMEOUT PGDATA >    ... >     ); > delete @ENV{@scrubkeys}; Good idea. I have used that. Thanks. -- M

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On Thu, Jun 03, 2021 at 01:53:34PM +1200, David Rowley wrote: > I think it would be good to fix at least the instances that are new > code in PG14 before we branch for PG15. They all seem low enough risk > and worth keeping the new-to-PG14 code as close to the same as > possible between major vers

Re: Performance degradation of REFRESH MATERIALIZED VIEW

On Thu, Jun 3, 2021 at 8:02 AM Tomas Vondra wrote: > > OK, > > As mentioned in the previous message, I've reverted most of 39b66a91bd. > It took a bit longer to test, because the revert patch I shared a couple > days ago was actually incorrect/buggy in one place. > > I'm not entirely happy about t

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

David Rowley writes: > On Wed, 2 Jun 2021 at 16:29, Michael Paquier wrote: >> Indeed, that's the same thing as 110d817 to make all those calls >> cheaper. No objections from me to do those changes now rather than >> later on HEAD. > I think it would be good to fix at least the instances that ar

Re: PoC/WIP: Extended statistics on expressions (\d in old client)

On Fri, Jan 22, 2021 at 02:09:04PM +0100, Tomas Vondra wrote: > On 1/22/21 5:01 AM, Justin Pryzby wrote: > > On Fri, Jan 22, 2021 at 04:49:51AM +0100, Tomas Vondra wrote: > > > > > | Statistics objects: > > > > > | "public"."s2" (ndistinct, dependencies, mcv) ON FROM t > > > > > > Umm, for me

Re: A micro-optimisation for ProcSendSignal()

On Fri, Mar 12, 2021 at 12:31 AM Thomas Munro wrote: > ProcSendSignal(pid) searches the ProcArray for the given pid and then > sets that backend's procLatch. It has only two users: UnpinBuffer() > and ReleasePredicateLocks(). In both cases, we could just as easily > have recorded the pgprocno in

Re: What to call an executor node which lazily caches tuples in a hash table? (GUC)

You started the thread about what to call the node, but what about its GUC? Should it be enable_result_cache instead of enable_resultcache? See also Robert's opinion last year about enable_incrementalsort and "economizing on underscores". https://www.postgresql.org/message-id/flat/CA%2BTgmoazhPw

Re: Outdated comments about proc->sem in lwlock.c

On Wed, Mar 10, 2021 at 1:11 AM Thomas Munro wrote: > In passing I noticed that lwlock.c contains 3 comments about bogus > wakeups due to sharing proc->sem with the heavyweight lock manager and > ProcWaitForSignal. Commit 675f55e (9.5) switched those things > from proc->sem to proc->procLatch

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On Wed, 2 Jun 2021 at 16:29, Michael Paquier wrote: > > On Wed, Jun 02, 2021 at 01:37:51AM +, houzj.f...@fujitsu.com wrote: > > In the latest HEAD branch, I found some places were using > > appendStringInfo/appendPQExpBuffer() when they could have been using > > appendStringInfoString/ appendP

Re: parent foreign tables and row marks

On Thu, Jun 3, 2021 at 3:39 AM Tom Lane wrote: > > Amit Langote writes: > > I noticed that 428b260f87e8 (v12) broke the cases where a parent > > foreign table has row marks assigned. > > Indeed :-(. Fix pushed. I tweaked the comments and test case slightly. Thank you. -- Amit Langote EDB: ht

Decoding of two-phase xacts missing from CREATE_REPLICATION_SLOT command

Commit 19890a064 changed pg_create_logical_replication_slot() to allow decoding of two-phase transactions, but did not extend the CREATE_REPLICATION_SLOT command to support it. Strangely, it does extend the CreateReplicationSlotCmd struct to add a "two_phase" field, but doesn't set it anywhere. Th

Re: Performance degradation of REFRESH MATERIALIZED VIEW

OK, As mentioned in the previous message, I've reverted most of 39b66a91bd. It took a bit longer to test, because the revert patch I shared a couple days ago was actually incorrect/buggy in one place. I'm not entirely happy about the end result (as it does not really help with TOAST tables), so h

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021 at 11:32 PM Joel Jacobson wrote: > On Wed, Jun 2, 2021, at 18:36, Marko Tiikkaja wrote: > > The use case is: version upgrades. I want to be able to have a > search_path of something like 'pg_catalog, compat, public'. That way we > can provide compatibility versions of newer

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021 at 10:20 PM Alvaro Herrera wrote: > On 2021-Jun-02, Marko Tiikkaja wrote: > > > The use case is: version upgrades. I want to be able to have a > search_path > > of something like 'pg_catalog, compat, public'. That way we can provide > > compatibility versions of newer functi

Re: pgsql: Add regression test for recovery pause.

On 6/2/21 5:26 PM, Tom Lane wrote: > Fujii Masao writes: >> Add regression test for recovery pause. > Buildfarm member jacana doesn't like this patch: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2021-06-02%2012%3A00%3A44 > > the symptom being > > Jun 02 09:05:17 t/005_r

Re: improve installation short version

Andrew Dunstan writes: > On 6/2/21 4:58 PM, Mark Dilger wrote: >> Prior to where your patch makes changes, the docs say, "If you are building >> PostgreSQL for Microsoft Windows, read this chapter if you intend to build >> with MinGW or Cygwin". I think going on to tell the users to use `su` is

Re: improve installation short version

On 6/2/21 4:58 PM, Mark Dilger wrote: > >> On Jun 2, 2021, at 1:43 PM, Andrew Dunstan wrote: >> >> > It's not the fault of your patch, but the docs seem to be misleading in ways > that your comments don't fix. (Or perhaps my Windows knowledge is just too > lacking to realize why these instru

Re: pgsql: Add regression test for recovery pause.

Fujii Masao writes: > Add regression test for recovery pause. Buildfarm member jacana doesn't like this patch: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2021-06-02%2012%3A00%3A44 the symptom being Jun 02 09:05:17 t/005_replay_delay..# poll_query_until ti

Re: Speed up pg_checksums in cases where checksum already set

Newer version attach that adds a small documentation tweak as well. Cheers, Greg pg_checksums.optimize.writes.and.always.sync.patch Description: Binary data

Re: improve installation short version

> On Jun 2, 2021, at 1:43 PM, Andrew Dunstan wrote: > > It's not the fault of your patch, but the docs seem to be misleading in ways that your comments don't fix. (Or perhaps my Windows knowledge is just too lacking to realize why these instructions are ok?) Prior to where your patch mak

improve installation short version

I just had a case where a new user was slightly confused by our installation "Short Version" instructions. I think the confusion would be lessened by adding a couple of comments, as in the attached patch. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com diff --git a/doc/src/

Re: pg_stat_progress_create_index vs. parallel index builds

On 2021-Jun-02, Tomas Vondra wrote: > On 6/2/21 6:38 PM, Alvaro Herrera wrote: > > Hmm, that's odd. I distinctly recall testing the behavior with parallel > > workers, and it is mentioned by Rahila in the original thread, and I > > think we tried to ensure that it was sane. I am surprised to le

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021, at 18:36, Marko Tiikkaja wrote: > On Wed, Jun 2, 2021 at 3:46 PM Joel Jacobson wrote: >> If a database object is to be accessed unqualified by all users, isn't the >> 'public' schema a perfect fit for it? How will it be helpful to create >> different database objects in diff

Re: make world and install-world without docs

Andrew Dunstan writes: > I'm inclined to agree with Alvaro that the messages are at best an > oddity. Standard Unix practice is to be silent on success. We've been steadily moving towards less chatter during builds. I'd be good with dropping these messages in HEAD, but doing so in the back branch

Re: pg_stat_progress_create_index vs. parallel index builds

On 6/2/21 6:38 PM, Alvaro Herrera wrote: > On 2021-Jun-02, Tomas Vondra wrote: > >> Hi, >> >> While experimenting with parallel index builds, I've noticed a somewhat >> strange behavior of pg_stat_progress_create_index when a btree index is >> built with parallel workers - some of the phases se

Re: make world and install-world without docs

On 6/1/21 6:23 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 31.05.21 16:16, Andrew Dunstan wrote: >>> make SKIPDOCS=1 world >>> make SKIPDOCS=1 install-world >> Maybe this should be configure option? That's generally where you set >> what you want to build or not build. (That might al

Re: TAP tests still sensitive to various PG* environment variables

On 6/1/21 9:49 PM, Michael Paquier wrote: > Hi all, > > While looking at a separate issue, I have noticed that TestLib.pm is > lagging behind in terms of environment variables it had better mask to > avoid failures: > https://www.postgresql.org/message-id/ylxjfov3teapi...@paquier.xyz > > Once I b

Re: security_definer_search_path GUC

On 2021-Jun-02, Marko Tiikkaja wrote: > The use case is: version upgrades. I want to be able to have a search_path > of something like 'pg_catalog, compat, public'. That way we can provide > compatibility versions of newer functions in the "compat" schema, which get > taken over by pg_catalog wh

Re: Support for CREATE MODULE?

On 2021-Jun-02, Jim Mlodgenski wrote: > Attached is a POC patch for modules. I modeled it as a sub-schema because > that is more what it seems like to me. It adds additional columns to > pg_namespace and allows for 3-part (or 4 with the database name) naming > of objects within the module. This si

Re: parent foreign tables and row marks

Amit Langote writes: > I noticed that 428b260f87e8 (v12) broke the cases where a parent > foreign table has row marks assigned. Indeed :-(. Fix pushed. I tweaked the comments and test case slightly. regards, tom lane

Re: security_definer_search_path GUC

On Wed, Jun 02, 2021 at 02:46:08PM +0200, Joel Jacobson wrote: > > But perhaps the search_path as an uninstallable extension is a less invasive > idea. I don't that that happening any time soon. An extension only adds SQL objects, it doesn't impact backend code. You can ship a module with your

Re: security_definer_search_path GUC

st 2. 6. 2021 v 14:46 odesílatel Joel Jacobson napsal: > On Wed, Jun 2, 2021, at 09:07, Pavel Stehule wrote: > > st 2. 6. 2021 v 8:45 odesílatel Joel Jacobson napsal: > > 'search_path' is a bit like a global variable in C, that can change the > behaviour of the SQL commands executed. > It makes

Re: pg_stat_progress_create_index vs. parallel index builds

On 2021-Jun-02, Tomas Vondra wrote: > Hi, > > While experimenting with parallel index builds, I've noticed a somewhat > strange behavior of pg_stat_progress_create_index when a btree index is > built with parallel workers - some of the phases seem to be missing. Hmm, that's odd. I distinctly re

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021 at 3:46 PM Joel Jacobson wrote: > If a database object is to be accessed unqualified by all users, isn't the > 'public' schema a perfect fit for it? How will it be helpful to create > different database objects in different schemas, if also adding all such > schemas to the sea

speed up verifying UTF-8

For v10, I've split the patch up into two parts. 0001 uses pure C everywhere. This is much smaller and easier to review, and gets us the most bang for the buck. One concern Heikki raised upthread is that platforms with poor unaligned-memory access will see a regression. We could easily add an #ifd

Re: pg_stat_progress_create_index vs. parallel index builds

On Wed, 2 Jun 2021 at 17:42, Tomas Vondra wrote: > > On 6/2/21 4:54 PM, Matthias van de Meent wrote: > > On Wed, 2 Jun 2021 at 15:23, Tomas Vondra > > wrote: > >> > >> ... > >> > > > > After looking at it a bit more, it seems like a solution was actually > > easier than I'd expected. PFA a prot

Re: pg_stat_progress_create_index vs. parallel index builds

On 6/2/21 4:54 PM, Matthias van de Meent wrote: On Wed, 2 Jun 2021 at 15:23, Tomas Vondra wrote: ... > After looking at it a bit more, it seems like a solution was actually easier than I'd expected. PFA a prototype (unvalidated, but check-world -ed) patch that would add these subphases of p

Re: Support for CREATE MODULE?

On Wed, Jun 2, 2021, at 16:43, Jim Mlodgenski wrote: > On Wed, Jun 2, 2021 at 9:58 AM Tom Lane > wrote: > > I wonder whether it'd be better to consider modules as a kind of > > extension, or at least things with the same sort of ownership relations > > as extensions hav

Re: Support for CREATE MODULE?

Bruce Momjian writes: > If we go in this direction, I assume we would just disallow a schema > name matching the database name. That seems quite impossible to enforce. regression=# create database d1; CREATE DATABASE regression=# alter database d1 rename to d2; ALTER DATABASE The system had no

Re: Support for CREATE MODULE?

On 6/2/21 10:43 AM, Jim Mlodgenski wrote: On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote: I wonder whether it'd be better to consider modules as a kind of extension, or at least things with the same sort of ownership relations as extensions have. That would solve the problem of associating obj

Re: Support for CREATE MODULE?

On Wed, Jun 2, 2021 at 10:43:10AM -0400, Jim Mlodgenski wrote: > On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote: > > > > In the first place, what do you think the primary key of pg_namespace is > > now? > > In the patch the unique constraint is (nspname, nspnamespace) which is > certainly awkwar

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On 02.06.21 12:57, Alvaro Herrera wrote: In the latest HEAD branch, I found some places were using appendStringInfo/appendPQExpBuffer() when they could have been using appendStringInfoString/ appendPQExpBufferStr() instead. I think we'd better fix these places in case other developers will use

Re: pg_stat_progress_create_index vs. parallel index builds

On Wed, 2 Jun 2021 at 15:23, Tomas Vondra wrote: > > > > On 6/2/21 3:03 PM, Matthias van de Meent wrote: > > On Wed, 2 Jun 2021 at 13:57, Tomas Vondra > > wrote: > >> > >> Hi, > >> > >> While experimenting with parallel index builds, I've noticed a somewhat > >> strange behavior of pg_stat_progr

Re: ALTER SUBSCRIPTION REFRESH PUBLICATION has default copy_data = true?

On Wed, Jun 2, 2021 at 6:40 AM Peter Smith wrote: > > Hi. > > The documentation of ALTER SUBSCRIPTION REFRESH PUBLICATION [1] says: > > -- > > REFRESH PUBLICATION > > Fetch missing table information from publisher. This will start > replication of tables that were added to the subscribed-t

Re: ALTER SUBSCRIPTION REFRESH PUBLICATION has default copy_data = true?

On 02.06.21 03:10, Peter Smith wrote: The documentation of ALTER SUBSCRIPTION REFRESH PUBLICATION [1] says: But I found that default copy_data = true to be unintuitive. e.g. When I had previously done the CREATE SUBSCRIPTION using copy_data = false, then I assumed (wrongly) that the subscript

Re: tab-complete for CREATE TYPE ... SUBSCRIPT

"tanghy.f...@fujitsu.com" writes: > Attached a patch to support tab completion for CREATE TYPE ... SUBSCRIPT > introduced at c7aba7c14e. Huh ... I had no idea anyone had taught tab-complete about the individual fields of CREATE TYPE. Experimenting with it, I see that the multirange patch missed

Re: Support for CREATE MODULE?

On Wed, Jun 2, 2021 at 9:58 AM Tom Lane wrote: > > In the first place, what do you think the primary key of pg_namespace is now? In the patch the unique constraint is (nspname, nspnamespace) which is certainly awkward. I initially went down the pg_module route to avoid adding another catalog, but

Re: Speed up pg_checksums in cases where checksum already set

Fair enough; thanks for the feedback. Attached is a new version that does an unconditional sync (well, unless do_sync is false, a flag I am not particularly fond of). Cheers, Greg pg_checksums.optimize.writes.always.sync.patch Description: Binary data

Re: tab-complete for CREATE TYPE ... SUBSCRIPT

On Wed, Jun 2, 2021 at 4:37 PM tanghy.f...@fujitsu.com wrote: > > On Wednesday, June 2, 2021 6:51 PM, tanghy.f...@fujitsu.com wrote: > > >Attached a patch to support tab completion for CREATE TYPE ... SUBSCRIPT > >introduced at c7aba7c14e. > > Oops, comma forgot. patch Updated. v2 patch LGTM. W

Re: Support for CREATE MODULE?

Jim Mlodgenski writes: > Questions > - Do we want to add module support? Certainly many people have asked for that, or things like that. > - If we do, should it be implemented as a type of namespace or should it > be its own object type that lives in something like pg_module? While I didn't r

Re: [BUG]Update Toast data failure in logical replication

On Wed, Jun 2, 2021 at 7:20 PM Kuntal Ghosh wrote: > > On Wed, Jun 2, 2021 at 3:10 PM Dilip Kumar wrote: > > > > Yes, you are right. I will change it in the next version, along with > > the test case. > > > +/* > + * if the key hasn't changed and we're only logging the key, we're done. >

Re: [BUG]Update Toast data failure in logical replication

On Wed, Jun 2, 2021 at 3:10 PM Dilip Kumar wrote: > > Yes, you are right. I will change it in the next version, along with > the test case. > +/* + * if the key hasn't changed and we're only logging the key, we're done. + * But if tuple has external data then we might have to detoast

Support for CREATE MODULE?

Working with users over the years, some have large libraries of server side code sometimes consisting of 100k+ lines of code over 1000+ functions and procedures. This usually comes from a migration of a commercial database like Oracle where it was best practice to put all of your business logic int

Re: pg_stat_progress_create_index vs. parallel index builds

On 6/2/21 3:03 PM, Matthias van de Meent wrote: On Wed, 2 Jun 2021 at 13:57, Tomas Vondra wrote: Hi, While experimenting with parallel index builds, I've noticed a somewhat strange behavior of pg_stat_progress_create_index when a btree index is built with parallel workers - some of the pha

Re: pg_stat_progress_create_index vs. parallel index builds

On Wed, 2 Jun 2021 at 13:57, Tomas Vondra wrote: > > Hi, > > While experimenting with parallel index builds, I've noticed a somewhat > strange behavior of pg_stat_progress_create_index when a btree index is > built with parallel workers - some of the phases seem to be missing. > > In serial (no pa

Re: Race condition in recovery?

On Tue, Jun 01, 2021 at 04:45:52PM -0400, Robert Haas wrote: > On Fri, May 28, 2021 at 2:05 AM Kyotaro Horiguchi > wrote: > > Agreed. I often annoyed by a long-lasting TAP script when I wanted to > > do one of the test items in it. However, I was not sure which is our > > policy here, consolidati

Re: security_definer_search_path GUC

On Wed, Jun 2, 2021, at 09:07, Pavel Stehule wrote: > st 2. 6. 2021 v 8:45 odesílatel Joel Jacobson napsal: >> __'search_path' is a bit like a global variable in C, that can change the >> behaviour of the SQL commands executed. >> It makes unqualified SQL code context-sensitive; you don't know by

Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options

On Wed, Jun 2, 2021 at 11:43 AM Peter Smith wrote: > Yes, it looks better, but (since the masks are all 1 bit) I was only > asking why not do like: > > if (supported_opts & SUBOPT_CONNECT) > if (supported_opts & SUBOPT_ENABLED) > if (supported_opts & SUBOPT_SLOT_NAME) > if (supported_opts & SUBOPT

Re: [PATCH] Allow queries in WHEN expression of FOR EACH STATEMENT triggers

Hi Hackers, Attached is a new version of this patch. I resurrected it after removing it from the commitfest last year; I'll add it back in to the next CF. The main change is a switch to using SPI for expression evaluation. The plans are also cached along the same lines as the RI trigger plans.

pg_stat_progress_create_index vs. parallel index builds

Hi, While experimenting with parallel index builds, I've noticed a somewhat strange behavior of pg_stat_progress_create_index when a btree index is built with parallel workers - some of the phases seem to be missing. In serial (no parallelism) mode, the progress is roughly this (it's always

RE: tab-complete for CREATE TYPE ... SUBSCRIPT

On Wednesday, June 2, 2021 6:51 PM, tanghy.f...@fujitsu.com wrote: >Attached a patch to support tab completion for CREATE TYPE ... SUBSCRIPT >introduced at c7aba7c14e. Oops, comma forgot. patch Updated. Regards, Tang V2-0001-psql-tab-complete-CREATE-TYPE-.-SUBSCRIPT.patch Description: V2-0001

Re: Fixup some appendStringInfo and appendPQExpBuffer calls

On 2021-Jun-02, houzj.f...@fujitsu.com wrote: > Hi, > > In the latest HEAD branch, I found some places were using > appendStringInfo/appendPQExpBuffer() when they could have been using > appendStringInfoString/ appendPQExpBufferStr() instead. I think we'd better > fix these places in case other d

Re: Alias collision in `refresh materialized view concurrently`

On Wed, Jun 2, 2021 at 1:27 PM Michael Paquier wrote: > > On Wed, Jun 02, 2021 at 10:53:22AM +0530, Bharath Rupireddy wrote: > > Thanks. PSA v4. > > Thanks for the new version. > > +MyProcPid, tempname, MyProcPid, MyProcPid, > +tempname, MyProcPid, MyProcPid

tab-complete for CREATE TYPE ... SUBSCRIPT

Hi Attached a patch to support tab completion for CREATE TYPE ... SUBSCRIPT introduced at c7aba7c14e. Regards, Tang 0001-psql-tab-complete-CREATE-TYPE-.-SUBSCRIPT.patch Description: 0001-psql-tab-complete-CREATE-TYPE-.-SUBSCRIPT.patch

Re: [BUG]Update Toast data failure in logical replication

On Wed, Jun 2, 2021 at 2:37 PM tanghy.f...@fujitsu.com wrote: > > On Wed, Jun 2, 2021 2:44 PM Dilip Kumar wrote: > > Attached patch fixes that, I haven't yet added the test case. Once > > someone confirms on the approach then I will add a test case to the > > patch. > > key_tuple = heap_

RE: [BUG]Update Toast data failure in logical replication

On Wed, Jun 2, 2021 2:44 PM Dilip Kumar wrote: > Attached patch fixes that, I haven't yet added the test case. Once > someone confirms on the approach then I will add a test case to the > patch. key_tuple = heap_form_tuple(desc, values, nulls); *copy = true; ...

Re: join pushdown and issue with foreign update

On Wed, Jun 2, 2021 at 4:39 PM Andrey Lepikhov wrote: > On 2/6/21 02:32, Tom Lane wrote: > > I wrote: > >> I think a preferable fix involves making sure that the correct > >> record-type typmod is propagated to record_in in this context. > >> Alternatively, maybe we could insert the foreign table'

Re: TAP tests still sensitive to various PG* environment variables

> On 2 Jun 2021, at 03:49, Michael Paquier wrote: > Attached is a patch to strengthen all that, which I think we'd better > backpatch. +1 > Any objections to that? Seems like a good idea, to keep test invocation stable across branches, minus PGSSLCRLDIR and PGSSLSNI which are only available in

Re: join pushdown and issue with foreign update

Tom Lane писал 2021-06-02 00:32: I wrote: I think a preferable fix involves making sure that the correct record-type typmod is propagated to record_in in this context. Alternatively, maybe we could insert the foreign table's rowtype during execution of the input operation, without touching the p

Re: Two patches to speed up pg_rewind.

On Wed, Jun 02, 2021 at 06:20:30PM +1200, Thomas Munro wrote: > The main thing I noticed was that Linux < 5.3 can fail with EXDEV if > you cross a filesystem boundary, is that something we need to worry > about there? Hmm. Good point. That may justify having a switch to control that. -- Michael

Re: Alias collision in `refresh materialized view concurrently`

On Wed, Jun 02, 2021 at 10:53:22AM +0530, Bharath Rupireddy wrote: > Thanks. PSA v4. Thanks for the new version. +MyProcPid, tempname, MyProcPid, MyProcPid, +tempname, MyProcPid, MyProcPid, MyProcPid, +MyProcPid, MyProcPid, MyProcPid); T

Re: join pushdown and issue with foreign update

On Wed, Jun 2, 2021 at 6:32 AM Tom Lane wrote: > I wrote: > > I think a preferable fix involves making sure that the correct > > record-type typmod is propagated to record_in in this context. > > Alternatively, maybe we could insert the foreign table's rowtype > > during execution of the input ope

Re: join pushdown and issue with foreign update

On 2/6/21 02:32, Tom Lane wrote: I wrote: I think a preferable fix involves making sure that the correct record-type typmod is propagated to record_in in this context. Alternatively, maybe we could insert the foreign table's rowtype during execution of the input operation, without touching the p

Re: security_definer_search_path GUC

st 2. 6. 2021 v 8:45 odesílatel Joel Jacobson napsal: > On Tue, Jun 1, 2021, at 18:05, Pavel Stehule wrote: > > I learned programming on Orafce, and I didn't expect any success, so I > designed it quickly, and the placing of old Orafce's functions to schemas > is messy. > > I am sure, if I starte