Re: Logical replication - schema change not invalidating the relation cache

2021-07-02 Thread Dilip Kumar
On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar wrote: > > Yeah, this looks like a bug. I will look at the patch. > While looking into this, I think the main cause of the problem is that schema rename does not invalidate the relation cache right? I also tried other cases e.g. if there is an open

Re: logical replication worker accesses catalogs in error context callback

2021-07-02 Thread Bharath Rupireddy
On Sat, Jul 3, 2021 at 2:19 AM Tom Lane wrote: > > I wrote: > > Didn't look at 0002 yet. > > ... and now that I have, I don't like it much. It adds a lot of > complexity, plus some lookup cycles that might be wasted. I experimented > with looking into the range table as I suggested previously,

Re: logical replication worker accesses catalogs in error context callback

2021-07-02 Thread Bharath Rupireddy
On Sat, Jul 3, 2021 at 1:37 AM Tom Lane wrote: > > Bharath Rupireddy writes: > >> << Attaching v5-0001 here again for completion >> > >> I'm attaching v5-0001 patch that avoids printing the column type names > >> in the context message thus no cache lookups have to be done in the > >> error

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Noah Misch
On Fri, Jul 02, 2021 at 11:20:17AM -0400, Tom Lane wrote: > Alvaro Herrera writes: > > Now it's hoverfly: > > ! nm -A -u libpq.so.5 2>/dev/null | grep -v __cxa_atexit | grep exit > > libpq.so.5: atexit U - > > libpq.so.5: pthread_exit U - > > Ugh. What

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Tom Lane
"alvhe...@alvh.no-ip.org" writes: > gcc here is 8.3.0. Hmmm ... mine is 8.4.1. I'm about to go out to dinner, but will check into this with some newer gcc versions later. regards, tom lane

Re: Numeric multiplication overflow errors

2021-07-02 Thread Dean Rasheed
On Fri, 2 Jul 2021 at 12:56, David Rowley wrote: > > On Fri, 2 Jul 2021 at 22:55, Dean Rasheed wrote: > > Here's an update with the > > last set of changes discussed. > > Looks good to me. Thanks for the review and testing! > Just the question of if we have any problems changing the serialized

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread alvhe...@alvh.no-ip.org
On 2021-Jul-02, Jacob Champion wrote: > Only src/common: > > controldata_utils_shlib.o: > U close > U __errno_location > U exit Actually, I do see these in the .o files as well, but they don't make it to the .a file. gcc here is 8.3.0. --

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Jacob Champion
On Fri, 2021-07-02 at 18:45 -0400, Tom Lane wrote: > Jacob Champion writes: > > On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote: > > > What configure options are you using? > > Just `./configure --enable-coverage`, nothing else. I distclean'd right > > before for good measure. > > Hmph.

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Tom Lane
Jacob Champion writes: > On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote: >> What configure options are you using? > Just `./configure --enable-coverage`, nothing else. I distclean'd right > before for good measure. Hmph. There's *something* different about your setup from what either Alvaro

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Jacob Champion
On Fri, 2021-07-02 at 18:20 -0400, Tom Lane wrote: > What configure options are you using? Just `./configure --enable-coverage`, nothing else. I distclean'd right before for good measure. > Does "nm -u" report "exit" being referenced from any *.o in libpq, > or from any *_shlib.o in src/port/ or

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Tom Lane
Jacob Champion writes: > With latest HEAD, building with --enable-coverage still fails on my > Ubuntu 20.04: > ! nm -A -u libpq.so.5.15 2>/dev/null | grep -v __cxa_atexit | grep exit > libpq.so.5.15: U exit@@GLIBC_2.2.5 Hm, weird. I don't see that here on RHEL8, and

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Jacob Champion
On Wed, 2021-06-30 at 10:42 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > On 2021-Jun-30, Tom Lane wrote: > > > You mentioned __gcov_exit, but I'm not sure if we need an > > > exception for that. I see it referenced by the individual .o > > > files, but the completed .so has no such

Re: rand48 replacement

2021-07-02 Thread Fabien COELHO
Hello Dean, It may be true that the bias is of the same magnitude as FP multiply, but it is not of the same nature. With FP multiply, the more-likely-to-be-chosen values are more-or-less evenly distributed across the range, whereas modulo concentrates them all at one end, making it more

