Re: [PATCH] Completed unaccent dictionary with many missing characters

On Thu, Jun 23, 2022 at 02:10:42PM +0200, Przemysław Sztoch wrote: > The only division that is probably possible is the one attached. Well, the addition of cyrillic does not make necessary the removal of SOUND RECORDING COPYRIGHT or the DEGREEs, that implies the use of a dictionnary when

Re: [PoC] Improve dead tuple storage for lazy vacuum

Hi, On 2022-06-28 11:17:42 +0700, John Naylor wrote: > On Mon, Jun 27, 2022 at 10:23 PM Hannu Krosing wrote: > > > > > Another thought: for non-x86 platforms, the SIMD nodes degenerate to > > > "simple loop", and looping over up to 32 elements is not great > > > (although possibly okay). We

Re: Comments referring to pg_start/stop_backup

At Tue, 28 Jun 2022 13:41:58 +0900, Michael Paquier wrote in > Hi all, > > While browsing through the recent changes with the base backup APIs, I > have noticed that a couple of comments did not get the renaming of the > SQL functions to pg_backup_start/stop, as of the attached. > > That's

Comments referring to pg_start/stop_backup

Hi all, While browsing through the recent changes with the base backup APIs, I have noticed that a couple of comments did not get the renaming of the SQL functions to pg_backup_start/stop, as of the attached. That's not a big deal, but let's be right. Thanks, -- Michael diff --git

Re: WIP Patch: Add a function that returns binary JSONB as a bytea

I wrote: > We can also shave a > few percent by having pg_utf8_verifystr use SSE2 for the ascii path. I > can look into this. Here's a patch for that. If the input is mostly ascii, I'd expect that part of the flame graph to shrink by 40-50% and give a small boost overall. -- John Naylor EDB:

Re: Making the subquery alias optional in the FROM clause

Hi, On Mon, Jun 27, 2022 at 12:03:20PM -0400, Isaac Morland wrote: > On Mon, 27 Jun 2022 at 11:12, Julien Rouhaud wrote: > > > More generally, I'm -0.5 on the feature. > > I prefer to force using SQL-compliant queries, and also not take bad > > habits. > > > > As to forcing SQL-complaint

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Mon, Jun 27, 2022 at 10:23 PM Hannu Krosing wrote: > > > Another thought: for non-x86 platforms, the SIMD nodes degenerate to > > "simple loop", and looping over up to 32 elements is not great > > (although possibly okay). We could do binary search, but that has bad > > branch prediction. > >

Re: Perform streaming logical transactions by background workers and parallel apply

On Tue, Jun 28, 2022 at 8:51 AM wangw.f...@fujitsu.com wrote: > > On Thu, Jun 23, 2022 at 16:44 PM Amit Kapila wrote: > > On Thu, Jun 23, 2022 at 12:51 PM wangw.f...@fujitsu.com > > wrote: > > > > > > On Mon, Jun 20, 2022 at 11:00 AM Amit Kapila > > wrote: > > > > I have improved the comments

Re: NAMEDATALEN increase because of non-latin languages

On Sat, Jun 25, 2022 at 08:00:04PM -0700, Andres Freund wrote: > > On 2022-06-26 10:48:24 +0800, Julien Rouhaud wrote: > > Anyway, per the nearby discussions I don't see much interest, especially > > not in > > the context of varlena identifiers (I should have started a different > > thread, > >

Re: Support logical replication of DDLs

On Sun, Jun 26, 2022 at 11:47 PM Alvaro Herrera wrote: > > On 2022-Jun-22, vignesh C wrote: > > > 1) Creation of temporary table fails infinitely in the subscriber. > > CREATE TEMPORARY TABLE temp1 (a int primary key); > > > > The above statement is converted to the below format: > > CREATE

RE: Perform streaming logical transactions by background workers and parallel apply

On Thu, Jun 23, 2022 at 9:41 AM Peter Smith wrote: > Here are some review comments for v12-0002 Thanks for your comments. > 3. .../subscription/t/022_twophase_cascade.pl > > For every test file in this patch the new function is passed $is_apply > = 0/1 to indicate to use 'on' or 'apply'

RE: Perform streaming logical transactions by background workers and parallel apply

