Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?

On Mon, Feb 13, 2023 at 05:10:56PM -0800, Andres Freund wrote: > I just tried to use pg_pwrite_zeros - and couldn't because it doesn't have an > offset parameter. Huh, what lead to the function being so constrained? Its current set of uses cases, where we only use it now to initialize with zeros

Re: Force testing of query jumbling code in TAP tests

On Mon, Feb 13, 2023 at 09:45:12AM -0800, Andres Freund wrote: > Shouldn't there at least be some basic verification of pg_stat_statements > output being sane after running the test? Even if that's perhaps just actually > printing the statements. There is a total of 20k entries in

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

On Tue, Feb 14, 2023 at 5:04 PM Amit Kapila wrote: > > On Fri, Feb 10, 2023 at 8:56 AM Peter Smith wrote: > > > > On Fri, Feb 10, 2023 at 1:32 PM houzj.f...@fujitsu.com > > wrote: > > > > > > On Tuesday, February 7, 2023 11:17 AM Amit Kapila > > > wrote: > > > > > > > > On Mon, Feb 6, 2023 at

RE: Time delayed LR (WAS Re: logical replication restrictions)

Hi, Andres-san On Tuesday, February 14, 2023 1:47 AM Andres Freund wrote: > On 2023-02-11 05:44:47 +, Takamichi Osumi (Fujitsu) wrote: > > On Saturday, February 11, 2023 11:10 AM Andres Freund > wrote: > > > Has there been any discussion about whether this is actually best > > >

Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry

Thanks for the new version. At Mon, 13 Feb 2023 09:58:52 +0100, "Drouvot, Bertrand" wrote in > Hi, > > On 2/13/23 8:40 AM, Kyotaro Horiguchi wrote: > > At Mon, 13 Feb 2023 08:09:50 +0100, "Drouvot, Bertrand" > > wrote in > >>> I think this is useful beyond being able to generate those

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

On Fri, Feb 10, 2023 at 8:56 AM Peter Smith wrote: > > On Fri, Feb 10, 2023 at 1:32 PM houzj.f...@fujitsu.com > wrote: > > > > On Tuesday, February 7, 2023 11:17 AM Amit Kapila > > wrote: > > > > > > On Mon, Feb 6, 2023 at 3:43 PM houzj.f...@fujitsu.com > > > wrote: > > > > > > > > while

Re: ExecRTCheckPerms() and many prunable partitions (sqlsmith)

On Mon, Feb 13, 2023 at 22:31 Tom Lane wrote: > Amit Langote writes: > > On Mon, Feb 13, 2023 at 5:07 Justin Pryzby wrote: > >> That seems to add various elog()s which are hit frequently by sqlsmith: > > > Thanks for the report. I’ll take a look once I’m back at a computer in a > > few days.

Re: Todo: Teach planner to evaluate multiple windows in the optimal order