Re: psql - factor out echo code

2021-07-02 Thread Fabien COELHO
"-- # QUERY\n%s\n\n" Attached an attempt along those lines. I found another duplicate of the ascii-art printing in another function. Completion queries seems to be out of the echo/echo hidden feature. Incredible, there is a (small) impact on regression tests for the \gexec case. All

Re: psql - factor out echo code

2021-07-02 Thread Tom Lane
Alvaro Herrera writes: > I think the most interesting case for decoration is the "step by step" > mode, where you want the "title" that precedes each query be easily > visible. I'm okay with leaving the step-by-step prompt as-is, personally. It's the inconsistency of the other ones that bugs me.

Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)

2021-07-02 Thread Ranier Vilela
Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor < mahi6...@gmail.com> escreveu: > On Fri, 2 Jul 2021 at 01:13, Ranier Vilela wrote: > > > > Hi, > > > > The function FreePageManagerPutInternal can access an uninitialized > variable, > > if the following conditions occur: > > Patch

Re: psql - factor out echo code

2021-07-02 Thread Alvaro Herrera
On 2021-Jul-02, Tom Lane wrote: > Fabien COELHO writes: > > Yes. Maybe decorations should be SQL comments, and the purpose/origin of > > the query could be made clear as you suggest, eg something like markdown > > in a comment: > >"-- # QUERY\n%s\n\n" > > If we keep the decoration, I'd

Re: psql - factor out echo code

2021-07-02 Thread Tom Lane
Fabien COELHO writes: > Yes. Maybe decorations should be SQL comments, and the purpose/origin of > the query could be made clear as you suggest, eg something like markdown > in a comment: >"-- # QUERY\n%s\n\n" If we keep the decoration, I'd agree with dropping all the asterisks. I'd vote

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

2021-07-02 Thread Tom Lane
Gavin Flower writes: > On 2/07/21 8:39 pm, David Rowley wrote: >> That's a good question. There was an argument in [1] that mentions >> that there might be a group of people who rely on aggregation being >> done in a certain order where they're not specifying an ORDER BY >> clause in the

Re: logical replication worker accesses catalogs in error context callback

