Re: row filtering for logical replication

y the previous call to pgoutput_row_filter may have transformed it to a different action. ~~~ 13. src/tools/pgindent/typedefs.list - RowFilterPubAction If you choose to keep the typedef for RowFilterPubAction (ref to comment #1) then it should also be added to the typedefs.list. -- Kind Regards, Peter Smith. Fujitsu Australia

Re: ICU for global collation

ll site of pg_newlocale_from_collation(). +1 for me! Here is that patch. If this is applied, then in my estimation all these hunks will completely disappear from the global ICU patch. So this would be a significant win.From 2ee4b77221020e81ec83cf37d36e3955bf619d80 Mon Sep 17 00:00:00 2001 F

tab completion of enum values is broken

This doesn't work anymore: create type e2 as enum ('foo', 'bar'); alter type e2 rename value 'b This now results in alter type e2 rename value 'b' Bisecting blames commit cd69ec66c88633c09bc9a984a7f0930e09c7c96e Author: Tom Lane Date: Thu Jan 23 11:07:12 2020 -0500 Improve psql's tab

Re: Support tab completion for upper character inputs in psql

On 07.01.22 06:17, tanghy.f...@fujitsu.com wrote: On Friday, January 7, 2022 1:08 PM, Japin Li wrote: +/* + * pg_string_tolower - Fold a string to lower case if the string is not quoted + * and only contains ASCII characters. + * For German/Turkish etc text, no change will be made. + * + * The

Re: Non-decimal integer literals

bunch of single-line test files that can provoke various errors. I will keep these around and maybe put them into something more formal in the future. On 30.12.21 10:43, Peter Eisentraut wrote: There has been some other refactoring going on, which made this patch set out of date.  So here is

Re: Time to drop plpython2?

On 12.01.22 19:49, Tom Lane wrote: Anyway, getting back to the point: I think we should notify the owners ASAP and set a 30-day deadline. We should try to get this done before the March CF starts, so it's too late for a 60-day grace period. In any case, the worst-case scenario for an owner is t

Re: UNIQUE null treatment option

On Wed, Dec 29, 2021 at 2:06 AM Peter Eisentraut wrote: > Here is a rebased version of this patch. BTScanInsertData.anynullkeys already effectively means "if the index is a unique index, then we don't actually need to go through _bt_check_unique(), or perform any other checkin

Re: UNIQUE null treatment option

On Thu, Jan 13, 2022 at 10:36 AM Peter Geoghegan wrote: > I wonder if the logic for setting BTScanInsertData.anynullkeys inside > _bt_mkscankey() is the place to put your test for > rel->rd_index->indnullsnotdistinct -- not inside _bt_doinsert(). That > would probably ne

Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations

y more likely in any particular scenario, but makes it less likely in other scenarios. It also gives us early visibility into the problem, because we'll see that autovacuum can no longer advance relfrozenxid (using the enhanced log output) where that's generally expected. -- Peter Geoghegan

Re: row filtering for logical replication

On Thu, Jan 13, 2022 at 5:49 PM Peter Smith wrote: > > Thanks for posting the merged v63. > > Here are my review comments for the v63-0001 changes. > ... > ~~~ > > 4. src/backend/replication/pgoutput/pgoutput.c - pgoutput_row_filter comments > > + > +/* > +

Re: small development tip: Consider using the gold linker

On Fri, Jul 20, 2018 at 8:16 PM Peter Geoghegan wrote: > On Mon, Jul 9, 2018 at 4:40 PM, Andres Freund wrote: > > FWIW, I've lately noticed that I spend a fair time waiting for the > > linker during edit-compile-test cycles. Due to an independent issue I > > just use

Re: row filtering for logical replication

ot;, + lrel->remoteid, + lrel->remoteid, + pub_names.data); I think that trailing ";" of the SQL is not needed, and nearby SQL execution code does not include one so maybe better to remove it for consistency. -- Kind Regards, Peter Smith. Fujitsu Australia

Re: [PATCH] Allow multiple recursive self-references

On 11.01.22 12:33, Denis Hirn wrote: I have been studying this a bit more. I don't understand your argument here. Why would this query have different semantics than, say WITH RECURSIVE t(n) AS ( VALUES (1) UNION ALL VALUES (2) UNION ALL SELECT n+1 FROM t WHERE n < 1

Re: Unifying VACUUM VERBOSE and log_autovacuum_min_duration output

On Thu, Jan 6, 2022 at 10:21 AM Peter Geoghegan wrote: > The patch bitrot again, so attached is a rebased version, v3. I pushed a version of this patch earlier. This final version didn't go quite as far as v3 did: it retained a few VACUUM VERBOSE only INFO messages (it didn't d

Time to increase hash_mem_multiplier default?

emory it can make use of. This effect is reliable (data cardinality won't matter, for example). And so the improvement that is possible from giving a sort more memory is far smaller than (say) the improvement in performance we typically see when the optimizer switches from a hash aggregate to a group aggregate. -- Peter Geoghegan

Re: row filtering for logical replication

although the SQLs looked to be similar they actually take different PublicationObjSpec execution paths in the gram.y: i.e. " ColId OptWhereClause" Versus " ColId indirection OptWhereClause" ~~ So this review comment can be skipped. Both tests should be retained. -- Kind Regards, Peter Smith. Fujitsu Australia

Re: row filtering for logical replication

f unnecessary due to partition and the ancestor * having identical TupleDesc. */ - TupleConversionMap *map; + AttrMap *map; } RelationSyncEntry; I wondered if you should also rename this member to something more meaningful like 'attrmap' instead of just 'map'. -- Kind Regards, Peter Smith. Fujitsu Australia

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