On Mon, Jun 21, 2022 at 9:41 AM Peter Smith wrote: > Here are some review comments for the v11-0001 patch. > > (I will review the remaining patches 0002-0005 and post any comments later) > Thanks for your comments. > 6. doc/src/sgml/protocol.sgml > > Since there are protocol changes made

Re: Repeatability of installcheck for test_oat_hooks

On Tue, Jun 28, 2022 at 10:12:48AM +0900, Michael Paquier wrote: > As far as I can see, test_oat_hook has no need to keep around the > extra role it creates as part of the regression tests, because at the > end of the test there are no objects that depend on it. Wouldn't it > be better to make

Re: Handle infinite recursion in logical replication setup

Here are my review comments for the v24* patch set. Now, these few comments are all trivial and non-functional. Apart from these, everything looks good to me. v24-0001 No comments. LGTM V24-0002 2.1 doc/src/sgml/ref/create_subscription.sgml + +

Re: ICU for global collation

On Mon, Jun 27, 2022 at 09:10:29AM +0200, Peter Eisentraut wrote: > On 27.06.22 08:42, Michael Paquier wrote: > > On Mon, Jun 27, 2022 at 08:23:59AM +0200, Peter Eisentraut wrote: > > > On 26.06.22 05:51, Julien Rouhaud wrote: > > > > On Sat, Jun 25, 2022 at 10:19:30AM -0500, Justin Pryzby wrote:

Repeatability of installcheck for test_oat_hooks

Hi all, (Andrew in CC.) When running installcheck multiple times under src/test/modules/, we are getting two failures as of test_pg_dump and test_oat_tests, because these keep around some roles created by the tests. Keeping around a role for test_pg_dump has been discussed already, where the

Re: [BUG] Panic due to incorrect missingContrecPtr after promotion

At Mon, 27 Jun 2022 15:02:11 +0900, Michael Paquier wrote in > On Fri, Jun 24, 2022 at 04:17:34PM +, Imseih (AWS), Sami wrote: > > It is been difficult to get a generic repro, but the way we reproduce > > Is through our test suite. To give more details, we are running tests > > In which we

Re: Allowing REINDEX to have an optional name

Maybe the answer is to 1) add a parenthesized option REINDEX(SYSTEM) (to allow the current behavior); and 2) make REINDEX DATABASE an alias which implies "SYSTEM false"; 3) prohibit REINDEX (SYSTEM true) SYSTEM, or consider removing "REINDEX SYSTEM;". That avoids the opaque and surprising

Re: pg_upgrade (12->14) fails on aggregate

On Sat, Jun 25, 2022 at 03:34:49PM +0500, Andrey Borodin wrote: > > On 25 Jun 2022, at 01:28, Justin Pryzby wrote: > > > this is my latest. > > <0001-WIP-pg_upgrade-check-detect-old-polymorphics-from-pr.patch> > > Let's rename "databases_with_old_polymorphics.txt" to somthing like >

Re: [PoC] Let libpq reject unexpected authentication requests

On Mon, Jun 27, 2022 at 12:05 PM Jacob Champion wrote: > v5 adds a second patch which implements a client-certificate analogue > to gssencmode; I've named it sslcertmode. ...and v6 fixes check-world, because I always forget about postgres_fdw. --Jacob diff --git

Re: Hardening PostgreSQL via (optional) ban on local file system access

My current thinking is (based on more insights from Andres) that we should also have a startup flag to disable superuser altogether to avoid bypasses via direct manipulation of pg_proc. Experience shows that 99% of the time one can run PostgreSQL just fine without a superuser, so having a

Re: Hardening PostgreSQL via (optional) ban on local file system access

On Sat, 2022-06-25 at 00:08 +0200, Hannu Krosing wrote: > Hi Pgsql-Hackers > > As part of ongoing work on PostgreSQL security hardening we have > added a capability to disable all file system access (COPY TO/FROM > [PROGRAM] , pg_*file*() functions, lo_*() functions > accessing files, etc) in a

Re: do only critical work during single-user vacuum?