2021-07-02 Thread Tom Lane
I wrote: > Didn't look at 0002 yet. ... and now that I have, I don't like it much. It adds a lot of complexity, plus some lookup cycles that might be wasted. I experimented with looking into the range table as I suggested previously, and that seems to work; see attached. (This includes a

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

2021-07-02 Thread Gavin Flower
On 2/07/21 8:39 pm, David Rowley wrote: On Fri, 2 Jul 2021 at 19:54, Ronan Dunklau wrote: I don't know if it's acceptable, but in the case where you add both an aggregate with an ORDER BY clause, and another aggregate without the clause, the output for the unordered one will change and use the

Re: Synchronous commit behavior during network outage

2021-07-02 Thread Jeff Davis
On Fri, 2021-07-02 at 11:39 +0500, Andrey Borodin wrote: > If the failover happens due to unresponsive node we cannot just turn > off sync rep. We need to have some spare connections for that (number > of stuck backends will skyrocket during network partitioning). We > need available descriptors

Re: logical replication worker accesses catalogs in error context callback

2021-07-02 Thread Tom Lane
Bharath Rupireddy writes: >> << Attaching v5-0001 here again for completion >> >> I'm attaching v5-0001 patch that avoids printing the column type names >> in the context message thus no cache lookups have to be done in the >> error context callback. I think the column name is enough to know on

Re: psql - factor out echo code

2021-07-02 Thread Fabien COELHO
Hello Tom, I went to commit this, figuring that it was a trivial bit of code consolidation, but as I looked around in common.c I got rather unhappy with the inconsistent behavior of things. Examining the various places that implement "echo"-related logic, we have the three places this patch

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

2021-07-02 Thread Justin Pryzby
On Tue, Apr 06, 2021 at 11:01:31AM -0500, Justin Pryzby wrote: > On Wed, Dec 23, 2020 at 01:17:10PM -0600, Justin Pryzby wrote: > > On Mon, Nov 23, 2020 at 04:14:18PM -0500, Tom Lane wrote: > > > * I noticed that you did s/stat/lstat/. That's fine on Unix systems, > > > but it won't have any

Re: Numeric multiplication overflow errors

2021-07-02 Thread Ranier Vilela
On Fri, 2 Jul 2021 at 22:55, Dean Rasheed wrote: > Here's an update with the > last set of changes discussed. If you allow me a small suggestion. Move the initializations of the variable tmp_var to after check if the function can run. Saves some cycles, when not running. /* Ensure we disallow

Re: Increase value of OUTER_VAR

2021-07-02 Thread Tom Lane
Here's a more fleshed-out version of this patch. I ran around and fixed all the places where INNER_VAR etc. were being assigned directly to a variable or parameter of type Index, and also grepped for 'Index.*varno' to find suspicious declarations. (I didn't change every last instance of the

Re: Signed vs. Unsigned (some)

2021-07-02 Thread Ranier Vilela
Em sex., 2 de jul. de 2021 às 13:29, Alvaro Herrera escreveu: > On 2021-Jul-02, Justin Pryzby wrote: > > > On Fri, Jul 02, 2021 at 12:09:23PM +0200, Peter Eisentraut wrote: > > > > The use of InvalidBlockNumber with vac_update_relstats() looks a bit > fishy > > > to me. We are using in the same

Back-branch commit complexity

2021-07-02 Thread Bruce Momjian
In my git workflow, I normally use scripts to simplify and check things. Previously, most of my workfload was on master, with patches migrated to appropriate back branches. FYI, now that we have the release notes only in the major version branches, I have had to adjust my scripts to allow for

Re: Signed vs. Unsigned (some)

2021-07-02 Thread Alvaro Herrera
On 2021-Jul-02, Justin Pryzby wrote: > On Fri, Jul 02, 2021 at 12:09:23PM +0200, Peter Eisentraut wrote: > > The use of InvalidBlockNumber with vac_update_relstats() looks a bit fishy > > to me. We are using in the same call 0 as the default for > > num_all_visible_pages, and we generally

Re: wrong relkind error messages

2021-07-02 Thread Alvaro Herrera
On 2021-Jun-24, Peter Eisentraut wrote: > There might be room for some wordsmithing in a few places, but generally I > think this is complete. This looks good to me. I am +0.1 on your proposal of "cannot have triggers" vs Michael's "cannot create triggers", but really I could go with either.

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Tom Lane
Alvaro Herrera writes: > Now it's hoverfly: > ! nm -A -u libpq.so.5 2>/dev/null | grep -v __cxa_atexit | grep exit > libpq.so.5: atexit U - > libpq.so.5: pthread_exit U - Ugh. What in the world is producing those references? (As I mentioned upthread,

Re: psql - factor out echo code

2021-07-02 Thread Tom Lane
Fabien COELHO writes: > [ psql-echo-2.patch ] I went to commit this, figuring that it was a trivial bit of code consolidation, but as I looked around in common.c I got rather unhappy with the inconsistent behavior of things. Examining the various places that implement "echo"-related logic, we

Re: Preventing abort() and exit() calls in libpq

2021-07-02 Thread Alvaro Herrera
Now it's hoverfly: ! nm -A -u libpq.so.5 2>/dev/null | grep -v __cxa_atexit | grep exit libpq.so.5: atexit U - libpq.so.5: pthread_exit U - https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly=2021-07-02%2010%3A10%3A29 -- Álvaro Herrera

Re: Detecting File Damage & Inconsistencies

2021-07-02 Thread Simon Riggs
On Fri, Jul 2, 2021 at 5:34 AM Craig Ringer wrote: > > On Fri, 2 Jul 2021 at 00:19, Simon Riggs wrote: > >> >> > So yeah. I think it'd be better to log the info you want at start-of-txn >> > unless there's a compelling reason not so, and I don't see one yet. >> >> AFAIK, XLOG_XACT_ASSIGNMENT

Re: Signed vs. Unsigned (some)

2021-07-02 Thread Justin Pryzby
On Fri, Jul 02, 2021 at 12:09:23PM +0200, Peter Eisentraut wrote: > On 16.06.21 10:48, Peter Eisentraut wrote: > > On 15.06.21 10:17, Kyotaro Horiguchi wrote: > > > The definitions are not ((type) -1) but ((type) 0x) so > > > actually they might be different if we forget to widen the

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

2021-07-02 Thread Robert Haas
On Wed, Jun 30, 2021 at 11:46 PM Greg Nancarrow wrote: > I personally think "(b) provide an option to the user to specify > whether inserts can be parallelized on a relation" is the preferable > option. > There seems to be too many issues with the alternative of trying to > determine the

Re: RFC: Logging plan of the running query

2021-07-02 Thread Bharath Rupireddy
On Tue, Jun 22, 2021 at 8:00 AM torikoshia wrote: > Updated the patch. Thanks for the patch. Here are some comments on the v4 patch: 1) Can we do + ExplainState *es = NewExplainState(); and es assignments after if (!ActivePortal || !ActivePortal->queryDesc), just to avoid unnecessary call in

