Re: 回复: An implementation of multi-key sort

On Fri, Jul 26, 2024 at 6:18 PM Yao Wang wrote: > 2. Should we update optimizer to take in account statistic > (pg_statistic->stadistinct) and choose mksort/qsort accordingly? > According to the result, the choosing mechanism in optimizer > almost eliminated all regressions. Please note that eve

Re: On non-Windows, hard depend on uselocale(3)

v4 adds error handling, in case newlocale("C") fails. I created CF entry #5166 for this. From 3543cc04b0d66c7f83bdccbb247eedd93cdea4af Mon Sep 17 00:00:00 2001 From: Thomas Munro Date: Sat, 10 Aug 2024 11:01:21 +1200 Subject: [PATCH v4] Improve locale thread safety of ECPG. Remove the use of set

Re: Remove dependence on integer wrapping

On Mon, Jul 22, 2024 at 5:52 PM Alexander Lakhin wrote: > Also there are several trap-producing cases with date types: > SELECT to_timestamp('10,999', 'Y,YYY'); I attached patch 5 that fixes the to_timestamp overflow. Thank you, Matthew Kim From a01c5d67894de89f14f0dfc54d32e92258a1a3a7

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On 2024-08-10 16:01:18 +0700, John Naylor wrote: > On Tue, Aug 6, 2024 at 9:58 PM John Naylor wrote: > > > > It also turns out that to support 64kB memory settings, we actually > > wouldn't need to change radix tree to lazily create memory contexts -- > > at least currently, SlabCreate doesn't all

Re: Vacuum statistics

On Wed, 12 Jun 2024 at 11:38, Alena Rybakina wrote: > > Hi! > > On 11.06.2024 16:09, Alena Rybakina wrote: > > On 08.06.2024 09:30, Alena Rybakina wrote: > > I am currently working on dividing this patch into three parts to simplify > the review process: one of them will contain code for collecti

Re: Asynchronous MergeAppend

Hi! Thank you for your work on this subject! I think this is a very useful optimization) While looking through your code, I noticed some points that I think should be taken into account. Firstly, I noticed only two tests to verify the functionality of this function and I think that this is not

Re: Vacuum statistics

Hi, Ilia! > Do you consider not to create new table in pg_catalog but to save > statistics in existing table? I mean pg_class or > pg_stat_progress_analyze, pg_stat_progress_vacuum? > Thank you for your interest on our patch! *_progress views is not our case. They hold online statistics whil

Re: is_superuser versus set_config_option's parallelism check

Nathan Bossart writes: > Regarding returning 0 instead of -1 for the parallel case, I think that > follows. While doing some additional research, I noticed this return value > was just added in December (commit 059de3c [0]). Before that, it > apparently assumed that elevel >= ERROR. With that a

Re: SPI_connect, SPI_connect_ext return type

> I'd give it decent odds since our example usage doesn't include the test. > https://www.postgresql.org/docs/current/spi-examples.html https://www.postgresql.org/docs/devel/trigger-example.html > /* connect to SPI manager */ >if ((

Re: is_superuser versus set_config_option's parallelism check

On Sat, Aug 10, 2024 at 12:57:36PM -0400, Tom Lane wrote: > Yeah, the header comment could stand to be improved to make this > clearer. I think there are more conditions being checked now than > existed when the comment was written. But the para right below the > bit you quoted is pretty clear th

Re: Vacuum statistics

Hello, everyone! Thank you for your interesting patch with extended information statistics about autovacuum. Do you consider not to create new table in pg_catalog but to save statistics in existing table? I mean pg_class or pg_stat_progress_analyze, pg_stat_progress_vacuum? P.S. If I sent

Re: XID formatting and SLRU refactorings (was: Add 64-bit XIDs into PostgreSQL 15)

On Sat, Jul 27, 2024 at 07:24:33AM +0900, Michael Paquier wrote: > I've just applied now the remaining pieces down to 17. Comparing commit c9e2457 to the patch in zqgvzsbw5tgkq...@paquier.xyz, the commit lacks the slru.c portion.

Re: SPI_connect, SPI_connect_ext return type