* Fall back to the full tuple for comparison, but only compare the first +* sortkey if it was abbreviated. Otherwise, only compare second and later +* sortkeys. +*/ + SortTupleComparator comparetup_fallback; + /* * Alter datum1 representation in the SortTuple's array back from the * abbreviated key to the first column value. -- 2.39.1 window-sort-bench-jcn-20230213.ods Description: application/vnd.oasis.opendocument.spreadsheet

Re: Improve logging when using Huge Pages

On Mon, Feb 13, 2023 at 05:22:45PM -0600, Justin Pryzby wrote: > +Reports whether huge pages are in use by the current process. > +See for more information. nitpick: Should this say "server" instead of "current process"? > +static char *huge_pages_active = "unknown"; /*

Re: odd buildfarm failure - "pg_ctl: control file appears to be corrupt"

Hi, Thomas! Thanks for your rapid answer and sorry for my delay with reply. On 01.02.2023 09:45, Thomas Munro wrote: Might add a custom error message for EDEADLK since it absent in errcode_for_file_access()? Ah, good thought. I think it shouldn't happen™, so it's OK that

RE: [PATCH] Reuse Workers and Replication Slots during Logical Replication

On Thur, Feb 7, 2023 15:29 PM I wrote: > On Wed, Feb 1, 2023 20:07 PM Melih Mutlu wrote: > > Thanks for pointing out this review. I somehow skipped that, sorry. > > > > Please see attached patches. > > Thanks for updating the patch set. > Here are some comments. Hi, here are some more comments

Re: Some revises in adding sorting path

I looked at the three patches and have some thoughts: 0001: Does the newly added test have to be this complex? I think it might be better to just come up with the most simple test you can that uses an incremental sort. I really can't think why the test requires a FOR UPDATE, to test incremental

Re: Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS

Hi, On 2023-02-13 18:14:58 -0800, Andrey Borodin wrote: > On Mon, Feb 13, 2023 at 4:39 PM Andres Freund wrote: > > > > The problem I'm talking about is the increased overhead in InstrStopNode(), > > due to BufferUsageAccumDiff() getting more expensive. > > > > Thanks, now I understand the

Re: Time delayed LR (WAS Re: logical replication restrictions)

At Mon, 13 Feb 2023 15:51:25 +0530, Amit Kapila wrote in > I think we can introduce a new variable as last_feedback_time in the > LogicalRepWorker structure and probably for the last_received, we can > last_lsn in MyLogicalRepWorker as that seems to be updated correctly. > I think it would be

Re: Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS

On Mon, Feb 13, 2023 at 4:39 PM Andres Freund wrote: > > The problem I'm talking about is the increased overhead in InstrStopNode(), > due to BufferUsageAccumDiff() getting more expensive. > Thanks, now I understand the problem better. According to godbolt.com my patch doubles the number of

Re: A new strategy for pull-up correlated ANY_SUBLINK

Hi All: Sorry for the delay. Once I saw Tom's reply on Nov 15, I tried his suggestion about "whether we need to restrict the optimization so that it doesn't occur if the subquery contains outer references falling outside available_rels. " quickly, I'm sure such a restriction can fix the bad

Re: Support logical replication of DDLs

FYI - the latest patch cannot be applied. See cfbot [1] -- [1] http://cfbot.cputube.org/patch_42_3595.log Kind Regards, Peter Smith. Fujitsu Australia

Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl

At Mon, 13 Feb 2023 12:18:07 +0900, Michael Paquier wrote in > On Mon, Feb 13, 2023 at 11:27:58AM +0900, Kyotaro Horiguchi wrote: > > I think currently the output by --describe-config can be used only for > > consulting while editing a (possiblly broken) config file. Thus I > > think it's no

Re: Exit walsender before confirming remote flush in logical replication

On 2023-02-14 10:05:40 +0900, Kyotaro Horiguchi wrote: > What do you think about the need for explicitly specifying the > default? I'm fine with specifying the default using a single word, > such as WAIT_FOR_REMOTE_FLUSH. We obviously shouldn't force the option to be present. Why would we want

Re: Move defaults toward ICU in 16?

On Thu, 2023-02-02 at 05:13 -0800, Jeff Davis wrote: > As a project, do we want to nudge users toward ICU as the collation > provider as the best practice going forward? One consideration here is security. Any vulnerability in ICU collation routines could easily become a vulnerability in

Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?

Hi, On 2023-02-12 09:31:36 -0800, Andres Freund wrote: > Another thing: I think we should either avoid iterating over all the IOVs if > we don't need them, or, even better, initialize the array as a constant, once. I just tried to use pg_pwrite_zeros - and couldn't because it doesn't have an

Re: Exit walsender before confirming remote flush in logical replication

At Mon, 13 Feb 2023 08:27:01 +0530, Amit Kapila wrote in > On Mon, Feb 13, 2023 at 7:26 AM Kyotaro Horiguchi > wrote: > > > > IMHO I vaguely don't like that we lose a means to specify the default > > behavior here. And I'm not sure we definitely don't need other than > > flush and immedaite

Re: recovery modules

On Mon, Feb 13, 2023 at 04:55:58PM -0800, Nathan Bossart wrote: > Okay. I've added it back in v12 with the suggested adjustment for the > memory context stuff. Sorry for then noise, cfbot alerted me to a missing #include, which I've added in v13. -- Nathan Bossart Amazon Web Services:

Re: recovery modules

On Mon, Feb 13, 2023 at 03:37:33PM -0800, Andres Freund wrote: > On 2023-02-13 14:56:47 -0800, Nathan Bossart wrote: >> On Mon, Feb 13, 2023 at 04:37:10PM +0900, Michael Paquier wrote: >> > + basic_archive_context = data->context; >> > + if (CurrentMemoryContext == basic_archive_context) >> >

Re: pg_walinspect memory leaks

Hi, On 2023-02-13 15:22:02 -0800, Peter Geoghegan wrote: > More concretely, it looks like GetWALRecordInfo() calls > CStringGetTextDatum/cstring_to_text in a way that accumulates way too > much memory in ExprContext. Additionally, we leak two stringinfos for each record. > This could be

Re: Adding "large" to PG_TEST_EXTRA

Hi, On 2023-02-14 11:38:06 +1100, Peter Smith wrote: > No, nothing specific in mind. But maybe like these: > - tests for causing obscure errors that would never otherwise be > reached without something deliberately designed to fail a certain way I think there's some cases around this that could

Re: Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS

Hi, On 2023-02-13 16:36:25 -0800, Andrey Borodin wrote: > On Mon, Feb 13, 2023 at 4:29 PM Andres Freund wrote: > > > 1. Some more increments on hot paths. We have to add this tiny toll to > > > every single buffer hit, but it will be seldom of any use. > > > > Additionally, I bet it slows down

Re: Adding "large" to PG_TEST_EXTRA

On Tue, Feb 14, 2023 at 10:44 AM Andres Freund wrote: > > Hi, > > On 2023-02-14 09:26:47 +1100, Peter Smith wrote: > > I've observed suggested test cases get rejected as being overkill, or > > because they would add precious seconds to the test execution. OTOH, I > > felt such tests would still

Re: Inconsistency in reporting checkpointer stats

On 2022-12-21 17:14:12 +0530, Nitin Jadhav wrote: > Kindly review and share your comments. This doesn't pass the tests, because the regression tests weren't adjusted: https://api.cirrus-ci.com/v1/artifact/task/5937624817336320/testrun/build/testrun/regress/regress/regression.diffs

Re: Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS

On Mon, Feb 13, 2023 at 4:29 PM Andres Freund wrote: > > 1. Some more increments on hot paths. We have to add this tiny toll to > > every single buffer hit, but it will be seldom of any use. > > Additionally, I bet it slows down EXPLAIN (ANALYZE, BUFFERS) noticeably. It's > already quite

Re: Make EXPLAIN generate a generic plan for a parameterized query

Hi, On 2023-02-05 18:24:03 +0100, Laurenz Albe wrote: > Anyway, attached is v7 that tries to do it that way. This consistently fails on CI: https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3962

Re: Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS

Hi, On 2023-02-13 16:23:30 -0800, Andrey Borodin wrote: > But there are some caveats: > 1. Some more increments on hot paths. We have to add this tiny toll to > every single buffer hit, but it will be seldom of any use. Additionally, I bet it slows down EXPLAIN (ANALYZE, BUFFERS) noticeably.

Re: Add the ability to limit the amount of memory that can be allocated to backends.

Hi, On 2023-01-26 15:27:20 -0500, Reid Thompson wrote: > Yes, just a rebase. There is still work to be done per earlier in the > thread. The tests recently started to fail: https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3867 > I do want to follow up and note re

Buffer usage detailed by RelKind in EXPLAIN ANALYZE BUFFERS

Hi hackers! I was asked to prototype a feature that helps to distinguish shared buffer usage between index reads and heap reads. Practically it looks like this: # explain (analyze,verbose,buffers) select nextval('s'); QUERY PLAN

Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error

Hi, On 2023-02-08 13:10:40 +0100, Alvaro Herrera wrote: > On 2023-Feb-08, Alvaro Herrera wrote: > > > I propose instead the following: each command is prepared just before > > it's executed, as previously, and if we see a \startpipeline, then we > > prepare all commands starting with the one

Re: Support for dumping extended statistics

Hi, On 2023-02-01 04:38:17 +, Hari krishna Maddileti wrote: > Thanks for the update, I have attached the updated patch with > meson compatible and addressed warnings from make file too. This patch consistently crashes in CI:

Re: pglz compression performance, take two

On Mon, Feb 13, 2023 at 4:03 PM Andres Freund wrote: > > Due to the sanitizer changes, and this feedback, I'm marking the entry as > waiting on author. > Thanks Andres! Yes, I plan to make another attempt to refactor this patch on the weekend. If this attempt fails, I think we should just reject

Re: pglz compression performance, take two

Hi, On 2023-02-08 11:16:47 +0100, Tomas Vondra wrote: > On 2/7/23 21:18, Andres Freund wrote: > > > > Independent of this failure, I'm worried about the cost/benefit analysis of > > a > > pglz change that changes this much at once. It's quite hard to review. > > > > I agree. > > I think I

Re: Rework of collation code, extensibility

New version attached. Changes: * I moved the GUC patch to the end (so you can ignore it if it's not useful for review) * I cut out the pg_locale_internal.h rearrangement (at least for now, it might seem useful after the dust settles on the other changes). * I added a separate patch for

Re: Adding "large" to PG_TEST_EXTRA

Hi, On 2023-02-14 09:26:47 +1100, Peter Smith wrote: > I've observed suggested test cases get rejected as being overkill, or > because they would add precious seconds to the test execution. OTOH, I > felt such tests would still help gain some additional percentages from > the "code coverage"

Re: recovery modules

Hi, On 2023-02-13 14:56:47 -0800, Nathan Bossart wrote: > On Mon, Feb 13, 2023 at 04:37:10PM +0900, Michael Paquier wrote: > > + basic_archive_context = data->context; > > + if (CurrentMemoryContext == basic_archive_context) > > + MemoryContextSwitchTo(TopMemoryContext); > > + > > +

Re: Improve logging when using Huge Pages

On Thu, Feb 09, 2023 at 11:29:09AM -0800, Nathan Bossart wrote: > On Thu, Feb 09, 2023 at 10:40:13AM +0100, Alvaro Herrera wrote: > > On 2023-Feb-08, Justin Pryzby wrote: > >> I don't think it makes sense to run postgres -C huge_pages_active, > >> however, so I see no issue that that would always

pg_walinspect memory leaks

It looks like pg_walinspect's GetWALRecordsInfo() routine doesn't take sufficient care with memory management. It should avoid memory leaks of the kind that lead to OOMs whenever pg_get_wal_records_info_till_end_of_wal() has to return very many tuples. Right now it isn't that hard to make that

[PATCH] Fix unbounded authentication exchanges during PQconnectPoll()

Hello, This is closely related to the prior conversation at [1]. There are a couple places in CONNECTION_AWAITING_RESPONSE where libpq will read a huge number of bytes from a server that we really should have hung up on. The attached patch adds a length check for the v2 error compatibility case,

Re: recovery modules

On Mon, Feb 13, 2023 at 04:37:10PM +0900, Michael Paquier wrote: > + basic_archive_context = data->context; > + if (CurrentMemoryContext == basic_archive_context) > + MemoryContextSwitchTo(TopMemoryContext); > + > + if (MemoryContextIsValid(basic_archive_context)) > +

Re: Adding "large" to PG_TEST_EXTRA

On Tue, Feb 14, 2023 at 5:42 AM Andres Freund wrote: > > Hi, > > I'm working on rebasing [1], my patch to make relation extension scale > better. > > As part of that I'd like to add tests for relation extension. To be able to > test the bulk write strategy path, we need to have a few backends

Re: Adding "large" to PG_TEST_EXTRA

On 2023-02-13 Mo 14:34, Andres Freund wrote: Hi, On 2023-02-13 14:15:24 -0500, Stephen Frost wrote: * Andres Freund (and...@anarazel.de) wrote: On 2023-02-13 13:45:41 -0500, Stephen Frost wrote: Are there existing tests that we should add into that set that you're thinking of..? I've been

OID ordering dependency in pg_dump

While starting to poke at the hashed-enum-partition-key problem recently discussed [1], I realized that pg_dump's flagInhAttrs() function has a logic issue: its loop changes state that will be inspected in other iterations of the loop, and there's no guarantee about the order in which related

Re: REASSIGN OWNED vs ALTER TABLE OWNER TO permission inconsistencies

On Wed, Feb 8, 2023 at 5:49 AM Nazir Bilal Yavuz wrote: > My colleague Adam realized that when transferring ownership, 'REASSIGN > OWNED' command doesn't check 'CREATE privilege on the table's schema' on > new owner but 'ALTER TABLE OWNER TO' docs state that: Well, that sucks. > As you can see,

Re: Adding "large" to PG_TEST_EXTRA

Andres Freund writes: > On 2023-02-13 14:55:45 -0500, Tom Lane wrote: >> bigdisk, bigcpu? > Works for me. > I'll probably just add bigdisk as part of adding a test for bulk relation > extensions, mentioning in a comment that we might want bigcpu if we have a > test for it? No objection here.

Re: proposal: psql: psql variable BACKEND_PID

On 13.02.23 18:33, Pavel Stehule wrote: In every real use case you can use pg_backend_pid(), but you need to write a complete name without tab complete, and you need to know so this function is available. BACKEND_PID is supported by  tab complete, and it is displayed in \set list and \?

Re: old_snapshot_threshold bottleneck on replica

Hi, On 2023-01-24 10:46:28 -0500, Robert Haas wrote: > On Mon, Jan 23, 2023 at 9:40 AM Maxim Orlov wrote: > > One of our customers stumble onto a significant performance degradation > > while running multiple OLAP-like queries on a replica. > > After some investigation, it became clear that the

Re: Adding "large" to PG_TEST_EXTRA

On 2023-02-13 14:55:45 -0500, Tom Lane wrote: > bigdisk, bigcpu? Works for me. I'll probably just add bigdisk as part of adding a test for bulk relation extensions, mentioning in a comment that we might want bigcpu if we have a test for it?

Re: Adding "large" to PG_TEST_EXTRA

Andres Freund writes: > On 2023-02-13 13:54:59 -0500, Tom Lane wrote: >> it seems like this class could eventually include tests that run a long time >> but don't necessarily eat disk space. "resource-intensive" is too long. > I'm not sure we'd want to combine time-intensive and

Re: Adding "large" to PG_TEST_EXTRA

Hi, On 2023-02-13 14:15:24 -0500, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > On 2023-02-13 13:45:41 -0500, Stephen Frost wrote: > > > Are there existing tests that we should add into that set that you're > > > thinking of..? I've been working with the Kerberos tests

Re: Adding "large" to PG_TEST_EXTRA

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2023-02-13 13:45:41 -0500, Stephen Frost wrote: > > Are there existing tests that we should add into that set that you're > > thinking of..? I've been working with the Kerberos tests and that's > > definitely one that seems to fit this

Re: Adding "large" to PG_TEST_EXTRA

Hi, On 2023-02-13 13:54:59 -0500, Tom Lane wrote: > Bikeshedding a bit ... is "large" the right name? It's not awful but > I wonder if there is a better one I did wonder about that too. But didn't come up with something more poignant. > it seems like this class could eventually include tests

Re: Adding "large" to PG_TEST_EXTRA

Hi, On 2023-02-13 13:45:41 -0500, Stephen Frost wrote: > Are there existing tests that we should add into that set that you're > thinking of..? I've been working with the Kerberos tests and that's > definitely one that seems to fit this description... I think the kerberos tests are already

Re: Adding "large" to PG_TEST_EXTRA

Andres Freund writes: > As part of that I'd like to add tests for relation extension. To be able to > test the bulk write strategy path, we need to have a few backends concurrently > load > 16MB files. > It seems pretty clear that doing that on all buildfarm machines wouldn't be > nice / welcome.

Re: ICU locale validation / canonicalization

On Fri, 2023-02-10 at 22:50 -0500, Robert Haas wrote: > The fact that you're figuring out how it all works from reading the > source code does not give me a warm feeling. Right. On the other hand, the behavior is quite well documented, it was just the keyword that was undocumented (or I didn't

[PATCH] Align GSS and TLS error handling in PQconnectPoll()

Hi all, During the gssencmode CVE discussion, we noticed that PQconnectPoll() handles the error cases for TLS and GSS transport encryption slightly differently. After TLS fails, the connection handle is dead and future calls to PQconnectPoll() return immediately. But after GSS encryption fails,

Re: Making Vars outer-join aware

On Mon, Feb 13, 2023 at 03:33:15PM +0800, Richard Guo wrote: > On Mon, Feb 13, 2023 at 7:58 AM Justin Pryzby wrote: > > The patch broke this query: > > > > select from pg_inherits inner join information_schema.element_types > > right join (select from pg_constraint as sample_2) on true > > on

Re: Adding "large" to PG_TEST_EXTRA

Greetings, * Andres Freund (and...@anarazel.de) wrote: > I'm working on rebasing [1], my patch to make relation extension scale > better. > > As part of that I'd like to add tests for relation extension. To be able to > test the bulk write strategy path, we need to have a few backends

Adding "large" to PG_TEST_EXTRA

Hi, I'm working on rebasing [1], my patch to make relation extension scale better. As part of that I'd like to add tests for relation extension. To be able to test the bulk write strategy path, we need to have a few backends concurrently load > 16MB files. It seems pretty clear that doing that

Re: Killing off removed rels properly

Richard Guo writes: > On Sat, Feb 11, 2023 at 4:50 AM Tom Lane wrote: >> I think it's time to clean this up by removing the rel from the >> planner data structures altogether. The attached passes check-world, >> and if it does trigger any problems I would say that's a clear >> sign of bugs

Re: ERROR: permission info at index 1 ....

On 2023-Feb-13, Tom Lane wrote: > tender wang writes: > >After a61b1f74823c commit, below query reports error: > > create table perm_test1(a int); > > create table perm_test2(b int); > > select subq.c0 > > from (select (select a from perm_test1 order by a limit 1) as c0, b as c1 > > from

Re: run pgindent on a regular basis / scripted manner

On Mon, 13 Feb 2023 at 17:47, Andrew Dunstan wrote: > OK, but I'd like to hear from more people about what they want. Experience > tells me that making assumptions about how people work is not a good idea. I > doubt anyone's work pattern is like mine. I don't want to implement an option > that

Re: proposal: psql: psql variable BACKEND_PID

po 13. 2. 2023 v 18:52 odesílatel Tom Lane napsal: > Andres Freund writes: > > On 2023-02-13 18:06:23 +0100, Peter Eisentraut wrote: > >> But what do you need the backend PID for in the first place? > > > For me it's using gdb, pidstat, strace, perf, ... > > But for those %p in the PROMPTs is

Re: Rework LogicalOutputPluginWriterUpdateProgress

Hi, On 2023-02-13 14:06:57 +0530, Amit Kapila wrote: > > > The patch calls update_progress in change_cb_wrapper and other > > > wrappers which will miss the case of DDLs that generates a lot of data > > > that is not processed by the plugin. I think for that we either need > > > to call

Re: Rework LogicalOutputPluginWriterUpdateProgress

Hi, On 2023-02-13 08:22:34 +0530, Amit Kapila wrote: > On Sat, Feb 11, 2023 at 3:04 AM Andres Freund wrote: > > > > > One difference I see with the patch is that I think we will end up > > > sending keepalive for empty prepared transactions even though we don't > > > skip sending begin/prepare

Re: proposal: psql: psql variable BACKEND_PID

Hi, On 2023-02-13 12:52:23 -0500, Tom Lane wrote: > Andres Freund writes: > > E.g. I fire of a query, it's slower than I'd like, I want to attach perf. Of > > course I can establish a separate connection, query pg_stat_activity there, > > and then perf. But that requires manually filtering

Re: proposal: psql: psql variable BACKEND_PID

Andres Freund writes: > On 2023-02-13 18:06:23 +0100, Peter Eisentraut wrote: >> But what do you need the backend PID for in the first place? > For me it's using gdb, pidstat, strace, perf, ... > But for those %p in the PROMPTs is more useful. Indeed, because ... > E.g. I fire of a query, it's

Re: Force testing of query jumbling code in TAP tests

Hi, On 2023-02-13 14:00:36 +0900, Michael Paquier wrote: > With this addition, the query jumbling gets covered at 95%~, while > https://coverage.postgresql.org/src/backend/nodes/index.html reports > currently 35%. > > Thoughts or comments? Shouldn't there at least be some basic verification of

Re: proposal: psql: psql variable BACKEND_PID

Hi, On 2023-02-13 18:06:23 +0100, Peter Eisentraut wrote: > On 09.02.23 10:11, Pavel Stehule wrote: > > first and main (for me) - I can use psql variables tab complete - just > > :B - it is significantly faster > > second - I can see all connection related information by \set > > third - there is

Re: Use pg_pwritev_with_retry() instead of write() in dir_open_for_write() to avoid partial writes?

On 2023-02-13 18:33:34 +0900, Kyotaro Horiguchi wrote: > At Mon, 13 Feb 2023 10:15:03 +0530, Bharath Rupireddy > wrote in > > On Sun, Feb 12, 2023 at 11:01 PM Andres Freund wrote: > > > > > > On 2023-02-12 19:59:00 +0530, Bharath Rupireddy wrote: > > > > /* Prepare to write out a lot of

Re: proposal: psql: psql variable BACKEND_PID

po 13. 2. 2023 v 18:06 odesílatel Peter Eisentraut < peter.eisentr...@enterprisedb.com> napsal: > On 09.02.23 10:11, Pavel Stehule wrote: > > first and main (for me) - I can use psql variables tab complete - just > > :B - it is significantly faster > > second - I can see all connection related

Re: ERROR: permission info at index 1 ....

tender wang writes: >After a61b1f74823c commit, below query reports error: > create table perm_test1(a int); > create table perm_test2(b int); > select subq.c0 > from (select (select a from perm_test1 order by a limit 1) as c0, b as c1 > from perm_test2 where false order by c0, c1) as subq

Re: proposal: psql: psql variable BACKEND_PID

On 09.02.23 10:11, Pavel Stehule wrote: first and main (for me) - I can use psql variables tab complete - just :B - it is significantly faster second - I can see all connection related information by \set third - there is not hook on reconnect in psql - so if you implement BACKEND_PID by self,

Re: ExecRTCheckPerms() and many prunable partitions (sqlsmith)

Amit Langote writes: > On Mon, Feb 13, 2023 at 5:07 Justin Pryzby wrote: >> That seems to add various elog()s which are hit frequently by sqlsmith: > Thanks for the report. I’ll take a look once I’m back at a computer in a > few days. Looks like we already have a diagnosis and fix [1]. I'll

BRIN indexes vs. SK_SEARCHARRAY (and preprocessing scan keys)

Hi, while experimenting with BRIN indexes after a couple FOSDEM discussions, I ran into the existing limitation that BRIN indexes don't handle array scan keys. So BRIN indexes can be used for conditions like WHERE a IN (1,2,3,4,5) but we essentially treat the values as individual scan keys,

Re: Making Vars outer-join aware

Richard Guo writes: > Thanks for the report! I've looked at it a little bit and traced down > to function have_unsafe_outer_join_ref(). The comment there says > * In practice, this test never finds a problem ... > This seems not correct as showed by the counterexample. Right. I'd noticed

Re: run pgindent on a regular basis / scripted manner

On 2023-02-13 Mo 09:02, Jelte Fennema wrote: On Sun, 12 Feb 2023 at 15:16, Andrew Dunstan wrote: I'm not sure how much more I really want to do here. Given the way pgindent now processes command line arguments, maybe the best thing is for people to use that. Use of git aliases can help.

Re: Time delayed LR (WAS Re: logical replication restrictions)

Hi, On 2023-02-11 05:44:47 +, Takamichi Osumi (Fujitsu) wrote: > On Saturday, February 11, 2023 11:10 AM Andres Freund > wrote: > > Has there been any discussion about whether this is actually best > > implemented on the client side? You could alternatively implement it on the > > sender. >

Re: [PATCH] Support SK_SEARCHNULL / SK_SEARCHNOTNULL for heap-only scans

Hi, On 2023-02-13 17:59:13 +0300, Aleksander Alekseev wrote: > @@ -36,20 +36,36 @@ HeapKeyTest(HeapTuple tuple, TupleDesc tupdesc, int > nkeys, ScanKey keys) > boolisnull; > Datum test; > > - if (cur_key->sk_flags & SK_ISNULL) > -

ERROR: permission info at index 1 ....

Hi hackers, After a61b1f74823c commit, below query reports error: create table perm_test1(a int); create table perm_test2(b int); select subq.c0 from (select (select a from perm_test1 order by a limit 1) as c0, b as c1 from perm_test2 where false order by c0, c1) as subq where false; ERROR:

Re: Helper functions for wait_for_catchup() in Cluster.pm

Hi, On 2/13/23 11:58 AM, Alvaro Herrera wrote: On 2023-Jan-26, Drouvot, Bertrand wrote: Hi, On 1/26/23 10:42 AM, Alvaro Herrera wrote: On 2023-Jan-26, Drouvot, Bertrand wrote: On 1/24/23 7:27 PM, Alvaro Herrera wrote: 1. I don't think wait_for_write_catchup is necessary, because

[PATCH] Support SK_SEARCHNULL / SK_SEARCHNOTNULL for heap-only scans

Hi hackers, A colleague of mine wanted to use a ScanKey with SK_SEARCHNULL flag for a heap-only scan (besides other ScanKeys) and discovered that the result differs from what he would expect. Turned out that this is currently not supported as it is explicitly stated in skey.h. Although several

Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf

On Mon, 13 Feb 2023 at 15:06, Pavel Luzanov wrote: > Does it make sense to reflect changes to the PG-USERNAME field in the > pg_ident.conf.sample file? > > The same relates to the regexp supportin the DATABASE and USER fieldsof > the pg_hba.conf.sample file(8fea8683). That definitely makes sense

Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf

Hello, Playing with this patch, I did not see descriptive comments in pg_ident.conf. Does it make sense to reflect changes to the PG-USERNAME field in the pg_ident.conf.sample file? The same relates to the regexp supportin the DATABASE and USER fieldsof the pg_hba.conf.sample

Re: run pgindent on a regular basis / scripted manner

On Sun, 12 Feb 2023 at 15:16, Andrew Dunstan wrote: > I'm not sure how much more I really want to do here. Given the way pgindent > now processes command line arguments, maybe the best thing is for people to > use that. Use of git aliases can help. Something like these for example > > > [alias]

Re: amvalidate(): cache lookup failed for operator class 123

On Thu, May 13, 2021 at 12:01:22PM -0500, Justin Pryzby wrote: > postgres=# select amvalidate(123); > ERROR: cache lookup failed for operator class 123 > The usual expectation is that sql callable functions should return null rather > than hitting elog(). On Thu, May 13, 2021 at 2:22 PM Tom Lane

Re: run pgindent on a regular basis / scripted manner

On 2023-02-12 Su 16:13, Tom Lane wrote: Andrew Dunstan writes: On 2023-02-12 Su 11:24, Tom Lane wrote: It seems like "indent the whole tree" is about to become a minority use-case. Maybe instead of continuing to privilege that case, we should say that it's invoked by some new switch like

Re: run pgindent on a regular basis / scripted manner

On 2023-02-12 Su 15:59, Justin Pryzby wrote: It seems like if pgindent knows about git, it ought to process only tracked files. Then, it wouldn't need to manually exclude generated files, and it wouldn't process vpath builds and who-knows-what else it finds in CWD. for vpath builds use an

Re: [PATCH] Add pretty-printed XML output option

On 13.02.23 02:15, Peter Smith wrote: Something is misbehaving. Using the latest HEAD, and before applying the v6 patch, 'make check' is working OK. But after applying the v6 patch, some XML regression tests are failing because the DETAIL part of the message indicating the wrong syntax

Making CopyFromStateData not internal anymore

For Citus we'd like to hook into the way that GENERATED AS IDENTITY generates the next value. The way we had in mind was to replace T_NextValueExpr with a function call node. But doing that same for COPY seems only possible by manually changing the defexprs array of the CopyFromState. Sadly

Re: Can we do something to help stop users mistakenly using force_parallel_mode?

On Sat, 11 Feb 2023 at 04:34, Andrew Dunstan wrote: > > On 2023-02-09 Th 15:25, David Rowley wrote: > Likely the hardest part to get right here is the new name. Can anyone > think of anything better than debug_parallel_query? > > > WFM Thanks for chipping in. I've attached a patch which fixes

RE: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher

On Thu, Feb 2, 2023 4:34 PM Önder Kalacı wrote: > >> >> and if there's more >> than one candidate index pick any one. Additionally, we can allow >> disabling the use of an index scan for this particular case. If we are >> too worried about API change for allowing users to specify the index >>

Re: Helper functions for wait_for_catchup() in Cluster.pm

On 2023-Jan-26, Drouvot, Bertrand wrote: > Hi, > > On 1/26/23 10:42 AM, Alvaro Herrera wrote: > > On 2023-Jan-26, Drouvot, Bertrand wrote: > > > > > On 1/24/23 7:27 PM, Alvaro Herrera wrote: > > > > > > 1. I don't think wait_for_write_catchup is necessary, because > > > > calling

Re: psql - factor out echo code

On 01.12.22 08:27, Pavel Stehule wrote: st 30. 11. 2022 v 10:43 odesílatel Fabien COELHO > napsal: >> Now some of the output generated by test_extdepend gets a bit >> confusing: >> +-- QUERY: >> + >> + >> +-- QUERY: >> >>

Re: Rework of collation code, extensibility

On 01.02.23 00:33, Jeff Davis wrote: On Tue, 2023-01-31 at 11:40 +0100, Peter Eisentraut wrote: I don't know to what extent this depends on the abbreviated key GUC discussion.  Does the rest of this patch set depend on this? The overall refactoring is not dependent logically on the GUC patch.

  1   2   >