and so could be a local (as you say), but I felt the code consistency and future-proof benefits outweighed the idea of reducing the code to bare minimum required to work just "because we can". So I don't plan to change this, but if you still feel strongly that the parameter must be removed please give a convincing reason. Kind Regards, Peter Smith. Fujitsu Australia.

Re: New IndexAM API controlling index vacuum strategies

a structures roughly right here -- but I would appreciate some feedback on that. Does this seem like the right direction? -- Peter Geoghegan v3-0002-Skip-index-vacuuming-dynamically.patch Description: Binary data v3-0001-Remove-tupgone-special-case-from-vacuumlazy.c.patch Description: Binary data

Re: New IndexAM API controlling index vacuum strategies

d is after all very aggressive). We just need to be 99%+ sure that continuing with vacuuming will be worse that ending vacuuming. Which seems possible by making the decision dynamic (and revisiting it at least a few times during a very long VACUUM, in case things change). -- Peter Geoghegan

Re: New IndexAM API controlling index vacuum strategies

which is also only for emergencies. It is not like the SKIP_VACUUM_PAGES_RATIO case, which is just an optimization. Thanks -- Peter Geoghegan

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 15.03.21 18:35, Tom Lane wrote: Anyway, taking a quick look at the v4 patch, the only complaint I have is that it seems a bit bulky and brute-force to duplicate so much code. Is it feasible to share most of the implementation between old and new functions, returning (say) an int64 that can th

Re: SSL SNI

