Re: Logical replication keepalive flood

On Thu, Jun 10, 2021 at 11:42 AM Kyotaro Horiguchi wrote: > > At Thu, 10 Jun 2021 15:00:16 +0900 (JST), Kyotaro Horiguchi > wrote in > > At Wed, 9 Jun 2021 17:32:25 +0500, Abbas Butt > > wrote in > > > > > > On Wed, Jun 9, 2021 at 2:30 PM Amit Kapila > > > wrote: > > > > Is it possible that

Re: Logical replication keepalive flood

At Thu, 10 Jun 2021 15:00:16 +0900 (JST), Kyotaro Horiguchi wrote in > At Wed, 9 Jun 2021 17:32:25 +0500, Abbas Butt > wrote in > > > > On Wed, Jun 9, 2021 at 2:30 PM Amit Kapila wrote: > > > Is it possible that the write/flush location is not > > > updated at the pace at which we expect? >

Re: Logical replication keepalive flood

At Wed, 9 Jun 2021 17:32:25 +0500, Abbas Butt wrote in > > On Wed, Jun 9, 2021 at 2:30 PM Amit Kapila wrote: > > Does these keepalive messages are sent at the same frequency even for > > subscribers? > > Yes, I have tested it with one publisher and one subscriber. > The moment I start pgbench

Re: BF assertion failure on mandrill in walsender, v13

On Thu, Jun 10, 2021 at 10:47:20AM +1200, Thomas Munro wrote: > Not sure if there is much chance of debugging this one-off failure in > without a backtrace (long shot: any chance there's still a core > file?) No; it was probably in a directory deleted for each run. One would need to add dbx suppo

Re: Parallel INSERT SELECT take 2

On Thu, Jun 10, 2021 at 11:26 AM houzj.f...@fujitsu.com wrote: > > Through further review and thanks for greg-san's suggestions, > I attached a new version patchset with some minor change in 0001,0003 and > 0004. > > 0001. > * fix a typo in variable name. > * add a TODO in patch comment about upd

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

On Wed, Jun 9, 2021 at 9:47 PM Robert Haas wrote: > > On Wed, Jun 9, 2021 at 2:43 AM Tom Lane wrote: > > There are specific cases where there's a good reason to worry. > > For example, if we assume blindly that domain_in() is parallel > > safe, we will have cause to regret that. But I don't find

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

On Thursday, June 10, 2021 1:14 PM vignesh C > On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com > wrote: > > > > On Wednesday, June 9, 2021 12:06 PM Amit Kapila > wrote: > > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote: > > > > > > > > Thanks for the updated patch. > > > > > > >

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

On Thu, Jun 10, 2021 at 09:17:55AM +0530, Bharath Rupireddy wrote: > Hm. I get it. Unfortunately the commit b1ff33f is missing information > on what the coverity tool was complaining of and it has no related > discussion at all. This came from a FORWARD_NULL complain, due to the fact that parse_su

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

On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com wrote: > > On Wednesday, June 9, 2021 12:06 PM Amit Kapila > wrote: > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote: > > > > > > Thanks for the updated patch. > > > > > > I have few comments: > > > 1) Should we list the actual syste

Re: logical replication of truncate command with trigger causes Assert

On Wed, Jun 9, 2021 at 8:44 PM Mark Dilger wrote: > > > On Jun 9, 2021, at 7:52 AM, Tom Lane wrote: > > > > Here's a draft patch for that. I decided the most sensible way to > > organize this is to pair the existing ensure_transaction() subroutine > > with a cleanup subroutine. Rather unimagina

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