Re: Commit fest manager

2021-07-02 Thread Ibrar Ahmed
On Fri, 2 Jul 2021 at 7:06 PM, vignesh C wrote: > On Fri, Jul 2, 2021 at 6:05 PM Ibrar Ahmed wrote: > > > > > > > > On Fri, 2 Jul 2021 at 1:47 PM, David Rowley > wrote: > >> > >> On Fri, 2 Jul 2021 at 15:04, vignesh C wrote: > >> > I'm interested in assisting Ibrar Ahmed. > >> > >> It might

Re: Commit fest manager

2021-07-02 Thread vignesh C
On Fri, Jul 2, 2021 at 6:05 PM Ibrar Ahmed wrote: > > > > On Fri, 2 Jul 2021 at 1:47 PM, David Rowley wrote: >> >> On Fri, 2 Jul 2021 at 15:04, vignesh C wrote: >> > I'm interested in assisting Ibrar Ahmed. >> >> It might be worth talking to Ibrar to see where you can lend a hand. I >> think in

Re: Mention --enable-tap-tests in the TAP section page

2021-07-02 Thread Andrew Dunstan
On 7/1/21 9:53 PM, Michael Paquier wrote: > On Thu, Jul 01, 2021 at 10:03:10AM -0400, Greg Sabino Mullane wrote: >> Searching about the TAP tests often leads to this page, but there is no >> easy link or mention of the fact that the sample invocations will not work >> without the special config

RE: ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

2021-07-02 Thread kuroda.hay...@fujitsu.com
Dear Hackers, I revised my patch. > Please also ensure that you're generating the patch against git HEAD. > The cfbot shows it as failing to apply, likely because you're looking > at something predating ad8305a43d1890768a613d3fb586b44f17360f29. Maybe there was something wrong with my local

Re: Replication protocol doc fix

2021-07-02 Thread Robert Haas
On Fri, Jul 2, 2021 at 1:55 AM Jeff Davis wrote: > On Wed, 2021-06-30 at 12:25 -0400, Robert Haas wrote: > > I am not sure whether this works or not. Holding off cancel > > interrupts > > across possible network I/O seems like a non-starter. We have to be > > able to kill off connections that

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

2021-07-02 Thread Laurenz Albe
On Fri, 2021-07-02 at 23:31 +1200, David Rowley wrote: > I had a look at the patch in [1] and I find it a bit weird that we'd > write the following about autovacuum_work_mem in our docs: > > + > +Note that VACUUM has a hard-coded limit of 1GB > +for the amount of memory

Re: Commit fest manager

2021-07-02 Thread Ibrar Ahmed
On Fri, 2 Jul 2021 at 1:47 PM, David Rowley wrote: > On Fri, 2 Jul 2021 at 15:04, vignesh C wrote: > > I'm interested in assisting Ibrar Ahmed. > > It might be worth talking to Ibrar to see where you can lend a hand. I > think in terms of the number of patches, this might be our biggest >

Re: Numeric multiplication overflow errors

2021-07-02 Thread David Rowley
On Fri, 2 Jul 2021 at 22:55, Dean Rasheed wrote: > Here's an update with the > last set of changes discussed. Looks good to me. Just the question of if we have any problems changing the serialized format in the back branches. I'm not sure if that's something we've done before. I only had a

Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

2021-07-02 Thread David Rowley
On Fri, 21 May 2021 at 03:52, Laurenz Albe wrote: > Just sending a reply to -hackers so I can add it to the commitfest. I had a look at the patch in [1] and I find it a bit weird that we'd write the following about autovacuum_work_mem in our docs: + +Note that VACUUM has a