On Sat, Aug 10, 2024 at 9:29 AM Tom Lane wrote: > "David G. Johnston" writes: > > On Saturday, August 10, 2024, Tom Lane wrote: > >> That would break a lot of code (much of it not under our control) to > >> little purpose; it would also foreclose the option to return to using > >> SPI_ERROR_CON

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Sat, Aug 10, 2024 at 7:33 PM Alexander Korotkov wrote: > On Tue, Aug 6, 2024 at 5:17 AM Alexander Korotkov > wrote: > > On Sat, Aug 3, 2024 at 6:07 AM Alexander Korotkov > > wrote: > > > On Sat, Aug 3, 2024 at 3:45 AM Kevin Hale Boyes wrote: > > > > In the for loop in WaitForLSNReplay, sho

Re: is_superuser versus set_config_option's parallelism check

Nathan Bossart writes: > On Fri, Aug 09, 2024 at 06:50:14PM -0400, Tom Lane wrote: >> Also, now that the error depends on which parameter we're talking >> about, I thought it best to include the parameter name in the error >> and to re-word it to be more like all the other can't-set-this-now >> er

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Aug 6, 2024 at 5:17 AM Alexander Korotkov wrote: > On Sat, Aug 3, 2024 at 6:07 AM Alexander Korotkov > wrote: > > On Sat, Aug 3, 2024 at 3:45 AM Kevin Hale Boyes wrote: > > > In the for loop in WaitForLSNReplay, shouldn't the check for in-recovery > > > be moved up above the call to Ge

Re: SPI_connect, SPI_connect_ext return type