On Mon, Jun 27, 2022 at 12:36 PM Justin Pryzby wrote: > By chance, I came across this prior thread which advocated the same thing in a > initially (rather than indirectly as in this year's thread). Revisiting this topic reminded me that PostgreSQL 14 (the first version that had the wraparound

Re: Retrieving unused tuple attributes in ExecScan

Re: So I'm actually using the columns during merge join, basically I'm building a bloom filter on the outer relation and filtering out data on the inner relation of the join. I'm building the filter on the join keys We had a whole implementation for Bloom filtering for hash inner join, complete

Re: Retrieving unused tuple attributes in ExecScan

Hi, (please don't top-quote on PG lists) On 2022-06-27 19:29:34 +, Ma, Marcus wrote: > So I'm actually using the columns during merge join, basically I'm building a > bloom filter on the outer relation and filtering out data on the inner > relation of the join. I'm building the filter on

Re: do only critical work during single-user vacuum?

On Thu, Feb 03, 2022 at 01:05:50PM -0500, Robert Haas wrote: > On Thu, Dec 9, 2021 at 8:56 PM Andres Freund wrote: > > I think we should move *away* from single user mode, rather than the > > opposite. It's a substantial code burden and it's hard to use. > > Yes. This thread seems to be largely

Re: Retrieving unused tuple attributes in ExecScan

Hey Andres, So I'm actually using the columns during merge join, basically I'm building a bloom filter on the outer relation and filtering out data on the inner relation of the join. I'm building the filter on the join keys, so the columns are being used further up the execution tree. However,

Re: Retrieving unused tuple attributes in ExecScan

Hi, On 2022-06-27 19:00:44 +, Ma, Marcus wrote: > If I understand correctly, when a Sequential Scan takes place, the ExecScan > function (located in executor/execScan.c) does not retrieve all attributes > per tuple in the TupleTableSlot and only retrieves the necessary attribute. > So for

Re: [PoC] Let libpq reject unexpected authentication requests

On Fri, Jun 24, 2022 at 12:17 PM Jacob Champion wrote: > Both NOT (via ! negation) and "none" are implemented in v4. v5 adds a second patch which implements a client-certificate analogue to gssencmode; I've named it sslcertmode. This takes the place of the require_auth=[!]cert setting

Retrieving unused tuple attributes in ExecScan

Hey, If I understand correctly, when a Sequential Scan takes place, the ExecScan function (located in executor/execScan.c) does not retrieve all attributes per tuple in the TupleTableSlot and only retrieves the necessary attribute. So for example, let’s imagine we have a table t1 with 3 number

Re: Making the subquery alias optional in the FROM clause

On Mon, 27 Jun 2022 at 19:43, David G. Johnston wrote: > > On Mon, Jun 27, 2022 at 11:25 AM Dean Rasheed > wrote: >> >> On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote: >> > >> > It doesn't play that well if you have something called subquery though: >> > >> > [example that changes a

Re: Making the subquery alias optional in the FROM clause

On Mon, Jun 27, 2022 at 11:25 AM Dean Rasheed wrote: > On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote: > > > > It doesn't play that well if you have something called subquery though: > > > > [example that changes a user-provided alias] > > > > While the output is a valid query, it's not

Re: Making the subquery alias optional in the FROM clause

On Mon, 27 Jun 2022 at 16:12, Julien Rouhaud wrote: > > It doesn't play that well if you have something called subquery though: > > [example that changes a user-provided alias] > > While the output is a valid query, it's not nice that it's replacing a > user provided alias with another one (or

Re: SYSTEM_USER reserved word implementation

On 2022-Jun-25, Drouvot, Bertrand wrote: > diff --git a/src/include/miscadmin.h b/src/include/miscadmin.h > index 0af130fbc5..8d761512fd 100644 > --- a/src/include/miscadmin.h > +++ b/src/include/miscadmin.h > @@ -364,6 +364,10 @@ extern void InitializeSessionUserIdStandalone(void); > extern

Re: Making the subquery alias optional in the FROM clause

On Mon, 27 Jun 2022 at 11:12, Julien Rouhaud wrote: > More generally, I'm -0.5 on the feature. > I prefer to force using SQL-compliant queries, and also not take bad > habits. > As to forcing SQL-complaint queries, that ship sailed a long time ago: Postgres allows but does not enforce the use

Re: Lazy JIT IR code generation to increase JIT speed with partitions

On 2021-Jan-18, Luc Vlaming wrote: > I would like this topic to somehow progress and was wondering what other > benchmarks / tests would be needed to have some progress? I've so far > provided benchmarks for small(ish) queries and some tpch numbers, assuming > those would be enough. Hi, some

Re: Emit postgres log messages that have security or PII with special flags/error code/elevel

Hi, On Mon, Jun 27, 2022 at 06:41:21PM +0530, Bharath Rupireddy wrote: > > Here's an idea - what if postgres can emit log messages that have sensitive > information with special error codes or flags? The emit_log_hook > implementers will then just need to look for those special error codes or >

[Commitfest 2022-07] Begins This Friday

Hi all, Just a reminder that the July 2022 commitfest will begin this coming Friday, July 1. I'll send out reminders this week to get your patches registered/rebased, and I'll be updating stale statuses in the CF app. Thanks, --Jacob

Re: [PoC] Improve dead tuple storage for lazy vacuum

Hi, On 2022-06-27 18:12:13 +0700, John Naylor wrote: > Another thought: for non-x86 platforms, the SIMD nodes degenerate to > "simple loop", and looping over up to 32 elements is not great > (although possibly okay). We could do binary search, but that has bad > branch prediction. I'd be quite

Re: [PoC] Improve dead tuple storage for lazy vacuum

> Another thought: for non-x86 platforms, the SIMD nodes degenerate to > "simple loop", and looping over up to 32 elements is not great > (although possibly okay). We could do binary search, but that has bad > branch prediction. I am not sure that for relevant non-x86 platforms SIMD / vector

Re: JSON/SQL: jsonpath: incomprehensible error message

On 2022-06-26 Su 11:44, Erik Rijkers wrote: > JSON/SQL jsonpath > > For example, a jsonpath string with deliberate typo 'like_regexp' > (instead of 'like_regex'): > > select js > from (values (jsonb '{}')) as f(js) > where js @? '$ ? (@ like_regexp "^xxx")'; > > ERROR:  syntax error, unexpected

Re: Making the subquery alias optional in the FROM clause

On Mon, Jun 27, 2022 at 9:49 PM Dean Rasheed wrote: > > This was discussed previously in [1], and there seemed to be general > consensus in favour of it, but no new patch emerged. > > Attached is a patch that takes the approach of not generating an alias > at all, which seems to be neater and

Re: Lazy JIT IR code generation to increase JIT speed with partitions

Hi hackers, I picked this up and had a closer look in which way the total JIT time depends on the number of modules to be jitted. Indeed, the total JIT time increases the more modules are used. The reason for this to happen is that the inlining pass loads and deserializes all to be inlined

Making the subquery alias optional in the FROM clause

This was discussed previously in [1], and there seemed to be general consensus in favour of it, but no new patch emerged. Attached is a patch that takes the approach of not generating an alias at all, which seems to be neater and simpler, and less code than trying to generate a unique alias. It

Emit postgres log messages that have security or PII with special flags/error code/elevel

Hi, Today, postgres doesn't distinguish the log messages that it emits to server logs via ereport/elog mechanism, based on security information or PII (Personally Identifiable Information) or other sensitive information [1]. In production environments, these log messages would be captured and

Re: Add non-blocking version of PQcancel

On 2022-Jun-27, Justin Pryzby wrote: > On Fri, Jun 24, 2022 at 07:36:16PM -0500, Justin Pryzby wrote: > > Apparently there's still an occasional issue. > > https://cirrus-ci.com/task/6613309985128448 > > I think that failure is actually not related to this patch. Yeah, it's not -- Kyotaro

Re: Add non-blocking version of PQcancel

On Fri, Jun 24, 2022 at 07:36:16PM -0500, Justin Pryzby wrote: > Resending with a problematic email removed from CC... > > On Mon, Apr 04, 2022 at 03:21:54PM +, Jelte Fennema wrote: > > 2. Added some extra sleeps to the cancellation test, to remove random > > failures on FreeBSD. > >

Re: Logging query parmeters in auto_explain

Dagfinn Ilmari Mannsåker writes: > Michael Paquier writes: > >> On Thu, Jun 09, 2022 at 11:55:11PM +0100, Dagfinn Ilmari Mannsåker wrote: >>> Done (and more tests added), v3 attached. >> >> One thing I am wondering is if we'd better mention errdetail_params() >> at the top of the initial check

Re: Logging query parmeters in auto_explain

Michael Paquier writes: > On Thu, Jun 09, 2022 at 11:55:11PM +0100, Dagfinn Ilmari Mannsåker wrote: >> Done (and more tests added), v3 attached. > > One thing I am wondering is if we'd better mention errdetail_params() > at the top of the initial check done in ExplainQueryParameters(). > That's

Re: [PoC] Improve dead tuple storage for lazy vacuum

On Mon, Jun 20, 2022 at 7:57 AM Masahiko Sawada wrote: [v3 patch] Hi Masahiko, Since there are new files, and they are pretty large, I've attached most specific review comments and questions as a diff rather than in the email body. This is not a full review, which will take more time -- this

Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

On Mon, Jun 27, 2022 at 1:40 PM Drouvot, Bertrand wrote: > > Hi, > > On 6/27/22 9:31 AM, Hamid Akhtar wrote: > > > Hello Hackers, > > While working on one of my blogs on the B-Tree indexes, I needed to look at a > range of B-Tree page statistics. So the goto solution was to use pageinspect. >

Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)

On Mon, Jun 27, 2022 at 12:04:57AM -0700, Noah Misch wrote: > For me, it reproduces consistently with a sleep just before the startup > process exits: Nice catch. > One can adapt the test to the server behavior by having the test wait for the > archiver to start, as attached. This is sufficient

Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

(resent because it was blocked from the mailing-list due to inclusion of a blocked email address in the To line) From: Andres Freund > On 2022-04-04 15:21:54 +, Jelte Fennema wrote: > > 2. Added some extra sleeps to the cancellation test, to remove random > > failures on FreeBSD. > >

Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row

Hello Hackers, While working on one of my blogs on the B-Tree indexes , I needed to look at a range of B-Tree page statistics. So the goto solution was to use pageinspect. However, reviewing stats for

Re: ICU for global collation

On 27.06.22 08:42, Michael Paquier wrote: On Mon, Jun 27, 2022 at 08:23:59AM +0200, Peter Eisentraut wrote: On 26.06.22 05:51, Julien Rouhaud wrote: On Sat, Jun 25, 2022 at 10:19:30AM -0500, Justin Pryzby wrote: + if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1500) I think the

Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)