On Thu, Jun 10, 2021 at 8:55 AM Peter Smith wrote: > > > 2. > > > + /* If connect option is supported, the others also need to be. */ > > > + Assert(!IsSet(supported_opts, SUBOPT_CONNECT) || > > > +(IsSet(supported_opts, SUBOPT_ENABLED) && > > > + IsSet(supported_opts, SUBOPT_CREATE_SLOT) && >

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

On Thu, Jun 10, 2021 at 1:28 AM Bharath Rupireddy wrote: > > On Wed, Jun 9, 2021 at 10:37 AM Peter Smith wrote: > > [...] I checked the v4* patches. Everything applies and builds and tests OK for me. > > 2. > > + /* If connect option is supported, the others also need to be. */ > > + Assert(!Is

Re: Multiple hosts in connection string failed to failover in non-hot standby mode

Michael Paquier writes: > On Wed, Jun 09, 2021 at 12:05:10PM -0400, Tom Lane wrote: >> Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression, > Using ecpg2_regression for the role goes a bit against the recent rule > to not create any role not suffixed by "regress_" as part of

Re: Patch: Range Merge Join

On Thu, 10 Jun 2021 at 03:05, Thomas wrote: > We have implemented the Range Merge Join algorithm by extending the > existing Merge Join to also support range conditions, i.e., BETWEEN-AND > or @> (containment for range types). It shouldn't be a blocker for you, but just so you're aware, there was

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

On Thu, Jun 10, 2021 at 4:13 AM Jeff Davis wrote: > > On Wed, 2021-06-09 at 17:27 +0530, Amit Kapila wrote: > > 2. In the main patch [1], we do send two_phase option even during > > START_REPLICATION for the very first time when the two_phase can be > > enabled. There are reasons as described in t

Re: alter table set TABLE ACCESS METHOD

On Wed, Jun 09, 2021 at 01:45:52PM -0700, Zhihong Yu wrote: > + /* check if another access method change was already requested > */ > + if (tab->newAccessMethod) > + ereport(ERROR, > + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > +

Re: alter table set TABLE ACCESS METHOD

On Wed, Jun 09, 2021 at 01:47:18PM +0900, Michael Paquier wrote: > On Tue, Jun 08, 2021 at 05:33:31PM -0700, Jeff Davis wrote: > > New version attached, with the detoasting code removed. Could use > > another round of validation/cleanup in case I missed something during > > the merge. > > This loo

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

On Tue, Jun 08, 2021 at 11:32:21PM -0400, Tom Lane wrote: > I can imagine sometime in the future where we need to get rid of all > instances of pglz so we can reassign that compression code to something > else. But would we insist on a mass VACUUM FULL to make that happen? > Doubt it. You'd want

Re: RFC: Logging plan of the running query

On 2021-06-09 23:04, Fujii Masao wrote: Thanks for your review! auto_explain can log the plan of even nested statement if auto_explain.log_nested_statements is enabled. But ISTM that pg_log_current_plan() cannot log that plan. Is this intentional? I think that it's better to make pg_log_curr

Re: Transactions involving multiple postgres foreign servers, take 2

At Tue, 8 Jun 2021 08:45:24 +, "tsunakawa.ta...@fujitsu.com" wrote in > From: Kyotaro Horiguchi > > I think the discussion is based the behavior that any process that is > > responsible for finishing the 2pc-commit continue retrying remote > > commits until all of the remote-commits succeed

Re: alter table set TABLE ACCESS METHOD

On Wed, Jun 09, 2021 at 01:45:52PM -0700, Zhihong Yu wrote: > + /* check if another access method change was already requested > */ > + if (tab->newAccessMethod) > + ereport(ERROR, > + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > +

Re: please update ps display for recovery checkpoint

On Sun, Jun 06, 2021 at 09:13:48PM -0500, Justin Pryzby wrote: > Putting this into fd.c seems to assume that we can clobber "ps", which is fine > when called by StartupXLOG(), but it's a public interface, so I'm not sure if > it's okay to assume that's the only caller. Maybe it should check if > M

Re: please update ps display for recovery checkpoint

On Mon, Jun 07, 2021 at 01:28:06PM -0400, Robert Haas wrote: > On Mon, Jun 7, 2021 at 12:02 PM Bossart, Nathan wrote: >> I've seen a few functions cause lengthy startups, including >> SyncDataDirectory() (for which I was grateful to see 61752afb), >> StartupReorderBuffer(), and RemovePgTempFiles()

a path towards replacing GEQO with something better

Hi, On occasion it comes up that the genetic query optimizer (GEQO) doesn't produce particularly great plans, and is slow ([1] for example). The only alternative that has gotten as far as a prototype patch (as far as I know) is simulated annealing some years ago, which didn't seem to get far. The

Re: Race condition in recovery?

At Wed, 09 Jun 2021 19:09:54 -0400, Tom Lane wrote in > Robert Haas writes: > > Got it. I have now committed the patch to all branches, after adapting > > your changes just a little bit. > > Thanks to you and Kyotaro-san for all the time spent on this. What a slog! > > conchuela failed its firs

Re: Multiple hosts in connection string failed to failover in non-hot standby mode

On Wed, Jun 09, 2021 at 12:05:10PM -0400, Tom Lane wrote: > Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression, > which matches the name of one of the databases used, allowing the test > cases with defaulted database name to succeed. That gets rid of one of > the problematic

Re: Race condition in recovery?

Robert Haas writes: > Got it. I have now committed the patch to all branches, after adapting > your changes just a little bit. > Thanks to you and Kyotaro-san for all the time spent on this. What a slog! conchuela failed its first encounter with this test case: https://buildfarm.postgresql.org/c

Re: unnesting multirange data types

On 6/9/21 4:56 PM, Alvaro Herrera wrote: > On 2021-Jun-09, Jonathan S. Katz wrote: > >> I did a couple more tests around this. >> >> As suspected, in PL/pgSQL, there is no way to unpack or iterate over a >> multirange type. > > Uh. This is disappointing; the need for some way to unnest or unpack

Re: Estimating HugePages Requirements?

> On Jun 9, 2021, at 1:52 PM, Bossart, Nathan wrote: > > I'd be happy to clean it up and submit it for > discussion in pgsql-hackers@ if there is interest. Yes, I'd like to see it. Thanks for offering. — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

BF assertion failure on mandrill in walsender, v13

Hi, Not sure if there is much chance of debugging this one-off failure in without a backtrace (long shot: any chance there's still a core file?), but for the record: mandrill choked on a null pointer passed to GetMemoryChunkContext() inside a walsender running logical replication. Possibly via pf

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

Jeff Davis writes: > On Wed, 2021-06-09 at 16:50 +0530, Amit Kapila wrote: >> BTW, can't we consider it to be part of >> create_slot_opt_list? > Yes, that would be better. It looks like the physical and logical slot > options are mixed together -- should they be separated in the grammar > so that

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

On Wed, 2021-06-09 at 17:27 +0530, Amit Kapila wrote: > 2. In the main patch [1], we do send two_phase option even during > START_REPLICATION for the very first time when the two_phase can be > enabled. There are reasons as described in the worker.c why we can't > enable it during CREATE_REPLICATIO

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

On Wed, 2021-06-09 at 16:50 +0530, Amit Kapila wrote: > BTW, can't we consider it to be part of > create_slot_opt_list? Yes, that would be better. It looks like the physical and logical slot options are mixed together -- should they be separated in the grammar so that using an option with the wron

Re: Race condition in recovery?

On Wed, Jun 9, 2021 at 4:07 AM Dilip Kumar wrote: > Reason for the problem was that the "-Xnone" parameter was not > accepted by "sub backup" in PostgresNode.pm so I created that for > backpatch. With attached patches I am to make it pass in v12,v11,v10 > (with fix) and fail (without fix). Howev

Re: unnesting multirange data types

On 2021-Jun-09, Jonathan S. Katz wrote: > I did a couple more tests around this. > > As suspected, in PL/pgSQL, there is no way to unpack or iterate over a > multirange type. Uh. This is disappointing; the need for some way to unnest or unpack a multirange was mentioned multiple times in the ra

Re: pg_stat_progress_create_index vs. parallel index builds

On 2021-Jun-04, Greg Nancarrow wrote: > I tested with and without the patch, using the latest PG14 source as > of today, and can confirm that without the patch applied, the "sorting > live tuples" phase is not reported in the parallel-case, but with the > patch applied it then does get reported in

Re: Estimating HugePages Requirements?

moving to pgsql-hackers@ On 6/9/21, 9:41 AM, "Don Seiler" wrote: > I'm trying to set up a chef recipe to reserve enough HugePages on a > linux system for our PG servers. A given VM will only host one PG > cluster and that will be the only thing on that host that uses > HugePages. Blogs that I've

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Wed, Jun 9, 2021 at 11:45 AM Andres Freund wrote: > Good find! +1 > > The attached patch fixes this inconsistency > > I think I prefer applying the fix and the larger changes separately. I wonder if it's worth making the goto inside lazy_scan_prune verify that the heap tuple matches what we

Re: alter table set TABLE ACCESS METHOD

On Wed, Jun 9, 2021 at 12:31 PM Jeff Davis wrote: > On Wed, 2021-06-09 at 13:47 +0900, Michael Paquier wrote: > > There is a mix of upper and lower-case characters here. It could be > > more consistent. It seems to me that this test should actually check > > that pg_class.relam reflects the new

Re: Adjust pg_regress output for new long test names

On Wed, Jun 9, 2021 at 1:37 PM Peter Eisentraut wrote: > Can we scan all the test names first and then pick a suitable length? FWIW, I think this discussion of shortening the test case names is probably going in the wrong direction. It's true that in many cases such a thing can be done, but it's

Re: unnesting multirange data types

On 6/9/21 3:44 PM, Jonathan S. Katz wrote: > On 6/9/21 3:25 PM, Tom Lane wrote: >> "Jonathan S. Katz" writes: >>> I would like to decompose the returned multirange into its individual >>> ranges, similarly to how I would "unnest" an array: >> >> +1 for adding such a feature, but I suppose it's too

Re: unnesting multirange data types

On 6/9/21 3:25 PM, Tom Lane wrote: > "Jonathan S. Katz" writes: >> I would like to decompose the returned multirange into its individual >> ranges, similarly to how I would "unnest" an array: > > +1 for adding such a feature, but I suppose it's too late for v14. Well, the case I would make for v

Re: Add PortalDrop in exec_execute_message

On 2021-Jun-09, Tom Lane wrote: > I wrote: > > It turns out that the problem is specific to SELECT FOR UPDATE, and > > it happens because nodeLockRows is not careful to shut down the > > EvalPlanQual mechanism it uses before returning NULL at the end of > > a scan. If EPQ has been fired, it'll be

Re: alter table set TABLE ACCESS METHOD

On Wed, 2021-06-09 at 13:47 +0900, Michael Paquier wrote: > There is a mix of upper and lower-case characters here. It could be > more consistent. It seems to me that this test should actually check > that pg_class.relam reflects the new value. Done. I also added a (negative) test for changing t

Re: unnesting multirange data types

"Jonathan S. Katz" writes: > I would like to decompose the returned multirange into its individual > ranges, similarly to how I would "unnest" an array: +1 for adding such a feature, but I suppose it's too late for v14. AFAICS, "unnest(anymultirange) returns setof anyrange" could coexist alongsi

Re: Add PortalDrop in exec_execute_message

I wrote: > It turns out that the problem is specific to SELECT FOR UPDATE, and > it happens because nodeLockRows is not careful to shut down the > EvalPlanQual mechanism it uses before returning NULL at the end of > a scan. If EPQ has been fired, it'll be holding a tuple slot > referencing whateve

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

Hi, Good find! On 2021-06-09 17:42:34 +0200, Matthias van de Meent wrote: > I believe that I've found the culprit: > GetOldestNonRemovableTransactionId(rel) does not use the exact same > conditions for returning OldestXmin as GlobalVisTestFor(rel) does. > This results in different minimal XIDs, a

unnesting multirange data types

Hi, I have been exploring multirange data types using PostgreSQL 14 Beta 1. Thus far I'm really happy with the user experience, and it has allowed me to simplify some previously onerous queries! I do have a question about trying to "unnest" a multirange type into its individual ranges. For exampl

Re: Character expansion with ICU collations

Peter Eisentraut writes: > You can have these queries return both rows if you use an > accent-ignoring collation, like this example in the documentation: > CREATE COLLATION ignore_accents (provider = icu, locale = > 'und-u-ks-level1-kc-true', deterministic = false); It occurs to me to wonder w

Re: Character expansion with ICU collations

On 09.06.21 17:31, Finnerty, Jim wrote: CREATE COLLATION CI_AS (provider = icu, locale=’utf8@colStrength=secondary’, deterministic = false); CREATE TABLE MyTable3 (     ID INT IDENTITY(1, 1), Comments VARCHAR(100) ) INSERT INTO MyTable3 (Comments) VALUES ('strasse') INSERT INTO MyTable

Re: Adjust pg_regress output for new long test names

On 09.06.21 03:57, Thomas Munro wrote: test deadlock-simple ... ok 20 ms test deadlock-hard... ok10624 ms test deadlock-soft... ok 147 ms test deadlock-soft-2 ... ok 5154 ms test deadlock-parallel

Re: Adjust pg_regress output for new long test names

On 09.06.21 04:51, Noah Misch wrote: On Wed, Jun 09, 2021 at 01:57:45PM +1200, Thomas Munro wrote: test deadlock-simple ... ok 20 ms test deadlock-hard... ok10624 ms test deadlock-soft... ok 147 ms test deadlock-soft-2

Re: Add PortalDrop in exec_execute_message

I wrote: > I'm still wondering though why Yura is observing resources remaining > held by an executed-to-completion Portal. I think investigating that > might be more useful than tinkering with pipeline mode. I got a chance to look into this finally. The lens I've been looking at this through is

Re: Race condition in recovery?

On Wed, Jun 9, 2021 at 4:07 AM Dilip Kumar wrote: > Reason for the problem was that the "-Xnone" parameter was not > accepted by "sub backup" in PostgresNode.pm so I created that for > backpatch. With attached patches I am to make it pass in v12,v11,v10 > (with fix) and fail (without fix). Howev

Re: when the startup process doesn't

On Wed, Jun 09, 2021 at 05:09:54PM +0530, Nitin Jadhav wrote: > > + {"log_min_duration_startup_process", PGC_SUSET, > > LOGGING_WHEN, > > > > I think it should be PGC_SIGHUP, to allow changing it during runtime. > > Obviously it has no effect except during startup, but the change wil

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

On Wed, Jun 9, 2021 at 2:43 AM Tom Lane wrote: > There are specific cases where there's a good reason to worry. > For example, if we assume blindly that domain_in() is parallel > safe, we will have cause to regret that. But I don't find that > to be a reason why we need to lock down everything ev

Re: Multiple hosts in connection string failed to failover in non-hot standby mode

I wrote: > ... I'd be okay with dropping that test; or maybe we could > fix things so that the default case succeeds? Here's a draft patch that renames regress_ecpg_user2 to ecpg2_regression, which matches the name of one of the databases used, allowing the test cases with defaulted database name

Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Wed, 9 Jun 2021 at 04:42, Michael Paquier wrote: > > On Tue, Jun 08, 2021 at 05:47:28PM -0700, Peter Geoghegan wrote: > > I don't have time to try this out myself today, but offhand I'm pretty > > confident that this is sufficient to reproduce the underlying bug > > itself. And if that's true t

Re: Decoding speculative insert with toast leaks memory

May I suggest to use a different name in the blurt_and_lock_123() function, so that it doesn't conflict with the one in insert-conflict-specconflict? Thanks -- Álvaro Herrera39°49'30"S 73°17'W

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

On Wed, Jun 9, 2021 at 10:37 AM Peter Smith wrote: > > On Wed, Jun 2, 2021 at 10:41 PM Bharath Rupireddy > wrote: > > > > 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 (su

Re: logical replication of truncate command with trigger causes Assert

Mark Dilger writes: >> On Jun 9, 2021, at 7:52 AM, Tom Lane wrote: >> Somewhat unrelated, but ... am I reading the code correctly that >> apply_handle_stream_start and related routines are using Asserts >> to check that the remote sent stream-control messages in the correct >> order? That seems

Re: logical replication of truncate command with trigger causes Assert

> On Jun 9, 2021, at 7:52 AM, Tom Lane wrote: > > Here's a draft patch for that. I decided the most sensible way to > organize this is to pair the existing ensure_transaction() subroutine > with a cleanup subroutine. Rather unimaginatively, perhaps, I renamed > it to begin_transaction_step a

Re: logical replication of truncate command with trigger causes Assert

Amit Kapila writes: > On Wed, Jun 9, 2021 at 5:29 AM Tom Lane wrote: >> 2. Decide that we ought to ensure that a snapshot exists throughout >> most of this code. It's not entirely obvious to me that there is no >> code path reachable from, say, apply_handle_truncate's collection of >> relation O

Re: How to pass a parameter in a query to postgreSQL 11 (offtopic)

On Wed, Jun 09, 2021 at 05:30:15AM -0500, Hassan Camacho Cadre wrote: > I recently migrated from version 8.3 of postgreSQL to v11, previously in > all my queries for passing parameters I used the character : > Example > Where id =: searched I guess you migrated to a whole new environment, with man

Re: DELETE CASCADE

On Wed, Jun 9, 2021 at 8:48 AM David G. Johnston wrote: > On Wednesday, June 9, 2021, Peter Eisentraut < > peter.eisentr...@enterprisedb.com> wrote: > >> >> It might work, I'm just saying it needs to be thought about carefully. If >> you have functionality like, delete this if there is no matchin

Re: Fdw batch insert error out when set batch_size > 65535

On 6/9/21 3:28 PM, Tom Lane wrote: Tomas Vondra writes: Note that the problem here is [1] - we're creating a lot of slots referencing the same tuple descriptor, which inflates the duration. There's a fix in the other thread, which eliminates ~99% of the overhead. I plan to push that fix soon (a

Re: RFC: Logging plan of the running query

On 2021/06/09 16:44, torikoshia wrote: Updated the patch. Thanks for updating the patch! auto_explain can log the plan of even nested statement if auto_explain.log_nested_statements is enabled. But ISTM that pg_log_current_plan() cannot log that plan. Is this intentional? I think that it's

Re: Fix dropped object handling in pg_event_trigger_ddl_commands

On 2021-Jun-09, Michael Paquier wrote: > On Mon, Jun 07, 2021 at 12:44:42PM +0300, Aleksander Alekseev wrote: > > I confirm that the bug still exists in master (be57f216). The patch > > fixes it and looks good to me. I changed the wording a little and > > added a regression test. The updated patch

Re: DELETE CASCADE

On Wednesday, June 9, 2021, Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > > It might work, I'm just saying it needs to be thought about carefully. If > you have functionality like, delete this if there is no matching record > over there, you need to have the permission to check th

Re: Decoding speculative insert with toast leaks memory

On Wed, Jun 9, 2021 at 4:22 PM Amit Kapila wrote: > On Wed, Jun 9, 2021 at 4:12 PM Dilip Kumar wrote: > >> Few comments: > >> 1. The test has a lot of similarities and test duplication with what > >> we are doing in insert-conflict-specconflict.spec. Can we move it to > >> insert-conflict-specco

Re: Adjust pg_regress output for new long test names

On 2021-Jun-08, Noah Misch wrote: > On Wed, Jun 09, 2021 at 03:21:36PM +1200, Thomas Munro wrote: > > On Wed, Jun 9, 2021 at 2:44 PM Tom Lane wrote: > > > ... or we could shorten those file names. I recall an episode > > > awhile ago where somebody complained that their version of "tar" > > > co

Re: Fdw batch insert error out when set batch_size > 65535

Tomas Vondra writes: > Note that the problem here is [1] - we're creating a lot of slots > referencing the same tuple descriptor, which inflates the duration. > There's a fix in the other thread, which eliminates ~99% of the > overhead. I plan to push that fix soon (a day or two). Oh, okay, as

Re: Logical replication keepalive flood

Hi, On Wed, Jun 9, 2021 at 2:30 PM Amit Kapila wrote: > On Wed, Jun 9, 2021 at 1:47 PM Kyotaro Horiguchi > wrote: > > > > At Wed, 9 Jun 2021 11:21:55 +0900, Kyotaro Horiguchi < > horikyota@gmail.com> wrote in > > > The issue - if actually it is - we send a keep-alive packet before a > > > q

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

On Wed, Jun 9, 2021 at 4:50 PM Amit Kapila wrote: > > On Wed, Jun 9, 2021 at 1:53 AM Jeff Davis wrote: > > > > On Tue, 2021-06-08 at 17:41 +1000, Ajin Cherian wrote: > > > Here's an updated patchset that adds back in the option for two-phase > > > in CREATE_REPLICATION_SLOT command and a second p

Case expression pushdown

Hi. This patch allows pushing case expressions to foreign servers, so that more types of updates could be executed directly. For example, without patch: EXPLAIN (VERBOSE, COSTS OFF) UPDATE ft2 d SET c2 = CASE WHEN c2 > 0 THEN c2 ELSE 0 END WHERE c1 > 1000;

Re: when the startup process doesn't

> Should it show the rusage ? It's shown at startup completion since 10a5b35a0, > so it seems strange not to show it here. > I don't know, that seems like it's going to make the messages awfully > long, and I'm not sure of what use it is to see that for every report. I have not changed anything

Re: postgres_fdw batching vs. (re)creating the tuple slots

On Wed, Jun 9, 2021 at 4:38 PM Tomas Vondra wrote: > > On 6/9/21 12:50 PM, Bharath Rupireddy wrote: > > On Wed, Jun 9, 2021 at 4:00 PM Tomas Vondra > > wrote: > >> > >> Hi, > >> > >> Here's a v2 fixing a silly bug with reusing the same variable in two > >> nested loops (worked for simple postgres

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

On Wed, Jun 9, 2021 at 1:53 AM Jeff Davis wrote: > > On Tue, 2021-06-08 at 17:41 +1000, Ajin Cherian wrote: > > Here's an updated patchset that adds back in the option for two-phase > > in CREATE_REPLICATION_SLOT command and a second patch that adds > > support for > > two-phase decoding in pg_rec

Re: postgres_fdw batching vs. (re)creating the tuple slots

On 6/9/21 12:50 PM, Bharath Rupireddy wrote: On Wed, Jun 9, 2021 at 4:00 PM Tomas Vondra wrote: Hi, Here's a v2 fixing a silly bug with reusing the same variable in two nested loops (worked for simple postgres_fdw cases, but "make check" failed). I applied these patches and ran make check

Re: speed up verifying UTF-8

On 07/06/2021 15:39, John Naylor wrote: On Mon, Jun 7, 2021 at 8:24 AM Heikki Linnakangas > wrote: > > On 03/06/2021 21:58, John Naylor wrote: > > The microbenchmark is the same one you attached to [1], which I extended > > with a 95% multibyte case. > > Could you

Re: Decoding speculative insert with toast leaks memory

On Wed, Jun 9, 2021 at 4:12 PM Dilip Kumar wrote: > > On Wed, Jun 9, 2021 at 11:03 AM Amit Kapila wrote: >> >> On Tue, Jun 8, 2021 at 5:16 PM Dilip Kumar wrote: >> > >> > Based on the off list discussion, I have modified the test based on >> > the idea showed in >> > "isolation/specs/insert-conf

Re: postgres_fdw batching vs. (re)creating the tuple slots

On Wed, Jun 9, 2021 at 4:00 PM Tomas Vondra wrote: > > Hi, > > Here's a v2 fixing a silly bug with reusing the same variable in two > nested loops (worked for simple postgres_fdw cases, but "make check" > failed). I applied these patches and ran make check in postgres_fdw contrib module, I saw a

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

On Wed, Jun 9, 2021 at 6:23 AM Jeff Davis wrote: > > On Tue, 2021-06-08 at 17:41 +1000, Ajin Cherian wrote: > > Here's an updated patchset that adds back in the option for two-phase > > in CREATE_REPLICATION_SLOT command and a second patch that adds > > support for > > two-phase decoding in pg_rec

Re: Decoding speculative insert with toast leaks memory

On Wed, Jun 9, 2021 at 11:03 AM Amit Kapila wrote: > On Tue, Jun 8, 2021 at 5:16 PM Dilip Kumar wrote: > > > > Based on the off list discussion, I have modified the test based on > > the idea showed in > > "isolation/specs/insert-conflict-specconflict.spec", other open point > > we had about the

How to pass a parameter in a query to postgreSQL 11

Hello I recently migrated from version 8.3 of postgreSQL to v11, previously in all my queries for passing parameters I used the character : Example Where id =: searched In the new version when I try to make this query it sends me an error ERROR syntax error at or near ":" Could someone help me

Re: postgres_fdw batching vs. (re)creating the tuple slots

Hi, Here's a v2 fixing a silly bug with reusing the same variable in two nested loops (worked for simple postgres_fdw cases, but "make check" failed). regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company >From 494018fd3f2b983be474a85fc12fe3a4dbe

Re: Fdw batch insert error out when set batch_size > 65535

On 6/9/21 12:22 PM, Tomas Vondra wrote: On 6/9/21 8:28 AM, Tom Lane wrote: I wrote: Bharath Rupireddy writes: I've added a simple regression test to postgres_fdw, testing that batch sizes > 65535 work fine, and pushed the fix. I was earlier thinking of adding one, but stopped because

Re: Fdw batch insert error out when set batch_size > 65535

On 6/9/21 8:28 AM, Tom Lane wrote: I wrote: Bharath Rupireddy writes: I've added a simple regression test to postgres_fdw, testing that batch sizes > 65535 work fine, and pushed the fix. I was earlier thinking of adding one, but stopped because it might increase the regression test execu

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

On Tuesday, June 8, 2021 5:04 PM I wrote: > On Monday, June 7, 2021 6:22 PM Amit Kapila > wrote: > > On Mon, Jun 7, 2021 at 10:44 AM Amit Kapila > > wrote: > > > > > > One more comment is that for HEAD, first just create a patch with > > > synchronous replication-related doc changes and then writ

Re: Race condition in recovery?

On Wed, Jun 9, 2021 at 1:37 PM Dilip Kumar wrote: > > On Wed, Jun 9, 2021 at 12:14 PM Dilip Kumar wrote: > > > > On Wed, Jun 9, 2021 at 2:07 AM Robert Haas wrote: > > 2021-06-09 12:11:08.618 IST [122456] LOG: entering standby mode > > 2021-06-09 12:11:08.622 IST [122456] LOG: restored log file

Re: Logical replication keepalive flood

On Wed, Jun 9, 2021 at 1:47 PM Kyotaro Horiguchi wrote: > > At Wed, 9 Jun 2021 11:21:55 +0900, Kyotaro Horiguchi > wrote in > > The issue - if actually it is - we send a keep-alive packet before a > > quite short sleep. > > > > We really want to send it if the sleep gets long but we cannot predi

Re: Duplicate history file?

At Wed, 09 Jun 2021 16:56:14 +0900, Tatsuro Yamada wrote in > Hi, > > On 2021/06/09 16:23, Fujii Masao wrote: > > On 2021/06/09 15:58, Tatsuro Yamada wrote: > >> This may not be important at this time since it is a > >> PoC patch, but I would like to inform you that there > >> was a line that c

Re: logical replication of truncate command with trigger causes Assert

On Wed, Jun 9, 2021 at 5:29 AM Tom Lane wrote: > > Mark Dilger writes: > > On Jun 8, 2021, at 3:55 PM, Tom Lane wrote: > >> I suppose that either apply_dispatch or LogicalRepApplyLoop needs to > >> grow some more snapshot management logic, but I've not looked at that > >> code much, so I don't h

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

On Wed, Jun 9, 2021 at 12:03 PM osumi.takami...@fujitsu.com wrote: > > On Wednesday, June 9, 2021 12:06 PM Amit Kapila > wrote: > > On Tue, Jun 8, 2021 at 6:24 PM vignesh C wrote: > > > > 3) Should [user] catalog tables be catalog tables or user catalog > > > tables [user] catalog tables > > >

Re: Logical replication keepalive flood

At Wed, 9 Jun 2021 11:21:55 +0900, Kyotaro Horiguchi wrote in > The issue - if actually it is - we send a keep-alive packet before a > quite short sleep. > > We really want to send it if the sleep gets long but we cannot predict > that before entering a sleep. > > Let me think a little more on

RE: Transactions involving multiple postgres foreign servers, take 2

From: Masahiko Sawada > Maybe it's better to start a new thread to discuss this topic. If your > idea is good, we can lower all error that happened after writing the > commit record to warning, reducing the cases where the client gets > confusion by receiving an error after the commit. No. It's

Re: Race condition in recovery?

On Wed, Jun 9, 2021 at 12:14 PM Dilip Kumar wrote: > > On Wed, Jun 9, 2021 at 2:07 AM Robert Haas wrote: > 2021-06-09 12:11:08.618 IST [122456] LOG: entering standby mode > 2021-06-09 12:11:08.622 IST [122456] LOG: restored log file > "0002.history" from archive > cp: cannot stat > ‘/home

Re: Duplicate history file?

Hi, On 2021/06/09 16:23, Fujii Masao wrote: On 2021/06/09 15:58, Tatsuro Yamada wrote: This may not be important at this time since it is a PoC patch, but I would like to inform you that there was a line that contained multiple spaces instead of tabs. $ git diff --check src/backend/access/tran

Re: Error on pgbench logs

Hello Michael, The cause is that the time unit is changed to usec but the patch forgot to convert agg_interval into the same unit in doLog. I tempted to change it into pg_time_usec_t but it seems that it is better that the unit is same with other similar variables like duration. As the option

Re: RFC: Logging plan of the running query

On 2021-05-28 15:51, torikoshia wrote: On 2021-05-13 21:57, Dilip Kumar wrote: On Thu, May 13, 2021 at 5:18 PM Dilip Kumar wrote: On Thu, May 13, 2021 at 5:15 PM Bharath Rupireddy wrote: > > On Thu, May 13, 2021 at 5:14 PM Dilip Kumar wrote: > > > > On Thu, May 13, 2021 at 4:16 PM Bharath R

  1   2   >