"David G. Johnston" writes: > On Saturday, August 10, 2024, Tom Lane wrote: >> That would break a lot of code (much of it not under our control) to >> little purpose; it would also foreclose the option to return to using >> SPI_ERROR_CONNECT someday. > I suggest we document it as deprecated and

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Tue, Aug 6, 2024 at 8:36 AM Michael Paquier wrote: > On Tue, Aug 06, 2024 at 05:17:10AM +0300, Alexander Korotkov wrote: > > The 0001 patch is intended to improve this situation. Actually, it's > > not right to just put RecoveryInProgress() after > > GetXLogReplayRecPtr(), because more wal cou

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Probably QueryCompletion struct fits this purpose best from the existing parameters. Attached draft patch implements returning oid of newly created relation as part of QueryCompletion. Thoughts? I agree, returning the oid of the newly created relation is the best way to solve the problem. (Ex

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Fri, Aug 9, 2024 at 10:18 AM Dmitry Koval wrote: > > This breaks from the CVE-2014-0062 (commit 5f17304) principle of not > > repeating > > name lookups. The attached demo uses this defect to make one partition have > > two parents. > > Thank you very much for information (especially for the

Re: Remove dependence on integer wrapping

On Thu, Aug 8, 2024 at 9:01 PM jian he wrote: > > Should the error about integers be out of range? > > SELECT make_date(-2147483648, 1, 1); > "-2147483648" is not an allowed integer. > > \df make_date > List of functions >Schema | Name| Result data

Re: optimizing pg_upgrade's once-in-each-database steps

On Sat, Aug 10, 2024 at 10:17:27AM -0500, Nathan Bossart wrote: > On Fri, Aug 09, 2024 at 04:06:16PM -0400, Corey Huinker wrote: >>> Furthermore, most of the callbacks should do almost nothing for a given >>> upgrade, and since pg_upgrade runs on the server, client/server round-trip >>> time should

Re: SPI_connect, SPI_connect_ext return type

On Saturday, August 10, 2024, Tom Lane wrote: > Stepan writes: > > Hi, hackers! If you look at the code in the src/backend/executor/spi.c > file, > > you will see the SPI_connect function familiar to many there, which > > internally simply calls SPI_connect_ext. The return type is int, at the >

Re: optimizing pg_upgrade's once-in-each-database steps

On Fri, Aug 09, 2024 at 04:06:16PM -0400, Corey Huinker wrote: >> I'll admit I hadn't really considered pipelining, but I'm tempted to say >> that it's probably not worth the complexity. Not only do most of the tasks >> have only one step, but even tasks like the data types check are unlikely >> t

Re: SPI_connect, SPI_connect_ext return type

> >That would break a lot of code (much of it not under our control) to > little purpose; it would also foreclose the option to return to using > SPI_ERROR_CONNECT someday. > Agree, it makes sense. The only question left is, is there any logic in why in some places its return value of these functi

Re: libpq: Fix lots of discrepancies in PQtrace

On Sat, 10 Aug 2024 at 01:08, Alvaro Herrera wrote: > I don't want to add 4 bytes to struct pg_conn for tracing support. I'm > tempted to make the new struct member a plain 'char' to reduce overhead > for a feature that almost nobody is going to use. According to pahole > we have a 3 bytes hole

Re: is_superuser versus set_config_option's parallelism check

On Fri, Aug 09, 2024 at 06:50:14PM -0400, Tom Lane wrote: > Here's a draft patch to fix it with a flag, now with regression tests. Looks reasonable. > Also, now that the error depends on which parameter we're talking > about, I thought it best to include the parameter name in the error > and to r

Re: Pgoutput not capturing the generated columns

On Thu, 8 Aug 2024 at 10:53, Shubham Khanna wrote: > > On Wed, Aug 7, 2024 at 1:31 PM Peter Smith wrote: > > > > Hi Shubham, > > > > Here are my review comments for patch v24-0001 > > > > I think the TAP tests have incorrect expected results for the nogen-to-gen > > case. > > > > Whereas the HEA

Re: SPI_connect, SPI_connect_ext return type

Stepan writes: > Hi, hackers! If you look at the code in the src/backend/executor/spi.c file, > you will see the SPI_connect function familiar to many there, which > internally simply calls SPI_connect_ext. The return type is int, at the end > it says return SPI_OK_CONNECT; > It confuses me that n

Re: SPI_connect, SPI_connect_ext return type

Regarding checking the return value of these functions, I would also like to add that somewhere in the code before my patch, the value is checked, and somewhere it is not. I removed the check everywhere and it became the same style.

SPI_connect, SPI_connect_ext return type

Hi, hackers! If you look at the code in the src/backend/executor/spi.c file, you will see the SPI_connect function familiar to many there, which internally simply calls SPI_connect_ext. The return type is int, at the end it says return SPI_OK_CONNECT; It confuses me that nothing but OK, judging by

Re: [PATCH] Add log_transaction setting

On Thu, 4 Jul 2024 at 21:46, Sergey Solovev wrote: > > Hi. > > We encountered a problem with excessive logging when transaction is > sampled. > When it is getting sampled every statement is logged, event SELECT. This > can > lead to performance degradation and log polluting. > I have added new set

Re: Restart pg_usleep when interrupted

v9-0001-vaccum_delay-with-absolute-time-nanosleep.patch Description: Binary data v9 has some has some minor corrections to the comments. Regards, Sami

Re: asynchronous commit&synchronous replication

> On 10 Aug 2024, at 17:25, Konstantin Knizhnik wrote: > > So should we take in account sync replication in LR apply worker or not? There was some relevant discussion of this topic on PGCon2020 Unconference [0]. My recollection is that it would be nice to have LR slot setting akin to synchro

Re: Constant Splitting/Refactoring

On Wed, 13 Mar 2024 at 20:42, David Christensen wrote: > > Here is a version 2 of this patch, rebased atop 97d85be365. > > As before, this is a cleanup/prerequisite patch series for the page > features/reserved page size patches[1]. (Said patch series is going > to be updated shortly.) > > This s

asynchronous commit&synchronous replication

Hi hackers, Logical replication apply worker by default switches off asynchronous commit. Cite from documentation of subscription parameters: ``` |synchronous_commit|(|enum|)

Re: Historic snapshot doesn't track txns committed in BUILDING_SNAPSHOT state

Hi, Thanks for the comments! Here are the new version patches, I think it will be more clear. -- Regards, ChangAo Chen v3-0001-Track-transactions-committed-in-BUILDING_SNAPSHOT.patch Description: Binary data v3-0002-Add-test-case-snapshot_build-for-test_decoding.patch Description: Binary d

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

On Tue, Aug 6, 2024 at 9:58 PM John Naylor wrote: > > It also turns out that to support 64kB memory settings, we actually > wouldn't need to change radix tree to lazily create memory contexts -- > at least currently, SlabCreate doesn't allocate a keeper block, so a > newly created slab context rep

Re: EphemeralNamedRelation and materialized view

On Fri, 26 Jul 2024 at 12:07, Yugo Nagata wrote: > > Hi, > > While looking into the commit b4da732fd64e936970f38c792f8b32c4bdf2bcd5, > I noticed that we can create a materialized view using Ephemeral Named > Relation in PostgreSQL 16 or earler. > > > postgres=# create table tbl (i int); > CREATE T

libpq minor TOCTOU violation

I was playing with a static analyzer security scanner and it flagged a time-of-check-time-of-use violation in libpq. I was going to propose a fix for this on -hackers, since you probably can't do anything interesting with this, but then I figured I'd better check here first. libpq checks the