On Wed, Feb 16, 2022 at 01:42:27AM +0200, Heikki Linnakangas wrote: > On 15/02/2022 23:28, Tom Lane wrote: > >Heikki Linnakangas writes: > >>That was interesting: the order that WAL segments are archived when a > >>standby is promoted is not fully deterministic. > > > >Oh, of course. > > > >>I

Re: ICU for global collation

On Mon, Jun 27, 2022 at 08:23:59AM +0200, Peter Eisentraut wrote: > On 26.06.22 05:51, Julien Rouhaud wrote: >> On Sat, Jun 25, 2022 at 10:19:30AM -0500, Justin Pryzby wrote: + if (GET_MAJOR_VERSION(old_cluster.major_version) <= 1500) > > I think the fix here is to change <= to < ? Yes. --

Re: PG15 beta1 fix pg_stats_ext/pg_stats_ext_exprs view manual

On Mon, Jun 27, 2022 at 03:49:20AM +, Shinoda, Noriyoshi (PN Japan FSIP) wrote: > Thanks for your comment. sorry for the late reply. > I hope it will be fixed during the period of PostgreSQL 15 Beta. Apologies for the delay, fixed in time for beta2. -- Michael signature.asc Description:

Re: ICU for global collation

On 26.06.22 05:51, Julien Rouhaud wrote: Hi, On Sat, Jun 25, 2022 at 10:19:30AM -0500, Justin Pryzby wrote: commit f2553d43060edb210b36c63187d52a632448e1d2 says >=1500 in a few places, but in pg_upgrade says <=1500, which looks wrong for upgrades from v15. I think it should say <= 1400. On

Re: [BUG] Panic due to incorrect missingContrecPtr after promotion

On Fri, Jun 24, 2022 at 04:17:34PM +, Imseih (AWS), Sami wrote: > It is been difficult to get a generic repro, but the way we reproduce > Is through our test suite. To give more details, we are running tests > In which we constantly failover and promote standbys. The issue > surfaces after we