Re: Schema variables - new implementation for Postgres 15

2021-07-02 Thread Pavel Stehule
so 12. 6. 2021 v 8:00 odesílatel Pavel Stehule napsal: > Hi > > rebase > > rebase only Regards Pavel Regards > > Pavel > schema-variables-20210702.patch.gz Description: application/gzip

Re: Signed vs. Unsigned (some)

2021-07-02 Thread Ranier Vilela
Em sex., 2 de jul. de 2021 às 07:09, Peter Eisentraut < peter.eisentr...@enterprisedb.com> escreveu: > On 16.06.21 10:48, Peter Eisentraut wrote: > > On 15.06.21 10:17, Kyotaro Horiguchi wrote: > >> The definitions are not ((type) -1) but ((type) 0x) so > >> actually they might be

Re: Numeric multiplication overflow errors

2021-07-02 Thread Dean Rasheed
On Fri, 2 Jul 2021 at 10:24, David Rowley wrote: > > I ran this again with a few different worker counts after tuning a few > memory settings so there was no spilling to disk and so everything was > in RAM. Mostly so I could get consistent results. > > Here's the results. Average over 3 runs on

Re: wrong relkind error messages

2021-07-02 Thread Peter Eisentraut
On 02.07.21 08:25, Michael Paquier wrote: + ereport(ERROR, + (errcode(ERRCODE_WRONG_OBJECT_TYPE), +errmsg("ALTER action %s cannot be performed on relation \"%s\"", + action_str, RelationGetRelationName(rel)), +

Re: Small clean up in nodeAgg.c

2021-07-02 Thread David Rowley
On Thu, 1 Jul 2021 at 11:09, Tom Lane wrote: > Just reading it over quickly, I noticed a comment mentioning > "aggcombinedfn" which I suppose should be "aggcombinefn". Thanks. I've fixed that locally. > No particular opinion on whether this is a net reduction > of logical complexity. I had

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

2021-07-02 Thread tanghy.f...@fujitsu.com
On Thursday, July 1, 2021 11:48 AM Ajin Cherian > > Adding a new patch (0004) to this patch-set that handles skipping of > empty streamed transactions. patch-0003 did not > handle empty streamed transactions. To support this, added a new flag > "sent_stream_start" to PGOutputTxnData. > Also

Re: Signed vs. Unsigned (some)

2021-07-02 Thread Peter Eisentraut
On 16.06.21 10:48, Peter Eisentraut wrote: On 15.06.21 10:17, Kyotaro Horiguchi wrote: The definitions are not ((type) -1) but ((type) 0x) so actually they might be different if we forget to widen the constant when widening the types.  Regarding to the compiler behavior, I think we are

Re: Added schema level support for publication.

2021-07-02 Thread vignesh C
On Fri, Jul 2, 2021 at 10:18 AM tanghy.f...@fujitsu.com wrote: > > On Wednesday, June 30, 2021 7:43 PM vignesh C wrote: > > > > Thanks for reporting this issue, the attached v9 patch fixes this issue. > > This also fixes the other issue you reported at [1]. > > A comment on v9: > >

Re: Numeric multiplication overflow errors

2021-07-02 Thread David Rowley
On Fri, 2 Jul 2021 at 00:28, Dean Rasheed wrote: > > On Thu, 1 Jul 2021 at 06:43, David Rowley wrote: > > > > Master @ 3788c6678 > > > > Execution Time: 8306.319 ms > > Execution Time: 8407.785 ms > > Execution Time: 8491.056 ms > > > > Master + numeric-agg-sumX2-overflow-v2.patch > > Execution

Re: Commit fest manager

2021-07-02 Thread David Rowley
On Fri, 2 Jul 2021 at 15:04, vignesh C wrote: > I'm interested in assisting Ibrar Ahmed. It might be worth talking to Ibrar to see where you can lend a hand. I think in terms of the number of patches, this might be our biggest commitfest yet. 2020-07 246 2020-09 235 2020-11 244 2021-01 260

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

2021-07-02 Thread David Rowley
On Fri, 2 Jul 2021 at 19:54, Ronan Dunklau wrote: > I don't know if it's acceptable, but in the case where you add both an > aggregate with an ORDER BY clause, and another aggregate without the clause, > the output for the unordered one will change and use the same ordering, maybe > suprising the

Re: rand48 replacement

2021-07-02 Thread Dean Rasheed
On Thu, 1 Jul 2021 at 22:18, Fabien COELHO wrote: > > > However, this patch seems to be replacing that with a simple > > modulo operation, which is perhaps the worst possible way to do it. > > The modulo operation is biased for large ranges close to the limit, sure. > Also, the bias is somehow of

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

2021-07-02 Thread Ronan Dunklau
> > This allows us to give presorted input to both aggregates in the following > case: > > SELECT agg(a ORDER BY a),agg2(a ORDER BY a,b) ... > > but just the first agg in this one: > > SELECT agg(a ORDER BY a),agg2(a ORDER BY c) ... I don't know if it's acceptable, but in the case where you

Re: Teach pg_receivewal to use lz4 compression

2021-07-02 Thread gkokolatos
‐‐‐ Original Message ‐‐‐ On Friday, July 2nd, 2021 at 03:10, Michael Paquier wrote: > On Thu, Jul 01, 2021 at 02:10:17PM +, gkokola...@pm.me wrote: > > > Micheal suggested on the same thread to move my entry in the help output so > > that > > > > the output remains ordered. I

Re: row filtering for logical replication

2021-07-02 Thread Peter Smith
Hi. I have been looking at the latest patch set (v16). Below are my review comments and some patches. The patches are: v16-0001. This is identical to your previously posted 0001 patch. (I only attached it again hoping it can allow the cfbot to keep working OK). v16-0002,0003. These are for

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

2021-07-02 Thread Amit Kapila
On Fri, Jul 2, 2021 at 8:35 AM Alvaro Herrera wrote: > > > The latest patch sent by Bharath looks good to me. Would you like to > > commit it or shall I take care of it? > > Please, go ahead. > Okay, I'll push it early next week (by Tuesday) unless there are more comments or suggestions. Thanks!

Re: Add option --drop-cascade for pg_dump/restore

2021-07-02 Thread Haotian Wu
Hi, I agree that —drop-cascade does not make sense for pg_dumpall, so I removed them. > are we expecting more things to appear after the semi-colon? No, I was just trying to “reuse” original statement as much as possible. Append “\n” manually should also do the job, and I’ve updated the

Re: Synchronous commit behavior during network outage

2021-07-02 Thread Andrey Borodin
> 2 июля 2021 г., в 10:59, Jeff Davis написал(а): > > On Wed, 2021-06-30 at 17:28 +0500, Andrey Borodin wrote: >>> My patch also covers the backend termination case. Is there a >>> reason >>> you left that case out? >> >> Yes, backend termination is used by HA tool before rewinding the >>

Re: Logical replication - schema change not invalidating the relation cache

2021-07-02 Thread Dilip Kumar
On Fri, Jul 2, 2021 at 11:11 AM vignesh C wrote: > > Hi, > > I found a strange behavior when there is an insert after renaming the > schema. The test steps for the same are given below, Here after the > schema is renamed, the renamed schema table data should not be sent, > but the data was being

Re: Can a child process detect postmaster death when in pg_usleep?

2021-07-02 Thread Bharath Rupireddy
On Fri, Jul 2, 2021 at 9:53 AM Michael Paquier wrote: > > On Mon, Jun 28, 2021 at 08:21:06PM +0530, Bharath Rupireddy wrote: > > The recoveryWakeupLatch and procLatch/MyLatch are being used for WAL > > replay and recovery conflict, respectively. Actually, I was earlier > > using

Re: wrong relkind error messages

2021-07-02 Thread Michael Paquier
On Thu, Jun 24, 2021 at 10:12:49AM +0200, Peter Eisentraut wrote: > There might be room for some wordsmithing in a few places, but generally I > think this is complete. I have been looking at that, and it seems to me that you nailed it. That's a nice improvement compared to the existing error

Re: Synchronous commit behavior during network outage

2021-07-02 Thread Jeff Davis
On Wed, 2021-06-30 at 17:28 +0500, Andrey Borodin wrote: > > My patch also covers the backend termination case. Is there a > > reason > > you left that case out? > > Yes, backend termination is used by HA tool before rewinding the > node. Can't you just disable sync rep first (using ALTER SYSTEM