On Mon, Jul 08, 2024 at 06:39:56AM +, Bertrand Drouvot wrote:
> + for (int kind = PGSTAT_KIND_FIRST_VALID; kind <= PGSTAT_KIND_LAST;
> kind++)
> + {
> + char *ptr;
> + const PgStat_KindInfo *info = pgstat_get_kind_info(kind);
>
> I wonder if we co
Hi,
On Mon, Jul 08, 2024 at 02:30:23PM +0900, Michael Paquier wrote:
> On Fri, Jul 05, 2024 at 09:35:19AM +0900, Michael Paquier wrote:
> > On Thu, Jul 04, 2024 at 11:30:17AM +, Bertrand Drouvot wrote:
> >> On Wed, Jul 03, 2024 at 06:47:15PM +0900, Michael Paquier wrote:
> >>> - PgStat_Snapsho
On 2024/07/01 18:15, Jelte Fennema-Nio wrote:
On Thu, 27 Jun 2024 at 12:27, ikedarintarof
wrote:
Thanks for your suggestion. I used ChatGPT to choose the wording, but
it's still difficult for me.
Looks good to me now (but obviously biased since you took my wording).
LGTM, too.
* Valid
Hi,
On Mon, Jul 08, 2024 at 11:20:45AM +0530, Amit Kapila wrote:
> On Mon, Jul 8, 2024 at 11:08 AM Bertrand Drouvot
> wrote:
> >
> > On Mon, Jul 08, 2024 at 08:46:19AM +0530, Amit Kapila wrote:
> > > This sounds better but it is better to add just before we determine
> > > am_cascading_walsender
On Fri, Jun 28, 2024 at 9:06 PM Amit Kapila wrote:
>
> On Fri, Jun 28, 2024 at 9:44 AM Masahiko Sawada wrote:
> >
> > # Benchmark results
> >
> > * Test-1: parallel heap scan on the table without indexes
> >
> > I created 20GB table, made garbage on the table, and run vacuum while
> > changing pa
On Fri, Jul 5, 2024 at 6:51 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Sawada-san,
>
> > The parallel vacuum we have today supports only for index vacuuming.
> > Therefore, while multiple workers can work on different indexes in
> > parallel, the heap table is always processed by the single proces
Hi feichanghong
I think adding an intercept this way is better than implementing a
global temp table,there is a path to implement a global temporary table (
https://www.postgresql.org/message-id/1a1a6edc-d0ec-47b0-bd21-c2acbaea6...@alibaba-inc.com),you
can consult with them ,they work at Alib
On Mon, Jul 8, 2024 at 1:16 PM David Rowley wrote:
>
>
> Updated patch attached.
>
looking good to me.
On Mon, Jul 8, 2024 at 11:08 AM Bertrand Drouvot
wrote:
>
> On Mon, Jul 08, 2024 at 08:46:19AM +0530, Amit Kapila wrote:
> > This sounds better but it is better to add just before we determine
> > am_cascading_walsender as is done in the attached. What do you think?
>
> Thanks! LGTM.
>
I would li
On 6/24/24 19:57, Peter Eisentraut wrote:
On 24.06.24 02:34, Michael Paquier wrote:
On Sat, Jun 22, 2024 at 11:48:21AM -0400, Tom Lane wrote:
Peter Eisentraut writes:
On 18.06.24 13:43, Ranier Vilela wrote:
I found another implementation of strsep, it seems lighter to me.
I will attach it fo
Hi,
On Mon, Jul 08, 2024 at 08:46:19AM +0530, Amit Kapila wrote:
> This sounds better but it is better to add just before we determine
> am_cascading_walsender as is done in the attached. What do you think?
Thanks! LGTM.
>
> BTW, is it possible that the promotion gets completed after we wait
>
On Fri, Jul 05, 2024 at 09:35:19AM +0900, Michael Paquier wrote:
> On Thu, Jul 04, 2024 at 11:30:17AM +, Bertrand Drouvot wrote:
>> On Wed, Jul 03, 2024 at 06:47:15PM +0900, Michael Paquier wrote:
>>> - PgStat_Snapshot holds an array of void* also indexed by
>>> PGSTAT_NUM_KINDS, pointing to th
Here are review comments for v15-0001
==
doc/src/sgml/ddl.sgml
nitpick - there was a comma (,) which should be a period (.)
==
.../libpqwalreceiver/libpqwalreceiver.c
1.
+ if (options->proto.logical.include_generated_columns &&
+ PQserverVersion(conn->streamConn) >= 17)
+ appendStri
On Mon, 8 Jul 2024 at 16:43, jian he wrote:
> { oid => '2031',
> proname => 'timestamp_mi', prorettype => 'interval',
> proargtypes => 'timestamp timestamp', prosrc => 'timestamp_mi' },
> { oid => '1188',
> proname => 'timestamptz_mi', prorettype => 'interval',
> proargtypes => 'timestampt
On Mon, Jul 8, 2024 at 12:02 PM David Rowley wrote:
>
> > /*
> > * Protect against overflows in timestamp_mi. XXX convert to
> > * ereturn one day?
> > */
> > if (!TIMESTAMP_NOT_FINITE(start) && !TIMESTAMP_NOT_FINITE(finish) &&
> > !pg_sub_s64_overflow(finish, start, &dummy))
> >
> > i don't unde
Hi wenhui,
> On Jul 8, 2024, at 12:18, wenhui qiu wrote:
>
> Hi feichanghong
> I don't think it's acceptable to introduce a patch to fix a problem that
> leads to performance degradation, or can we take tom's suggestion to optimise
> PreCommit_on_commit_actions? I think it to miss the for
Hi,
I researched about how to detect the resolve update_deleted and thought
about one idea: which is to maintain the xmin in logical slot to preserve
the dead row and support latest_timestamp_xmin resolution for
update_deleted to maintain data consistency.
Here are details of the xmin idea and re
Hi feichanghong
I don't think it's acceptable to introduce a patch to fix a problem
that leads to performance degradation, or can we take tom's suggestion to
optimise PreCommit_on_commit_actions? I think it to miss the forest for
the trees
Best Regards,
feichanghong 于2024年7月8日周一 10:35写道：
On Mon, 8 Jul 2024 at 14:50, jian he wrote:
>
> looks good to me.
Thanks for looking.
> /*
> * Protect against overflows in timestamp_mi. XXX convert to
> * ereturn one day?
> */
> if (!TIMESTAMP_NOT_FINITE(start) && !TIMESTAMP_NOT_FINITE(finish) &&
> !pg_sub_s64_overflow(finish, start, &dummy)
On Sun, 18 Feb 2024 at 11:31, Tomas Vondra
wrote:
> 2) Leader vs. worker counters
>
> It seems to me this does nothing to add the per-worker values from "Heap
> Blocks" into the leader, which means we get stuff like this:
>
> Heap Blocks: exact=102 lossy=10995
> Worker 0: actual time=50.5
+ context_item can be any character string that
+ can be succesfully cast to jsonb.
typo: "succesfully", should be "successfully"
maybe rephrase it to:
+ context_item can be jsonb type or any
character string that
+ can be successfully cast to jsonb.
+ON EMPTY expression (that i
On Sat, Jul 6, 2024 at 7:36 PM Bertrand Drouvot
wrote:
>
> On Fri, Jul 05, 2024 at 11:10:00AM +0530, Amit Kapila wrote:
> > On Fri, Jun 28, 2024 at 6:30 PM Bertrand Drouvot
> > wrote:
> > >
> > > On Fri, Jun 28, 2024 at 03:15:22PM +0530, Amit Kapila wrote:
> > > > On Fri, Jun 28, 2024 at 12:55 PM
From: Fujii Masao
Sent: Wednesday, July 3, 2024 7:44 PM
>
> On 2024/07/03 17:51, hajime.matsun...@nttdata.com wrote:
> > Thanks for the suggestions the other day.
> > I have created a patch that incorporates your suggestions.
>
> -pg_stat_database, in the output of
> +pg_stat_d
looks good to me.
some minor questions:
/*
* Protect against overflows in timestamp_mi. XXX convert to
* ereturn one day?
*/
if (!TIMESTAMP_NOT_FINITE(start) && !TIMESTAMP_NOT_FINITE(finish) &&
!pg_sub_s64_overflow(finish, start, &dummy))
i don't understand the comment "XXX convert to ereturn on
On Mon, 8 Jul 2024 at 12:19, David Rowley wrote:
> Notice the "Heap Blocks: exact=225000" is missing on Windows.
> This is because it wrapped around to a negative value and
> show_tidbitmap_info() only shows > 0 values.
>
> I feel this is a good enough justification to increase the width of
>
On Mon, Jul 8, 2024 at 7:49 AM Richard Guo wrote:
> On Sun, Jul 7, 2024 at 5:43 PM Junwang Zhao wrote:
> > I think the period here should be a typo.
> >
> > index 16b5803d388..af3b15e93df 100644
> > --- a/src/backend/storage/ipc/procarray.c
> > +++ b/src/backend/storage/ipc/procarray.c
> > @@ -18
Hi wenhui,
Thank you for your suggestions. I have supplemented some performance tests.
Here is the TPS performance data for different numbers of temporary tables
under different thresholds, as compared with the head (98347b5a). The testing
tool used is pgbench, with the workload being to insert
On Mon, Jul 08, 2024 at 01:03:42AM +0900, Fujii Masao wrote:
> If this has already been discussed and the current behavior is deemed proper,
> I'm sorry for bringing it up again. Even in that case, it would be helpful
> to document that USAGE privilege on the schema may be necessary in addition
> t
On Mon, Jul 1, 2024 at 11:45 AM Laurenz Albe
wrote:
> I asked them for a statement, and they were nice enough to write up
> https://postgr.es/m/e89e8dd9-7143-4db8-ac19-b2951cb0c0da%40gmail.com
> They have a workaround, so the patch is not absolutely necessary for them.
It sounds like the issue
On Mon, Jul 08, 2024 at 01:03:42AM +0900, Fujii Masao wrote:
> I've noticed an issue with non-superusers who have the pg_maintain role.
> When they run VACUUM on a specific table within a specific schema,
> like "VACUUM mynsp.mytbl", it fails if they don't have the USAGE privilege
> on the schema.
On Sun, 14 Apr 2024 at 15:14, David Rowley wrote:
> I had some spare time today, so wrote a patch, which gives you:
>
> postgres=# explain analyze select * from generate_series('2024-01-01',
> '2025-01-01', interval '1 day');
> QUERY PLAN
> -
On Fri, Jul 05, 2024 at 02:19:54PM +0900, Michael Paquier wrote:
> As of this stage of the game for v17, I am going to agree with (2) to
> remove this inconsistency rather than experiment with new things. We
> could always study more in v18 what could be done with the /D switches
> and the other p
NextCopyFrom, currently, it is:
--
if (cstate->defaults[m])
{
..
}
/*
* If ON_ERROR is specified with IGNORE, skip rows with soft
* errors
*/
else if (!InputFunctionCallSafe(&in_functions[m],
string,
typioparams[m],
att->atttypmod,
(Node *) cstate->escontext,
&values[m]))
{
Assert(
On Fri, 5 Jul 2024 at 12:52, David Rowley wrote:
> I propose we change these to uint64 while causing churn in this area,
> probably as a follow-on patch. I think a uint32 isn't wide enough as
> you could exceed the limit with rescans.
I wondered how large a query it would take to cause this prob
On Sun, Jul 7, 2024 at 5:43 PM Junwang Zhao wrote:
> I think the period here should be a typo.
>
> index 16b5803d388..af3b15e93df 100644
> --- a/src/backend/storage/ipc/procarray.c
> +++ b/src/backend/storage/ipc/procarray.c
> @@ -185,7 +185,7 @@ typedef struct ComputeXidHorizonsResult
> F
On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> I've also tidied up a bit by replacing all instances of SHRT_MAX with
> a new constant NUMERIC_WEIGHT_MAX, whose name more accurately
> describes the limit, as used in various other overflow checks.
Having thought a bit more on this, I think we
On Sun, Jul 07, 2024 at 12:21:26PM +0200, Dmitry Dolgov wrote:
> From what I understand, coordinating custom RmgrIds via a wiki page was
> made under the assumption that implementing a table AM with custom WAL
> requires significant efforts, which limits the demand for ids. This
> might not be same
Hi Bruce.
> From: Bruce Momjian
> Is there a reason the documentation is no longer a part of this patch?
> Can I help you keep it current?
Here are the reasons:
Reason1. The approach differs significantly from the previous patch that
included documentation, the below.
https://www.postgre
Hi Jelte and hackers,
I've reconsidered which of the following two approaches is the best.
Approach1: Adding export/import functions to transmit state values.
Approach 2: Adding native types which are equal to state values.
In my mind, Approach1 is superior. Therefore, if there are no objecti
I wrote:
> I saw that one. It would be good to have a replacement for
> xmlParseBalancedChunkMemory, because after looking at the libxml2
> sources I realize that that's classed as a SAX1 function, which means
> it will likely go away at some point (maybe it's already not there in
> some builds).
Hello hackers,
I'm not hopeful this idea will be fruitful, but maybe we can find solutions
to the problems together.
The idea is to increase the numeric NBASE from 1e4 to 1e8, which could possibly
give a significant performance boost of all operations across the board,
on 64-bit architectures, fo
Hello hackers,
This patch adds a mul_var_large() that is dispatched to from mul_var()
for var1ndigits >= 8, regardless of rscale.
The main idea with mul_var_large() is to reduce the "n" in O(n^2) by a factor
of two.
This is achieved by first converting the (ndigits) number of int16 NBASE digits,
I wrote:
> I think we could work around it as attached. This relies on seeing
> that the 2.13 code will return a node list if and only if
> ctxt->wellFormed is true (and we already eliminated the empty-input
> case, so an empty node list shouldn't happen). But it's not a lot
> less ugly than your
Erik Wienhold writes:
> On 2024-07-06 20:43 +0200, Tom Lane wrote:
>> I'm disinclined to spend much effort on working around dot-zero bugs.
> Found an open issue about ABI compatibility that affects 2.12.7 and
> possibly also 2.13: https://gitlab.gnome.org/GNOME/libxml2/-/issues/751.
> Maybe just
On 2024-07-06 20:43 +0200, Tom Lane wrote:
> One angle that ought to be considered is that some of this stuff may
> be flat-out bugs in 2.13.0. I see at
>
> https://gitlab.gnome.org/GNOME/libxml2/-/releases
>
> that both 2.13.1 and 2.13.2 contain fixes for "regressions" in 2.13.0.
> I'm disincli
On 7/5/24 21:45, Matthias van de Meent wrote:
> On Wed, 3 Jul 2024 at 20:36, Matthias van de Meent
> wrote:
>>
>> On Mon, 24 Jun 2024 at 02:58, Tomas Vondra
>> wrote:
>>> So I've switched this to use the regular data-type comparisons, with
>>> SortSupport etc. There's a bit more cleanup remaining
On 7/3/24 20:36, Matthias van de Meent wrote:
> On Mon, 24 Jun 2024 at 02:58, Tomas Vondra
> wrote:
>>
>> Here's a bit more cleaned up version, clarifying a lot of comments,
>> removing a bunch of obsolete comments, or comments speculating about
>> possible solutions, that sort of thing. I've a
Hi,
I've noticed an issue with non-superusers who have the pg_maintain role.
When they run VACUUM on a specific table within a specific schema,
like "VACUUM mynsp.mytbl", it fails if they don't have the USAGE privilege
on the schema. For example, the error message logged is
"ERROR: permission den
On Fri, Jun 28, 2024 at 05:36:25PM -0400, Melanie Plageman wrote:
> I've attached a WIP v11 streaming vacuum patch set here that is
> rebased over master (by Thomas), so that I could add a CF entry for
> it. It still has the problem with the extra WAL write and fsync calls
> investigated by Thomas
On Sun, Jul 7, 2024, at 13:28, Dean Rasheed wrote:
> The numeric round() and trunc() functions clamp the scale argument to
> the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
> That's a long way short of the actual allowed range of type numeric,
> so they produce incorrect results
🔥
On Sun, Jul 7, 2024, 7:44 AM Joel Jacobson wrote:
> On Sat, Jul 6, 2024, at 17:36, Dean Rasheed wrote:
> > In the numeric width_bucket() code, we currently do the following:
> ..
> > Instead, this can be done more simply and efficiently, using division
> > with truncation as follows:
> ..
> >
Hi feichanghong
Thanks for updating the patch ,I think could be configured as a GUC
parameter,PostgreSQL has too many static variables that are written to
death and explicitly stated in the code comments may later be designed as
parameters. Now that more and more applications that previously u
On 2024-07-07 Su 7:28 AM, Andrew Dunstan wrote:
On 2024-07-07 Su 3:02 AM, Andres Freund wrote:
Hi,
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with
TMP/TEMP
located
On Sat, Jul 6, 2024, at 17:36, Dean Rasheed wrote:
> In the numeric width_bucket() code, we currently do the following:
..
> Instead, this can be done more simply and efficiently, using division
> with truncation as follows:
..
>
> Patch attached. I didn't bother with any new test cases, since ther
Hello everybody,
On 12.06.2024 20:13, Igor V.Gnatyuk wrote:
Hello.
Before the advent of procedures in PostgreSQL 11 that can manage
transactions, there could only be one transaction
in one statement. Hence the end of the transaction also meant the end
of the statement. Apparently, this is why
The numeric round() and trunc() functions clamp the scale argument to
the range between +/- NUMERIC_MAX_RESULT_SCALE, which is +/- 2000.
That's a long way short of the actual allowed range of type numeric,
so they produce incorrect results when rounding/truncating more than
2000 digits before or af
On 2024-07-07 Su 3:02 AM, Andres Freund wrote:
Hi,
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with TMP/TEMP
located on c:, the tested code on d:. This causes the foll
As part of making tuplestores faster [1], I noticed that in WindowAgg, when
we end one partition we call tuplestore_end() and then we do
tuplestore_begin_heap() again for the next partition in begin_partition()
and then go on to set up the tuplestore read pointers according to what's
required for t
On 2024-07-07 Su 1:26 AM, Tom Lane wrote:
Andres Freund writes:
Do we want to support checking out with core.autocrlf?
-1. It would be a constant source of breakage, and you could never
expect that (for example) making a tarball from such a checkout
would match anyone else's results.
Yea
> On Fri, Jun 21, 2024 at 01:28:11PM +0900, Michael Paquier wrote:
> On Fri, Jun 21, 2024 at 01:09:10PM +0900, Kyotaro Horiguchi wrote:
> > At Thu, 13 Jun 2024 16:59:50 +0900, Michael Paquier
> > wrote in
> >> * The kind IDs may change across restarts, meaning that any stats data
> >> associated
I think the period here should be a typo.
index 16b5803d388..af3b15e93df 100644
--- a/src/backend/storage/ipc/procarray.c
+++ b/src/backend/storage/ipc/procarray.c
@@ -185,7 +185,7 @@ typedef struct ComputeXidHorizonsResult
FullTransactionId latest_completed;
/*
-* The sam
Hi,
While working on [1] I encountered the issue that, on github-actions,
010_pg_basebackup.pl fails on windows.
The reason for that is that github actions uses two drives, with TMP/TEMP
located on c:, the tested code on d:. This causes the following code to fail:
# Create a temporary directo
62 matches
Mail list logo