On 26.02.21 23:27, Greg Stark wrote: Do you mean the IPv6 detection code is not correct? What is the problem? This bit, will recognize ipv4 addresses but not ipv6 addresses: + /* + * Set Server Name Indication (SNI), but not if it's a literal IP address. + * (RFC 6066) + */ + if (!(strspn(con

Re: SSL SNI

On 25.02.21 19:36, Jacob Champion wrote: On Thu, 2021-02-25 at 17:00 +0100, Peter Eisentraut wrote: Just as additional data points, it has come to my attention that both the Go driver ("lib/pq") and the JDBC environment already send SNI automatically. (In the case of JDBC this is d

Re: a verbose option for autovacuum

uum_indexes() and vacuum_indexes_leader(). > Please review the attached patch. That seems much clearer. Were you going to take care of this, Michael? -- Peter Geoghegan

Re: New IndexAM API controlling index vacuum strategies

burned through XIDs at a furious pace. So we really want this mechanism to not rely on the system being in its typical state, if at all possible. When index vacuuming is skipped due to concerns about XID wraparound, it should really be a rare emergency that is a rare and unpleasant surprise to the DBA. Nobody should rely on this mechanism consistently. -- Peter Geoghegan

Re: default result formats setting

curity concern, but I don't think it's useful. The driver would specify "send int4 in binary, I know how to handle that". There doesn't seem to be a point in specifying that sort of thing globally. From 3410ac02bc34b60b79c99ad96505dabe4362570f Mon Sep 17 00:00:00 2001 Fro

Maintaining a list of pgindent commits for "git blame" to ignore

Tom runs pgindent. It doesn't matter if this misses one or two smaller pgindent runs, it seems. Provided the really huge ones are in the file, everything works very well. -- Peter Geoghegan

Re: Maintaining a list of pgindent commits for "git blame" to ignore

ficial project workflow documented at src/tools/pgindent/README. -- Peter Geoghegan pgindent-git-blame-ignore-revs Description: Binary data

Re: a verbose option for autovacuum

On Thu, Mar 18, 2021 at 2:08 PM Michael Paquier wrote: > Yes, I was waiting for Sawada-san to send an updated version, which he > just did. Great. This really seems worth having. I was hoping that somebody else could pick this one up. -- Peter Geoghegan

Re: Maintaining a list of pgindent commits for "git blame" to ignore

isn't a lot left to automate -- running pgindent on the tree is something that happens no more than 2 or 3 times a year. It could easily be added to the checklist in the README. It should take less than 5 minutes a year. -- Peter Geoghegan

Re: Maintaining a list of pgindent commits for "git blame" to ignore

ing I remember it insisting upon in any other area. There is probably a very good practical reason for that. -- Peter Geoghegan

Re: Maintaining a list of pgindent commits for "git blame" to ignore

ing that there might be a security issue. I could fairly easily make my git commit match a prefix intended to uniquely identify your git commit if I set out to do so. There are projects that might have to consider that possibility, though perhaps we're not one of them. -- Peter Geoghegan

Re: Maintaining a list of pgindent commits for "git blame" to ignore

And that the pgindent README (which already mentions these other tools) ought to be updated to be explicit about the policy applying equally to commits that apply any of the two other tools in bulk. -- Peter Geoghegan

Re: Maintaining a list of pgindent commits for "git blame" to ignore

dful of those. They tend to generate an enormous amount of churn that touches almost everything. So it probably isn't necessary to worry about smaller things. -- Peter Geoghegan

Re: New IndexAM API controlling index vacuum strategies

On Thu, Mar 18, 2021 at 2:05 PM Robert Haas wrote: > On Wed, Mar 17, 2021 at 11:23 PM Peter Geoghegan wrote: > > Most anti-wraparound VACUUMs are really not emergencies, though. > > That's true, but it's equally true that most of the time it's not > necessary to

Re: Allow an alias to be attached directly to a JOIN ... USING

On 05.03.21 18:00, David Steele wrote: On 11/14/20 3:49 AM, Peter Eisentraut wrote: On 2020-11-10 16:15, Georgios Kokolatos wrote: I noticed that this patch fails on the cfbot. For this, I changed the status to: 'Waiting on Author'. Cheers, //Georgios The new status of thi

Re: SQL-standard function body

00:00:00 2001 From: Peter Eisentraut Date: Fri, 19 Mar 2021 14:48:04 +0100 Subject: [PATCH v10] SQL-standard function body This adds support for writing CREATE FUNCTION and CREATE PROCEDURE statements for language SQL with a function body that conforms to the SQL standard and is portable to other im

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 18.03.21 09:28, Peter Eisentraut wrote: Which leads me to:  After retesting this now, with a new machine, the performance of the numeric implementation is brutal compared to the float implementation, for cases where we need numeric division, which is milliseconds, seconds, and epoch.  In

Re: [PATCH] Identify LWLocks in tracepoints

On 18.03.21 07:34, Craig Ringer wrote: In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call moved?   Is there some correctness issue?  If so, we should explain that (at least in the commit message, or as a separate patch). If you want I can split it out, or drop th

Re: [PATCH] Identify LWLocks in tracepoints

On 18.03.21 07:34, Craig Ringer wrote: The main reason I didn't want to add more tracepoints than were strictly necessary is that Pg doesn't enable the systemtap semaphores feature, so right now we do a T_NAME(lock) evaluation each time we pass a tracepoint if --enable-dtrace is compiled in,

Re: Maintaining a list of pgindent commits for "git blame" to ignore

Okay. I have made a personal TODO list item for this. I'll pick this up again in April, once the final CF is over. -- Peter Geoghegan

replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

finished using the ent. Kind Regards, Peter Smith. Fujitsu Australia v1-0001-Fix-for-stream_cleanup_files-HASH_REMOVE.patch Description: Binary data

Re: popcount

On 18.03.21 13:51, John Naylor wrote: Hi David, Just a nitpick: +SET bytea_output TO hex; Since we don't see the string in the output, I don't immediately see the reason to change the output format here? Aside from that, this patch works as expected, and is ready for committer. I have now

Re: [PATCH] Identify LWLocks in tracepoints

On 19.03.21 21:06, Peter Eisentraut wrote: On 18.03.21 07:34, Craig Ringer wrote:     In patch 0001, why was the TRACE_POSTGRESQL_LWLOCK_RELEASE() call     moved?   Is there some correctness issue?  If so, we should explain that (at     least in the commit message, or as a separate patch

Re: New IndexAM API controlling index vacuum strategies

urally the implementation wouldn't really need to consider whether that meant the anti-wraparound VACUUM could end almost immediately, or some time later -- the point is that it completes ASAP. -- Peter Geoghegan

Re: default result formats setting

On 19.03.21 15:55, Emre Hasegeli wrote: I applied the patch, tried running the test and got the following: rm -rf '/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check /bin/sh ../../../../config/install-sh -c -d '/Users/hasegeli/Developer/postgres/src/test/modules/li

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Sun, Mar 21, 2021 at 8:54 PM Amit Kapila wrote: > > On Sat, Mar 20, 2021 at 12:54 PM Peter Smith wrote: > > > > PSA my patch to correct this by firstly doing a HASH_FIND, then only > > HASH_REMOVE after we've finished using the ent. > > > > Why can

Re: 64-bit XIDs in deleted nbtree pages

On Wed, Mar 10, 2021 at 5:34 PM Peter Geoghegan wrote: > Here is another bitrot-fix-only revision, v9. Just the recycling patch again. I committed the final nbtree page deletion patch just now -- the one that attempts to make recycling happen for newly deleted pages. Thanks for all your work

Re: replication cleanup code incorrect way to use of HTAB HASH_REMOVE ?

On Mon, Mar 22, 2021 at 9:21 AM Thomas Munro wrote: > > On Mon, Mar 22, 2021 at 10:50 AM Peter Smith wrote: > > The real problem isn't the Assert. It's all those other usages of ent > > disobeying the API rule: "(NB: in the case of the REMOVE action, the >

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

now what do you think about the changes? > Hi Amit. PSA a small collection of feedback patches you can apply on top of the patch v65-0001 if you decide they are OK. (There are all I have found after a first pass over all the recent changes). ------ Kind Regards, Peter Smith. Fujitsu Au

Re: [PATCH] Identify LWLocks in tracepoints

On 10.03.21 06:38, Craig Ringer wrote: On Wed, 3 Mar 2021 at 20:50, David Steele <mailto:da...@pgmasters.net>> wrote: On 1/22/21 6:02 AM, Peter Eisentraut wrote: This patch set no longer applies: http://cfbot.cputube.org/patch_32_2927.log <http://cfbot.cputube.org/p

Re: [PATCH] Identify LWLocks in tracepoints

On 20.03.21 01:29, Craig Ringer wrote: There is already support for that.  See the documentation at the end of this page: https://www.postgresql.org/docs/devel/dynamic-trace.html#DEFINING-TRACE-POINTS

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

On Mon, Mar 22, 2021 at 6:27 PM Peter Smith wrote: > > On Sun, Mar 21, 2021 at 6:37 PM Amit Kapila wrote: > > > > I have further updated the patch to implement unique GID on the > > subscriber-side as discussed in the nearby thread [1]. That requires > > some change

Re: default result formats setting

Here is an updated patch. From 61796d1077bd146daa6952dae799819539c05a96 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 22 Mar 2021 13:36:35 +0100 Subject: [PATCH v5] Add result_format_auto_binary_types setting The current way binary results are requested in the extended query proto

Re: New IndexAM API controlling index vacuum strategies

e splits (by deleting now-totally-dead index tuples), then we shouldn't be too surprised to see complementary effects. Though I have to admit that I was quite surprised at how true this was in the case of Victor's benchmark -- it worked very well with the workload, without any designer predicting or understanding anything specific. -- Peter Geoghegan

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

On 19.03.21 21:06, Tom Lane wrote: I guess the immediate question is how much of a performance gap there is now between the float and numeric implementations. Attached are my test script and the full output. To summarize, for cases that don't do any interesting computation and where the over

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

an pgindent, (d) modified tests to use standard > wait_for_catch function and removed few tests to reduce the time and > to keep regression tests reliable. I checked all v65* / v66* differences and found only two trivial comment typos. PSA patches to fix those. ---- Kind Regards, Peter Smi

Re: New IndexAM API controlling index vacuum strategies

you know what you're doing (say you're testing the feature) you can reduce all 3 sibling GUCs to 0 and get the testing behavior that you desire. What do you think? -- Peter Geoghegan

Re: New IndexAM API controlling index vacuum strategies

On Mon, Mar 22, 2021 at 8:28 PM Peter Geoghegan wrote: > You seem to be concerned about a similar contradiction. In fact it's > *very* similar contradiction, because this new GUC is naturally a > "sibling GUC" of both vacuum_freeze_table_age and > autovacuum_vacuum_m

Re: New IndexAM API controlling index vacuum strategies

On Mon, Mar 22, 2021 at 8:33 PM Peter Geoghegan wrote: > More concretely, maybe the new GUC is forced to be 1.05 of > vacuum_freeze_table_age. Of course that scheme is a bit arbitrary -- > but so is the existing 0.95 scheme. I meant to write 1.05 of autovacuum_vacuum_max_age. S

Re: popcount

On 21.03.21 02:31, David Fetter wrote: I have now read the entire internet on what a suitable name for this function could be. I think the emerging winner is BIT_COUNT(), which already exists in MySQL, and also in Python (int.bit_count()) and Java (Integer.bitCount()). Thanks for doing this te

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

On Tue, Mar 23, 2021 at 10:44 AM Peter Smith wrote: > > On Mon, Mar 22, 2021 at 11:51 PM Amit Kapila wrote: > > > > I have incorporated all your changes and additionally made few more > > changes (a) got rid of LogicalRepBeginPrepareData and instead used > > Logical

Re: OpenSSL 3.0.0 compatibility

On 12.03.21 00:22, Daniel Gustafsson wrote: On 12 Mar 2021, at 00:04, Peter Eisentraut wrote: On 11.03.21 11:41, Daniel Gustafsson wrote: Then there are a few where we get padding back where we really should have ended up with the "Cipher cannot be initialized" error since DES

Re: pg_amcheck contrib application

ame situation at all -- this is VACUUM. I will make this change to HEAD soon, barring objections. -- Peter Geoghegan

Re: pg_amcheck contrib application

of the work involved in deleting an entire subtree up-front, inside _bt_lock_subtree_parent(). It's clearly safe to back out of it if it looks dicey. -- Peter Geoghegan

Re: pg_amcheck contrib application

On Tue, Mar 23, 2021 at 12:53 PM Peter Geoghegan wrote: > One of the advantages of this design is that we verify practically all > of the work involved in deleting an entire subtree up-front, inside > _bt_lock_subtree_parent(). It's clearly safe to back out of it if it > loo

Re: New IndexAM API controlling index vacuum strategies

hat high level simplicity seems important to me. I always disliked the way the WAL records for vacuumlazy.c worked. Especially the XLOG_HEAP2_CLEANUP_INFO record -- that one is terrible. -- Peter Geoghegan

Re: 64-bit XIDs in deleted nbtree pages

yet placed in the FSM (it's hard to think through very rare cases like this with confidence). Is it really so bad if we launch parallel workers that we don't really need for a parallel VACUUM? -- Peter Geoghegan

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

On Tue, Mar 23, 2021 at 9:01 PM Peter Smith wrote: > > On Tue, Mar 23, 2021 at 10:44 AM Peter Smith wrote: > > > > On Mon, Mar 22, 2021 at 11:51 PM Amit Kapila > > wrote: > > > > > > I have incorporated all your changes and additionally

Re: truncating timestamps on arbitrary intervals

On 18.01.21 21:54, John Naylor wrote: On Mon, Nov 23, 2020 at 1:44 PM John Naylor mailto:john.nay...@enterprisedb.com>> wrote: > > On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut <mailto:peter.eisentr...@enterprisedb.com>> wrote: > > - After reading the discuss

Re: truncating timestamps on arbitrary intervals

On 24.03.21 18:25, Erik Rijkers wrote: On 2021.03.24. 16:38 Peter Eisentraut wrote: Committed. 'In cases full units' seems strange. fixed, thanks

Re: truncating timestamps on arbitrary intervals

On 24.03.21 18:58, John Naylor wrote: > As a potential follow-up, should we perhaps add named arguments?  That > might make the invocations easier to read, depending on taste. I think it's quite possible some users will prefer that. All we need is to add something like proargnames => '{bin_

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

On Wed, Mar 24, 2021 at 11:31 PM Amit Kapila wrote: > > On Tue, Mar 23, 2021 at 3:31 PM Peter Smith wrote: > > > > On Tue, Mar 23, 2021 at 10:44 AM Peter Smith wrote: > > > > > > PSA patches to fix those. > > > > > > > Hi Amit. > &

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

On Thu, Mar 25, 2021 at 1:40 PM Peter Smith wrote: > > On Wed, Mar 24, 2021 at 11:31 PM Amit Kapila wrote: > > > > On Tue, Mar 23, 2021 at 3:31 PM Peter Smith wrote: > > > > > > On Tue, Mar 23, 2021 at 10:44 AM Peter Smith > > > wr

Re: multi-install PostgresNode

On 25.03.21 04:47, Michael Paquier wrote: On Wed, Mar 24, 2021 at 03:33:51PM -0300, Alvaro Herrera wrote: On 2021-Mar-24, Andrew Dunstan wrote: +# The install path set in get_new_node needs to be a directory containing +# bin and lib subdirectories as in a standard PostgreSQL installation, so t

Re: proposal: unescape_text function

functionality is the same. Now it supports Oracle convention, Java and Python (for Python U) and \+XX. These formats was already supported.The compatibility witth Oracle is nice. Peter, it looks like Pavel has aligned this function with unistr() as you suggested. Thoughts? I have

Re: row filtering for logical replication

9fa406202c30b0a Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Thu, 25 Mar 2021 11:57:48 +0100 Subject: [PATCH 1/6] fixup! Row filter for logical replication Remove unused header files, clean up whitespace. --- src/backend/catalog/pg_publication.c| 2 -- src/backend/replication/pgou

Re: name of enum used in 'Cache if PathTarget and RestrictInfos contain volatile functions'

as UNKNOWN is going to clash [1] with something else, which IIUC is why the enums all have prefixes in the first place. -- [1] https://stackoverflow.com/questions/35380279/avoid-name-collisions-with-enum-in-c-c99 Kind Regards, Peter Smith. Fujitsu Australia

Re: proposal: unescape_text function

On 25.03.21 10:44, Peter Eisentraut wrote: On 10.03.21 14:52, David Steele wrote: I thought about it a little bit more, and  the prefix specification has not too much sense (more if we implement this functionality as function "unistr"). I removed the optional argument and r

Redundant errdetail prefix "The error was:" in some logical replication messages

xist 2021-03-30 14:17:37.567 AEDT [22317] STATEMENT: DROP SUBSCRIPTION tap_sub; -- PSA a small patch which simply removes this prefix "The error was:" -- Kind Regards, Peter Smith. Fujitsu Australia v1-0001-Remove-redundant-errdetail-The-error-was.patch Description: Binary data

Re: Redundant errdetail prefix "The error was:" in some logical replication messages

On Tue, Mar 30, 2021 at 5:10 PM Tom Lane wrote: > > Peter Smith writes: > > There are a couple of error messages within the logical replication > > code where the errdetail text includes a prefix of "The error was:" > > Hmm, isn't project style more usual

Use consistent terminology for tablesync slots.

e same - "tablesync slots" -- Kind Regards, Peter Smith. Fujitsu Australia v1-0001-Use-consistent-terminology-for-tablesync-slots.patch Description: Binary data

Re: Add Nullif case for eval_const_expressions_mutator

On 24.03.21 11:52, houzj.f...@fujitsu.com wrote: + if (!has_nonconst_input) + return ece_evaluate_expr(expr); That's not okay without a further check to see if the comparison function used by the node is immutable. Compare Scal

Re: Use consistent terminology for tablesync slots.

On Tue, Mar 30, 2021 at 8:14 PM Amit Kapila wrote: > > On Tue, Mar 30, 2021 at 2:21 PM Peter Smith wrote: > > > > Hi, > > > > The logical replication tablesync worker creates tablesync slots. > > > > Previously some PG docs pages were referring to these

Re: Lowering the ever-growing heap->pd_lower

an Assert, which fails when > the redirect is to an invalid OffsetNumber. This is not enough to not > exhibit arbitrary behaviour when accessing corrupted data with > non-assert builds, but I think that that is fine; we already do not > have a guaranteed behaviour for this fai

Re: Allow an alias to be attached directly to a JOIN ... USING

On 23.03.21 00:18, Tom Lane wrote: However, ParseNamespaceItem as it stands needs some help for this. It has a wired-in assumption that p_rte->eref describes the table and column aliases exposed by the nsitem. 0001 below fixes this by creating a separate p_names field in an nsitem. (There are

Re: New IndexAM API controlling index vacuum strategies

ought -- lazy_scan_prune() was my focus in 0002. I can imagine adding a lot more stuff to lazy_scan_prune() in the future too. For example, maybe we can do more freezing earlier based on whether or not we can avoid dirtying the page by not freezing. The structure of lazy_scan_prune() can do stuff like that because it gets to see the page before and after both pruning and freezing -- and with the retry stuff in 0003, it can back out of an earlier decision to not freeze as soon as it realizes the page is getting dirtied either way. Also, I think we might end up collecting more complicated information that informs our eventual decision about whether or not indexes need to be vacuumed. > My concentration is flagging a bit so I'm going to stop reviewing here > for now. I'm not deeply opposed to any of what I've seen so far. My > main criticism is that I think more thought should be given to how > things are named and to separating minimal code-movement patches from > other changes. That seems totally reasonable. Thanks again! -- Peter Geoghegan

Re: New IndexAM API controlling index vacuum strategies

em, etc. But let me think about it...I suppose we could do it when one-pass VACUUM considers vacuuming a range of FSM pages every VACUUM_FSM_EVERY_PAGES. That's kind of similar to index vacuuming, in a way -- it wouldn't be too bad to check for emergencies in the same way there. > Both vacrel->do_index_vacuuming and vacrel->do_index_cleanup can be > false also when INDEX_CLEANUP is off. So autovacuum could wrongly > report emergency if the table's vacuum_index_vacuum reloption is > false. Good point. I will need to account for that so that log_autovacuum's LOG message does the right thing. Perhaps for other reasons, too. Thanks for the review! -- Peter Geoghegan

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

On Thu, Apr 1, 2021 at 4:58 PM Ajin Cherian wrote: > > > > On Thu, Apr 1, 2021 at 2:29 PM Amit Kapila wrote: >> >> On Tue, Mar 30, 2021 at 5:34 AM Peter Smith wrote: >> > >> > Please find attached the latest patch set v68* >> > >> >

Re: Since '2001-09-09 01:46:40'::timestamp microseconds are lost when extracting epoch

rt as an open item in any case, to see what we should do about that. From d6d28fc50107401ffd9d8ed0e7c641e6ef21fe3c Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Thu, 1 Apr 2021 20:12:07 +0200 Subject: [PATCH v6] Change return type of EXTRACT to numeric The previous implementation of EXTRACT

Re: New IndexAM API controlling index vacuum strategies

set/returned by lazy_scan_prune(), or generic stuff like a Buffer variable. -- Peter Geoghegan

Re: Add Nullif case for eval_const_expressions_mutator

On 30.03.21 11:20, Peter Eisentraut wrote: On 24.03.21 11:52, houzj.f...@fujitsu.com wrote: +    if (!has_nonconst_input) +    return ece_evaluate_expr(expr); That's not okay without a further check to see if the comparison function used by the node is immu

Re: SQL-standard function body

On 31.03.21 12:12, Julien Rouhaud wrote: On Tue, Mar 23, 2021 at 11:28:55PM -0500, Jaime Casanova wrote: On Fri, Mar 19, 2021 at 8:49 AM Peter Eisentraut wrote: Right. Here is a new patch with that fix added and a small conflict resolved. Great. It seems print_function_sqlbody() is not

Re: SP-GiST confusion: indexed column's type vs. index column type

The tupdesc passed back for an index-only scan reports the > input (heap) data type. > > This might be too much change for the back branches. Given the > lack of complaints to date, I think we can just fix it in HEAD. +1 to fixing it on HEAD only. -- Peter Geoghegan

Re: Support ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION ... syntax

On 23.03.21 16:08, Japin Li wrote: I check the duplicates for newpublist in merge_publications(). The code is copied from publicationListToArray(). I do not check for all duplicates because it will make the code more complex. For example: ALTER SUBSCRIPTION mysub ADD PUBLICATION mypub2, mypub2,

Re: Using COPY FREEZE in pgbench

rprised how much wal_compression=off matters here.) -- Peter Geoghegan

Re: Using COPY FREEZE in pgbench

ful because it speeds up "pgbench -i" for everybody. It's also useful because having all of the tuples already frozen after bulk loading seems like a good benchmarking practice, at least most of the time. The patch changes the initial state of the database with "pgbench -i"

Re: Lowering the ever-growing heap->pd_lower

truncation mechanism will only ever kick-in during a VACUUM operation. -- Peter Geoghegan

Re: New IndexAM API controlling index vacuum strategies

paround/aggressive autovacuum immediately afterwards. We want that second anti-wraparound VACUUM to hurry from the very start of lazy_scan_heap(). -- Peter Geoghegan

<    5   6   7   8   9   10   11   12   13   14   >