Hi Vladyslav,
No Problem, I also did not realize that you will be implementing it.
So I spent a couple of hours and provided a patch.
Also created commitfest entry as well, Please do review the patch and
let me know if this is sufficient at least for your use case.
Regards,
Umar Hayat
Bitnine (htt
hi.
more small issues.
+ count_db++; /* Increment db couter. */
+ dboidprecell = dboid_cell;
+ }
+
typo, "couter" should be "counter".
+
+/*
+ * get_dbname_oid_list_from_mfile
+ *
+ * Open map.dat file and read line by line and then prepare a list of database
+ * names and correspoding db_oid.
+
31.01.2025 08:15, Ashutosh Bapat пишет:
Hi All,
EvictUnpinnedBuffer() calls InvalidateVictimBuffer() followed by
UnpinBuffer() before returning. None of those functions put the buffer
back into the free list. Its freeNext remains set to
FREENEXT_NOT_IN_LIST. I think then that buffer will never be
On Fri, Jan 31, 2025 at 10:40 AM Peter Smith wrote:
>
> ==
> src/backend/replication/slot.c
>
> ReportSlotInvalidation:
>
> 1.
> +
> + case RS_INVAL_IDLE_TIMEOUT:
> + Assert(inactive_since > 0);
> + /* translator: second %s is a GUC variable name */
> + appendStringInfo(&err_detail,
> + _("The
Alvaro Herrera wrote:
> On 2025-Jan-31, Antonin Houska wrote:
>
> Something that Robert Haas just mentioned to me is handling of row
> locks: if concurrent transactions are keeping rows in the original table
> locked (especially SELECT FOR KEY SHARE, since that's not considered by
> logical deco
On 2025-Jan-31, Antonin Houska wrote:
> Alvaro Herrera wrote:
>
> > Something that Robert Haas just mentioned to me is handling of row
> > locks: if concurrent transactions are keeping rows in the original table
> > locked (especially SELECT FOR KEY SHARE, since that's not considered by
> > logi
Hi,
On Wed, 29 Jan 2025 at 18:16, Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Jan 29, 2025 at 02:57:21PM +0300, Nazir Bilal Yavuz wrote:
> > I agree with you but it was discussed before in this thread [2]. It
> > was decided to use both track_wal_io_timing and track_io_timing
> > because of the o
On Thu, 30 Jan 2025 at 16:29, Alvaro Herrera wrote:
>
> On 2025-Jan-30, Michael Banck wrote:
>
> > > I haven't addressed the problem of a new command yet - for that I'd like
> > > to
> > > see some sort of consensus, so that I do not have to do all the related
> > > changes many times.
> >
> > We
On Mon, Dec 2, 2024 at 1:09 PM Jim Jones wrote:
>
>
> On 29.11.24 21:57, Kirill Gavrilov wrote:
> > Same thing applies to log_parameter_max_length, for example.
> >
> > postgres=# set log_parameter_max_length = '1foo';
> > ERROR: invalid value for parameter "log_parameter_max_length": "1foo"
> >
On 2025-Jan-31, Antonin Houska wrote:
> I assume the patch should mark CLUSTER deprecated rather than removing it
> immediately.
Yeah, we should certainly not make any statements fail that work today.
Same goes for VACUUM FULL.
> I also agree that tables not being REPACKed should be treated as n
I'll set this patch to "ready for committer".
This is about the color of the bikeshed, and several people
have voiced their opinion. I don't think much more review
is needed. All that is needed is a committer who either
commits or rejects it.
Yours,
Laurenz Albe
Hi, Dmitry!
On Tue, Jan 28, 2025 at 1:15 AM Dmitry Koval wrote:
>
> >Only patches v34-0001 and 2 has been tested.
> >Patch v34-0003-Refactor-createPartitionTable-to-remove-ProcessU.patch
> >do not apply anymore on src/backend/catalog/heap.c
>
> Thanks, rebased.
> The patches are attached to th
Hi Hackers,
Enabling logging_collector is required for json log. During jsonlog
implementation [1], log destination and logging_collector comments in
postgresql.conf.sample and documentation was updated but
logging_collector short description was not updated in guc.c (which is
guc_table.c now).
Att
On Fri, Jan 31, 2025 at 06:09:48PM +0900, Umar Hayat wrote:
> Enabling logging_collector is required for json log. During jsonlog
> implementation [1], log destination and logging_collector comments in
> postgresql.conf.sample and documentation was updated but
> logging_collector short description
Hi!
I'd like to share some thoughts on which particular way this patch could go.
On Thu, Aug 22, 2024 at 8:25 PM Robert Haas wrote:
> Here, aside from the name lookup issues, there are also problems with
> expression evaluation: we can't split partitions without reindexing
> rows that those part
On Mon, Dec 9, 2024 at 11:01 PM Dmitry Koval wrote:
> >I see fixes for the issues mentioned in [1] and [2] are still not
> >implemented. Do you plan to do this in this release cycle?
>
> I would like to make some changes, but I think it would be appropriate
> to discuss these points first.
> As
On Mon, 2024-12-23 at 16:39 +0100, Jelte Fennema-Nio wrote:
> On Thu, 31 Oct 2024 at 18:15, Jelte Fennema-Nio wrote:
> >
> > On Thu, 31 Oct 2024 at 15:50, Heikki Linnakangas wrote:
> > > Bikeshedding time:
> >
> > Another few options:
>
> Okay let's just pick one of the available options. The
> On 31 Jan 2025, at 07:03, Ashutosh Bapat wrote:
>
> Hi All,
> All the functions in pg_buffercache module have their names suffixed
> with () and also use tag in the documentation, except
> pg_buffercache_evict(). PFA patch to fix the style. With this change,
> the index entry and the section t
Hi.
Debugging some replication lag on a replica when the master node
experiences heavy writes.
PG "startup recovering" eats up a lot of CPU (like 65 %user and 30 %sys),
which is a little surprising (what is it doing with all those CPU cycles?
it looked like WAL replay should be more IO bound than
Hello, hackers!
When using manually created partitioned tables for pgbench, an error
occurred:
ERROR: cannot perform COPY FREEZE on a partitioned table.
Currently only pgbench_accounts can be partitioned, all others must be a
regular tables.
I wrote a patch to disable WITH (FREEZE = ON) wh
On Fri, Jan 31, 2025 at 2:19 PM Yura Sokolov wrote:
>
> 31.01.2025 08:15, Ashutosh Bapat пишет:
> > Hi All,
> > EvictUnpinnedBuffer() calls InvalidateVictimBuffer() followed by
> > UnpinBuffer() before returning. None of those functions put the buffer
> > back into the free list. Its freeNext rema
On Fri, Jan 31, 2025 at 2:43 PM Michael Paquier wrote:
>
> On Fri, Jan 31, 2025 at 06:09:48PM +0900, Umar Hayat wrote:
> > Enabling logging_collector is required for json log. During jsonlog
> > implementation [1], log destination and logging_collector comments in
> > postgresql.conf.sample and do
On 2025-Jan-31, Antonin Houska wrote:
> Matthias van de Meent wrote:
> > First, due to the XLog-based change detection this feature can't work
> > for unlogged tables without first changing them to logged (which
> > implies first writing the whole table to XLog, to not cause issues on
> > any re
Dear Ajin, Hou,
> - Snapshot construction
I understand the approach that we do not try to filter for all the workloads; do
just best-effort.
I played with your PoC and here are my comments.
1.
Can you add tests for better understanding? I've tried for tes_decoding like
attached,
but it couldn'
At the FOSDEM dev meeting we discussed potential improvements to the
commitfest app and how to handle deploying future changes with minimal
disruption to existing workflows. We're going to try a new approach:
announcing a new commitfest release ~2 weeks in advance, including
release notes. That way
On 2025-Jan-31, Dmitry Koterov wrote:
> PG "startup recovering" eats up a lot of CPU (like 65 %user and 30 %sys),
> which is a little surprising (what is it doing with all those CPU cycles?
> it looked like WAL replay should be more IO bound than CPU bound?).
>
> Running "perf top -p ", it shows
Hello Mike,
We encountered the same problem with a fixed allocsize=262144k. Removing
this option seemed to fix the problem.We are now in an XFS managed
allocation heuristic way. The problem does not show up since the change
was made on monday, but I'm not totally sure it has fixed the problem.
If
On Wed, Jan 29, 2025 at 11:49 PM Matthias van de Meent
wrote:
>
> Hi,
>
> Some time ago I noticed that every buffer table entry is quite large at 40
> bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are
> padding), 20 bytes of BufferTag, and 4 bytes for the offset into the
On Thu, Jan 30, 2025 at 11:09 PM Andrey Borodin wrote:
>
>
>
> > On 31 Jan 2025, at 00:54, Masahiko Sawada wrote:
> >
> > I like this idea. Would you like to write a patch, or shall I?
>
> I propose to separate milliseconds from nanoseconds. Please find attached
> implementation of this.
> With
Vladlen Popolitov writes:
> Only one exceptions in src/backend/commands/vacuumparallel.c:378
> shared->dead_items_info.max_bytes = vac_work_mem * (size_t)1024;
> max_bytes declared as size_t, I did cast to the same type (I cannot
> guarranty, that size_t and Size are equivalent in all systems)
I
On Fri, Jan 31, 2025 at 5:00 PM Dmitry Koterov
wrote:
> Hi.
>
> Debugging some replication lag on a replica when the master node
> experiences heavy writes.
>
> PG "startup recovering" eats up a lot of CPU (like 65 %user and 30 %sys),
> which is a little surprising (what is it doing with all thos
On 2024-Nov-25, Ashutosh Bapat wrote:
> Hmm, I am doing something similar to what you are doing. Here are my
> scripts. setup.sql - creates partitioned table, and functions, tables
> used to run the benchmark benchmark.sh - creates queries with all
> combinations of enable_partitionwise_join, num
On Thu, 23 Jan 2025 at 14:39, Peter Eisentraut <
peter.eisentr...@enterprisedb.com> wrote:
> On 27.12.24 11:16, Peter Eisentraut wrote:
> > On 16.05.22 10:27, Peter Eisentraut wrote:
> >> Inspired by [0], I looked to convert more macros to inline functions.
> >
> > This is an older thread where I
On 2025-Jan-31, Ashutosh Bapat wrote:
> But if the constraint is NOT VALID and later marked as NOT ENFORCED,
> what is expected behaviour while changing it to ENFORCED?
I think what you want is a different mode that would be ENFORCED NOT
VALID, which would be an extension of the standard, because
On Friday, January 31, 2025 03:21 MSK, Michael Paquier
wrote:
> > Thoughts and comments are welcome.
I'm looking at the v13 patch. I see, there is the only file for v13:
v2-0002-Fix-issues-with-2PC-file-handling-at-recovery-13.txt
There are two points I would like to highlight:
#1. In Recover
pgbench_accounts is the only table that should grow to
the point where partitioning can benefit the tpcb-like
benchmark.
It looks like you have customized the pgbench
schema that partitions the other pgbench tables, so
you can use a custom script to initialize the data.
IMO, If there is a good re
On Fri, Jan 31, 2025 at 2:27 PM Sami Imseih wrote:
>
> pgbench_accounts is the only table that should grow to
> the point where partitioning can benefit the tpcb-like
> benchmark.
pgbench_history is append-only, so I could see the argument for
partitioning that.
> IMO, If there is a good reason
On Fri, Jan 31, 2025 at 10:19:29AM -0500, Tom Lane wrote:
> FWIW, it seems weird to me to use the word "output" with only one
> of those terms. The proposed new wording is fine by me, or we
> could do
>
> "Start a subprocess to capture stderr, csvlog and/or jsonlog output
> into log files."
>
>
Michael Paquier writes:
> FWIW, I'd choose for keeping things simpler and just remove the word
> "output", keeping this list as all the possible values. Hence, the
> patch is OK here:
> -gettext_noop("Start a subprocess to capture stderr output and/or csvlogs
> into log files."),
> +gett
On Fri, 31 Jan 2025 at 17:50, Nisha Moond wrote:
>
> Thanks for the review! I have incorporated the above comments. The
> test in patch-002 has been optimized as suggested and now completes in
> less than a second.
> Please find the attached v66 patch set. The base patch(v65-001) is
> committed no
Hi, all
I wanted to bring up an idea that could really help out.
Our DBA team uses foreign tables for ETL processes in Greenplum and Cloudberry,
and we often need to create foreign tables that match the column definitions of
local tables.
When dealing with wide tables and lots of those foreign
On Fri, Jan 31, 2025 at 10:18 AM Sami Imseih wrote:
>
> What is being discussed here is different from what I can tell. This
> is referring
> to the index changing status ( visible/invisible ) and those changes being
> visible by another transaction.
>
>
+1. My vote would be to keep the behavior
On Fri, Jan 24, 2025 at 4:03 PM Benoit Lobréau
wrote:
> I did notice something in the command prototype:
>
> +ALTER INDEX [ IF EXISTS ] class="parameter">name VISIBLE
> +ALTER INDEX [ IF EXISTS ] class="parameter">name INVISIBLE
>
> it would probably be better as:
>
> +ALTER INDEX [ IF EXISTS
On Fri, Jan 24, 2025 at 8:56 PM Benoit Lobréau
wrote:
> I also noticed that \d on an index doesn't warn about the invisible state
> whereas \d on a table does:
>
Thank you for the review + patch (v9-002) [1]. Your patch looks good to me.
I have not incorporated this in my v10 patch [2]. Mostly t
On 2025-Jan-31, Alvaro Herrera wrote:
> So I tried to rerun Ashutosh's benchmark (of course, on a build
> with no C assertions, otherwise the numbers are meaningless). First,
> the patches still apply to current master.
(BTW I just realized that I applied patches 0001-0004, omitting 0005).
--
On Fri, Jan 31, 2025 at 2:32 PM Amit Kapila wrote:
>
> On Fri, Jan 31, 2025 at 10:40 AM Peter Smith wrote:
> >
> > ==
> > src/backend/replication/slot.c
> >
> > ReportSlotInvalidation:
> >
> > 1.
> > +
> > + case RS_INVAL_IDLE_TIMEOUT:
> > + Assert(inactive_since > 0);
> > + /* translator: se
Matthias van de Meent wrote:
> Further observations:
>
> First, due to the XLog-based change detection this feature can't work
> for unlogged tables without first changing them to logged (which
> implies first writing the whole table to XLog, to not cause issues on
> any replicas). However, docu
On Wed, Jan 29, 2025 at 6:18 PM Amul Sul wrote:
>
> On Tue, Jan 28, 2025 at 9:47 PM Peter Eisentraut wrote:
> >
> > > In 0006, this change in the test output should be improved:
> > >
> > > -- XXX: error message is misleading here
> > > ALTER TABLE unique_tbl ALTER CONSTRAINT unique_tbl_i_key
31.01.2025 17:25, Álvaro Herrera пишет:
> On 2025-Jan-31, Dmitry Koterov wrote:
>
>> PG "startup recovering" eats up a lot of CPU (like 65 %user and 30 %sys),
>> which is a little surprising (what is it doing with all those CPU cycles?
>> it looked like WAL replay should be more IO bound than CPU
Hi!
On 25.01.2025 08:04, Alexander Korotkov wrote:
On Wed, Jan 15, 2025 at 10:24 AM Andrei Lepikhov wrote:
On 1/13/25 10:39, Andrei Lepikhov wrote:
On 1/13/25 01:39, Alexander Korotkov wrote:
It can be resolved with a single-line change (see attached). But I need
some time to ponder over the
On Thu, 23 Jan 2025 at 13:57, Jelte Fennema-Nio wrote:
> # Proposal for new process
I just announced an upcoming commitfest app release[1], following the
discussion on this topic at the FOSDEM dev meeting.
The rest of the conclusion is that we'll roughly follow the approach
outlined in this orig
Hi,
On 2025-01-31 03:30:35 -0800, Dmitry Koterov wrote:
> Debugging some replication lag on a replica when the master node
> experiences heavy writes.
>
> PG "startup recovering" eats up a lot of CPU (like 65 %user and 30 %sys),
> which is a little surprising (what is it doing with all those CPU
On Fri, Jan 31, 2025 at 12:16 AM Ashutosh Bapat
wrote:
>
> Hi All,
> EvictUnpinnedBuffer() calls InvalidateVictimBuffer() followed by
> UnpinBuffer() before returning. None of those functions put the buffer
> back into the free list. Its freeNext remains set to
> FREENEXT_NOT_IN_LIST. I think then
> On 24 Jan 2025, at 22:45, Daniel Gustafsson wrote:
>
>> On 24 Jan 2025, at 21:07, Andrew Dunstan wrote:
>> On 2025-01-22 We 4:25 AM, Dave Page wrote:
>
>>> Anyway, no fix was committed as far as I know. I would suggest it should be
>>> back-patched as well.
>>
>> I'm quite partial to the ap
Hi,
On 2025-01-30 21:24:05 -0500, Andres Freund wrote:
> On January 30, 2025 8:55:36 PM EST, Tom Lane wrote:
> >Andres Freund writes:
> >> While working on polishing the AIO patchset, I was trying to figure out
> >> where
> >> to fit the new GUCs. So far I had a new "top-level" #--- style secti
Umar Hayat writes:
> On Fri, 31 Jan 2025 at 20:41, Ashutosh Bapat
> wrote:
>> - gettext_noop("Start a subprocess to capture stderr output and/or
>> csvlogs into log files."),
>> + gettext_noop("Start a subprocess to capture stderr, csvlog and/or
>> jsonlog into log files."),
>>
>> Did you remove
Hi,
On 2025-01-31 15:54:45 +0100, Daniel Gustafsson wrote:
> > On 24 Jan 2025, at 22:45, Daniel Gustafsson wrote:
> >
> >> On 24 Jan 2025, at 21:07, Andrew Dunstan wrote:
> >> On 2025-01-22 We 4:25 AM, Dave Page wrote:
> >
> >>> Anyway, no fix was committed as far as I know. I would suggest it
Andres Freund writes:
> I don't really know what to do about the "IO" abbreviation. The other sections
> un-abbreviate abbreviations, but I suspect that Input/Output will be less
> informative than IO to most...
I'd lean towards writing "I/O", but it's not a point I'd quibble over.
> On 31 Jan 2025, at 16:29, Andres Freund wrote:
>> #ifdef ENABLE_GSS
>> -#if defined(HAVE_GSSAPI_H)
>> -#include
>> -#else
>> -#include
>> -#endif /* HAVE_GSSAPI_H */
>> +#include "libpq/pg-gssapi.h"
>> #endif /* ENABLE_GSS */
>
> This #ifdef ENABLE_GSS probably isn't necessary anymore.
Yeah
On Fri, 31 Jan 2025 at 20:41, Ashutosh Bapat
wrote:
>
> On Fri, Jan 31, 2025 at 2:43 PM Michael Paquier wrote:
> >
> > On Fri, Jan 31, 2025 at 06:09:48PM +0900, Umar Hayat wrote:
> > > Enabling logging_collector is required for json log. During jsonlog
> > > implementation [1], log destination an
31.01.2025 01:43, Heikki Linnakangas пишет:
Hi Heikki,
Did you consider using a radix tree? We use that method in src/backend/
utils/mb/Unicode/convutils.pm. I'm not sure if that's better or worse
than what's proposed here, but it would seem like a more standard
technique at least. Or if this
On Thu, Jan 30, 2025 at 7:42 AM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Tue, 28 Jan 2025 15:00:03 -0800,
> Masahiko Sawada wrote:
>
> > While 0001 and 0002 look good to me overall, we still need to polish
> > subseq
On Thu, Jan 30, 2025 at 10:39 PM Amit Kapila wrote:
>
> On Fri, Jan 31, 2025 at 4:10 AM Masahiko Sawada wrote:
> >
> > I have one question about the 0004 patch; it implemented
> > max_conflict_retntion_duration as a subscription parameter. But the
> > launcher invalidates the pg_conflict_detectio
Hi,
In
"Re: Make COPY format extendable: Extract COPY TO format implementations" on
Fri, 31 Jan 2025 14:25:34 -0800,
Masahiko Sawada wrote:
> I think that CopyToState and CopyFromState are not APIs but the
> execution states. I'm not against exposing CopyToState and
> CopyFromState. What I
Hi,
On January 31, 2025 5:22:43 PM EST, Robert Treat wrote:
>On Fri, Jan 31, 2025 at 10:25 AM Andres Freund wrote:
>>
>> Hi,
>>
>> On 2025-01-30 21:24:05 -0500, Andres Freund wrote:
>> > On January 30, 2025 8:55:36 PM EST, Tom Lane wrote:
>> > >Andres Freund writes:
>> > >> While working on p
Alvaro Herrera wrote:
> On 2025-Jan-31, Antonin Houska wrote:
>
> > Matthias van de Meent wrote:
>
> > > First, due to the XLog-based change detection this feature can't work
> > > for unlogged tables without first changing them to logged (which
> > > implies first writing the whole table to X
On Fri, Jan 31, 2025 at 10:25 AM Andres Freund wrote:
>
> Hi,
>
> On 2025-01-30 21:24:05 -0500, Andres Freund wrote:
> > On January 30, 2025 8:55:36 PM EST, Tom Lane wrote:
> > >Andres Freund writes:
> > >> While working on polishing the AIO patchset, I was trying to figure out
> > >> where
> >
On Fri, Jan 31, 2025 at 6:32 AM Sergey Tatarintsev
wrote:
>
> When using manually created partitioned tables for pgbench, an error
> occurred:
> ERROR: cannot perform COPY FREEZE on a partitioned table.
>
> Currently only pgbench_accounts can be partitioned, all others must be a
> regular tables.
> > IMO, If there is a good reason to allow the other pgbench
> > tables to be partitioned, that may be better to think
> > about. I am not sure there is though.
>
> see this thread [1] proposing partitioning pgbench_history last year.
>
> [1]
> https://www.postgresql.org/message-id/flat/CAAKRu_Zo
On Fri, Jan 31, 2025 at 3:10 PM Sutou Kouhei wrote:
>
> Hi,
>
> In
> "Re: Make COPY format extendable: Extract COPY TO format implementations"
> on Fri, 31 Jan 2025 14:25:34 -0800,
> Masahiko Sawada wrote:
>
> > I think that CopyToState and CopyFromState are not APIs but the
> > execution s
Zhang Mingli
www.hashdata.xyz
On Jan 30, 2025 at 15:49 +0800, Matthias van de Meent
, wrote:
>
> Some time ago I noticed that every buffer table entry is quite large at 40
> bytes (+8): 16 bytes of HASHELEMENT header (of which the last 4 bytes are
> padding), 20 bytes of BufferTag, and 4 bytes
On Sat, Feb 1, 2025 at 2:54 AM Masahiko Sawada wrote:
>
> On Thu, Jan 30, 2025 at 10:39 PM Amit Kapila wrote:
> >
> > On Fri, Jan 31, 2025 at 4:10 AM Masahiko Sawada
> > wrote:
> > >
> > > I have one question about the 0004 patch; it implemented
> > > max_conflict_retntion_duration as a subscri
72 matches
Mail list logo
