On Tue, Mar 11, 2025 at 12:45:35AM +1300, David Rowley wrote:
> It seems to me that if this fixes the issue, that the next similar one
> is already lurking in the shadows waiting to jump out on us.
For how many years will be have to wait for this threat hiddent in the
shadows? :)
This issue exis
Hi,
On Fri, Mar 7, 2025 at 9:35 PM Aleksander Alekseev
wrote:
> Your patch should target the `master` branch. Also please add a
> corresponding entry to the nearest open commitfest [1].
OK, thanks for the notice! I attach the v2 patch for the `master`
branch to this letter. Now you can also find
Hi,
On Mon, Mar 10, 2025 at 02:52:42PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> > On Mon, Mar 03, 2025 at 11:54:39AM +, Bertrand Drouvot wrote:
> > > So it does not look like what we're adding here can be seen as a primary
>
pgconf.dev is coming up soon. I won't be able to make it to Montreal,
but I saw that Dave Cramer posted on twitter asking about postgres
protocol topics.
while I don't have a patch, I wanted to send an email about something:
it'd be great to have a place - perhaps like application_name - for
arbit
On Thu, Feb 20, 2025 at 5:01 PM Nisha Moond wrote:
>
> Hi Hackers,
> (CCing people involved in related discussions)
>
> I am starting this thread to propose a new conflict detection type
> "multiple_unique_conflicts" that identifies when an incoming row
> during logical replication violates more t
On Tue, Mar 11, 2025 at 3:36 AM Devulapalli, Raghuveer
wrote:
>
> Hi John,
>
> > On the other hand, looking at Linux kernel sources, it seems a patch using
> > this
> > technique was contributed by Intel over a decade ago:
> >
> > https://github.com/torvalds/linux/blob/master/arch/x86/crypto/crc3
One thing I forgot to mention is the progress reporting only updates
blocks for the FORK_MAIN. It wouldn't be difficult to report blocks for
each fork, but it'd be confusing - the relation counters would remain
the same, but the block counters would change for each fork.
I guess we could report th
On Tue, Mar 11, 2025 at 8:20 AM David G. Johnston
wrote:
>
> Hi.
>
> With all the recent work on pg_createsubscriber I decided to take a look at
> it, namely the documentation.
>
I agree this page needs some improvement. Thanks for taking up this task.
> The 0001 patch is basically just fixing
On Mon, Mar 10, 2025 at 10:54 AM Amit Kapila wrote:
>
> On Mon, Mar 10, 2025 at 10:15 AM Dilip Kumar wrote:
> >
> > On Mon, Mar 10, 2025 at 9:33 AM Amit Kapila wrote:
> >>
> >> On Tue, Mar 4, 2025 at 6:54 PM vignesh C wrote:
> >> >
> >> > On further thinking, I felt the use of publications_upda
On Mon, 3 Mar 2025 at 15:02, vignesh C wrote:
>
> On Tue, 25 Feb 2025 at 21:49, vignesh C wrote:
> >
> > If any of these are ready, please add them to the CommitFest page. If
> > you think some are trivial and don’t need to be added, that’s fine
> > too.
> > Looking forward to a productive Commit
On Thu, Feb 27, 2025 at 6:58 AM Tom Lane wrote:
> Yeah. The key problem blocking doing something about it in the
> planner is that at the time we want to do join tree restructuring,
> we haven't yet collected the per-relation data that would allow
> us to know about NOT NULL constraints, nor run
Thank you for the quick reply.
On Mon, Mar 10, 2025 at 7:56 PM Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
> Dear David,
>
> > The main thing I noted is that our synopsis is simply wrong regarding the
> > optionality of the --database option. I went with a fix that included
> onl
Dear David,
> The main thing I noted is that our synopsis is simply wrong regarding the
> optionality of the --database option. I went with a fix that included only
> showing the two mandatory options and adding a paragraph to usage explaining
> that --database exists and how to use it. Our exis
Hi,
On March 10, 2025 10:37:43 AM EDT, Peter Eisentraut
wrote:
>On 10.03.25 14:58, Andres Freund wrote:
>>> diff --git a/src/backend/utils/mmgr/slab.c b/src/backend/utils/mmgr/slab.c
>>> index ec8eddad863..d32c0d318fb 100644
>>> --- a/src/backend/utils/mmgr/slab.c
>>> +++ b/src/backend/utils/mm
>
> Hi, Masahiko
>
> Thanks for your comments! I understand your concern as you stated.
> However, my initial patch was split into two parts as Kirill suggested.
> This thread is about the first part. Another part is here:
> https://commitfest.postgresql.org/patch/5149/
> Or you can take a look a
Hi Melanie Plageman
Thank you for your reply. My calculation logic is to calculate the
proportion of active tuples. What I really want to know is whether this
algorithm is correct and acceptable. The way I wrote it is mainly to
express that I want to calculate the percentage of active tuples
On Tue, 4 Mar 2025 at 23:05, Jakub Wartak wrote:
> out of curiosity, did Redhat provide any further (deeper) information
> on why too big preallocation (or what heuristics) on XFS can cause
> such issues?
Hi Jakub
So far I don't have any feedback from RH. Unfortunately there is a
long corporate
Michael Paquier writes:
> On Mon, Mar 10, 2025 at 09:07:59AM +0100, Anthonin Bonnefoy wrote:
>> The issue seems to have been introduced by 2129d184a206c when
>> transactionState->priorContext was added and is only present in HEAD.
> It seems to me that you mean 1afe31f03cd2, no?
I dunno about th
During a recent review of pg_creatersubscriber I saw that commit
e117cfb introduced a common 'dbinfos' struct to contain the array of
individual 'dbinfo[i]' infos. But, this now means that getting to each
dbinfo[i] requires another level of referencing.
In some places, e.g. function cleanup_object
On Tue, 11 Mar 2025 at 05:18, Tom Lane wrote:
> Here's a hopefully-final v3 that makes the two changes discussed.
> Now with a draft commit message, too.
Looks good to me.
The only minor points I noted down while reviewing were 1)
name_active_windows()'s newname variable could be halved in size
On 2025/03/10 22:11, Yuki Seino wrote:
I encountered a compilation error with the patch. You can also see the error in
the patch tester.
https://cirrus-ci.com/task/5070779370438656
Sorry, removed some errors and made some fixes.
Thanks for updating the patch!
You modified heap_lock_tuple(
> I don't quite understand why do we need to differentiate between
> PLAN_CACHE_STATUS_GENERIC_PLAN_BUILD and
> PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE?
> We could simply keep PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE.
> I don't think users would see much of a difference in either
> pg_stat_statements or
On Mon, Mar 10, 2025 at 5:00 PM Peter Smith wrote:
> Hi Shubham.
>
> Some review comments for patch v16-0001.
>
> ==
> doc/src/sgml/ref/pg_createsubscriber.sgml
>
> 1.
> + -c
> + --drop-all-publications
>
> Is 'c' the best switch choice letter for this option? It doesn't seem
> intuit
On Mon, Mar 10, 2025 at 11:52:26AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Mar 10, 2025 at 04:46:53PM +0900, Michael Paquier wrote:
> > On Sat, Mar 08, 2025 at 07:53:04AM +, Bertrand Drouvot wrote:
> > > That would not be an issue should we only access the struct
> > > fields in the c
The attached v14 is the rebased patch that updated the OpenSSL API calls to be
compatible in
version 1.1.1 (and beyond), which is the new minimum OpenSSL version supported
in PostgreSQL.
Cary Huang
-
HighGo Software Inc. (Canada)
cary.hu...@highgo.ca
www.highgo.ca
v14-0001-Add-no
Hello,
I fleshed this out more fully and I think 0001 is good enough to commit.
I then noticed that constraints on domains are giving bogus error
messages as well, and the situation is easily improved -- see 0002. I'm
not so sure about this one, mainly because test coverage appears scant.
I need
While exploring the jsonb code, I noticed that in
datum_to_jsonb_internal, the tcategory checks compares against
JSONTYPE_JSON twice. There's no reason for that, right?
...
Ok, so, to try to answer my own question, I went looking at the
history, and this comes from "Unify JSON categorize type API
On Mon, Mar 10, 2025 at 09:07:59AM +0100, Anthonin Bonnefoy wrote:
> The issue seems to have been introduced by 2129d184a206c when
> transactionState->priorContext was added and is only present in HEAD.
It seems to me that you mean 1afe31f03cd2, no?
--
Michael
signature.asc
Description: PGP sign
On Sat, Mar 8, 2025 at 1:42 AM Masahiko Sawada wrote:
>
>
> I've attached the updated version patches.
I've started trying to review this and realized that, while I'm
familiar with heap vacuuming code, I'm not familiar enough with the
vacuumparallel.c machinery to be of help without much addition
Hi Shubham.
Some review comments for patch v16-0001.
==
doc/src/sgml/ref/pg_createsubscriber.sgml
1.
+ -c
+ --drop-all-publications
Is 'c' the best switch choice letter for this option? It doesn't seem
intuitive, but unfortunately, I don't have any better ideas since d/D
and p/P are
On Mon, 2025-03-10 at 17:53 -0400, Tom Lane wrote:
> I wrote:
> > I think what is happening is that the patch shut off CREATE
> > INDEX's update of not only the table's stats but also the
> > index's stats. This seems unhelpful: the index's empty
> > stats can never be what's wanted.
>
> I looked
On Mon, Mar 10, 2025 at 3:06 PM Melanie Plageman
wrote:
>
> The takeaway is that I think 16 is a good default effectio_io_concurrency
> value.
Attached v35 0003-0005 is the same as v34 but is on top of two new
commits: 0001 increases the default effective_io_concurrency to 16 and
0002 adds a REA
On 21/01/2025 12:05, Alexander Korotkov wrote:
On Tue, Jan 21, 2025 at 12:03 PM Alexander Korotkov
wrote:
On Sun, Dec 29, 2024 at 3:59 PM Heikki Linnakangas wrote:
However, I think GetLatestSnapshot() is wrong here anyway. None of this
matters for heapam which just ignores the 'snapshot' argu
On Mon, Mar 10, 2025 at 10:40:01AM +0300, Aleksander Alekseev wrote:
> The proposed patch adds reverse(bytea) function.
We already have array_reverse() and text_reverse(), so I see no strong
reason against also having a bytea_reverse().
--
nathan
On Sun, Mar 9, 2025 at 11:28 PM Amit Kapila wrote:
>
> On Fri, Mar 7, 2025 at 11:06 PM Masahiko Sawada wrote:
> >
> > Discussing with Amit offlist, I've run another benchmark test where no
> > data is loaded on the shared buffer. In the previous test, I loaded
> > all table blocks before running
I wrote:
> I think what is happening is that the patch shut off CREATE
> INDEX's update of not only the table's stats but also the
> index's stats. This seems unhelpful: the index's empty
> stats can never be what's wanted.
I looked at this more closely and realized that it's a simple matter
of h
On 07.03.2025 15:40, Aleksander Alekseev wrote:
Hi,
Sometimes support for base64url from RFC 4648 would be useful.
Does anyone else need a patch like this?
While not a frequent ask, it has been mentioned in the past. I think it would
make sense to add so please do submit a patch for it for co
On Mon, Mar 10, 2025 at 11:15:04AM +0530, Ashutosh Sharma wrote:
> On Fri, Mar 7, 2025 at 10:55 PM Nathan Bossart
> wrote:
>> I noticed that much of this code is lifted from DropRole(), and the new
>> check_drop_role_dependency() function is only used by DropRole() right
>> before it does the exa
Hello,
On 2025-Jan-15, jian he wrote:
> we cannot error out AlterDomainAddConstraint for cases like ALTER
> DOMAIN ADD CHECK NO INHERIT.
> because "NO INHERIT" is actually a separate Constraint Node, and
> AlterDomainAddConstraint
> can only handle one Constraint node.
I had forgotten this threa
Hello,
I did a full review on the provided patches plus some tests, I was able to
validate that the loading of bitcode modules is working also JIT works for
both backend and contrib modules.
To test JIT on contrib modules I just lowered the costs for all jit
settings and used the intarray extensi
Hi.
With all the recent work on pg_createsubscriber I decided to take a look at
it, namely the documentation.
The 0001 patch is basically just fixing some typos and other minor edits.
The 0002 includes some of the more editoralized (but still limited) changes.
The main thing I noted is that our
> On 7 Mar 2025, at 23:08, Melanie Plageman wrote:
Sorry for being late to the party. I like this functionality and would
definitely like to see it in v18.
> An unrelated note about the attached v13:
> I changed the language from log_connections "stages" to "options" and
> "aspects" depending o
> On 10 Mar 2025, at 22:06, Nathan Bossart wrote:
>
> On Mon, Mar 10, 2025 at 10:40:01AM +0300, Aleksander Alekseev wrote:
>> The proposed patch adds reverse(bytea) function.
>
> We already have array_reverse() and text_reverse(), so I see no strong
> reason against also having a bytea_reverse()
Hi,
I would like to propose exposing an internal PostgreSQL function called
ReadMultiXactCounts() to allow for efficient monitoring of MultiXact member
usage. This function provides an accurate, real-time view of MultiXact
activity by directly retrieving the actual member count, rather than
relyin
Hi John,
> On the other hand, looking at Linux kernel sources, it seems a patch using
> this
> technique was contributed by Intel over a decade ago:
>
> https://github.com/torvalds/linux/blob/master/arch/x86/crypto/crc32c-pcl-intel-
> asm_64.S
>
> So one more thing to ask our friends at Intel.
Hi,
Thanks for reviewing and suggestions!
On Thu, Mar 6, 2025 at 10:46 AM Peter Eisentraut wrote:
> This looks very good to me. I have one issue to point out: The logic
> in get_extension_control_directories() needs to be a little bit more
> careful to align with the rules in find_in_path().
Hi!
On Fri, 7 Feb 2025 at 05:15, Anton A. Melnikov
wrote:
>
> Hi!
> I noticed that the updated page is not written to disk because the
> buffer where it is located is not marked dirty. Moreover
> MarkBufferDirtyHint(),
> which is called for modified FSM pages, seems is not suitable here,
> sinc
Mahendra Singh Thalor writes:
> While doing some code changes with pg_dumpall and pg_rsetore[1], we noticed
> that on_exit_nicely_list array has only fixed slots (MAX_ON_EXIT_NICELY=20)
> but in some cases, we need more slots for pg_restore.
> *Ex: restore more than 20 databases by single pg_rest
> On 10 Mar 2025, at 12:17, Tomas Vondra wrote:
>
> On 3/10/25 10:46, Tomas Vondra wrote:
>> On 3/10/25 01:18, Tomas Vondra wrote:
Thank you so much for picking up and fixing the blockers, it's highly
appreciated!
>> For me, this passes all CI tests, hopefully cfbot will be happy too.
Confirm
Dear Hou,
> Currently, only the leaf partition is invalidated when the published table is
> partitioned. However, I think pgoutput could cache both the partitioned table
> and the leaf partition table as relsync entries.
>
> For INSERT/UPDATE/DELETE on a partitioned table, only the leaf partition
I encountered a compilation error with the patch. You can also see the
error in the patch tester.
https://cirrus-ci.com/task/5070779370438656
Sorry, removed some errors and made some fixes.
Regard,
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index d2fa5f7d1a9..dd14bac6a4d
On Wed, Mar 5, 2025 at 8:01 PM Dean Rasheed wrote:
> Yes, that makes sense, and it seems like a fairly straightforward
> simplification, given that perform_pullup_replace_vars() sets it back
> to false shortly afterwards.
>
> The same thing happens in pull_up_constant_function().
Thanks for looki
On Wed, 5 Mar 2025 at 07:33, Andreas Karlsson wrote:
>
> On 3/4/25 10:24 AM, Andreas Karlsson wrote:
> > Rebased the patch to add support for OLD.* and NEW.*.
>
> Apparently the CI did not like that version.
>
> Andreas
Hi!
Applied v6.
1) Should we answer INSERT 0 10 here?
```
reshke=# table tt
On Mon, Mar 10, 2025, 14:32 Daniel Gustafsson wrote:
> > On 10 Mar 2025, at 12:28, Florents Tselai
> wrote:
>
> > Here's a C implementation for this, along with some tests and
> documentation.
> > Tests are copied from cpython's implementation of urlsafe_b64encode and
> urlsafe_b64decode.
>
> +
> On 10 Mar 2025, at 12:28, Florents Tselai wrote:
> Here's a C implementation for this, along with some tests and documentation.
> Tests are copied from cpython's implementation of urlsafe_b64encode and
> urlsafe_b64decode.
+ base64url_encode ( input
bytea )
Shouldn't this be modelle
On Fri, 7 Mar 2025 at 16:52, Andreas Karlsson wrote:
>
> Hi,
Hi!
> Here is a rebased version of it to make the CI happy.
Looks like CI is still unhappy with this change[0]
0001:
>+
>+SMgrId
>+smgr_register(const f_smgr *smgr, Size smgrrelation_size)
...
> + Assert(smgr->smgr_open != NULL);
>
On 13.02.25 16:34, Peter Eisentraut wrote:
On 22.01.25 19:16, Peter Eisentraut wrote:
On 06.01.25 15:52, Peter Eisentraut wrote:
On 03.01.25 21:51, Dagfinn Ilmari Mannsåker wrote:
Peter Eisentraut writes:
I suggest we define pg_noreturn as
1. If C11 is supported, then _Noreturn, else
2. If
Hi,
Thank you for working on this!
I just started reading the code and have a couple of questions.
I think that every time we flush IO or WAL stats, we want(?) to flush
backend stats as well, so would it make sense to move
pgstat_flush_backend() calls to inside of pgstat_flush_io() and
pgstat_wa
Hi,
On Mon, Mar 10, 2025 at 04:46:53PM +0900, Michael Paquier wrote:
> On Sat, Mar 08, 2025 at 07:53:04AM +, Bertrand Drouvot wrote:
> > That would not be an issue should we only access the struct
> > fields in the code, but that's not the case as we're making use of
> > pg_memory_is_all_zeros
On Mon, 10 Mar 2025 at 23:17, Bykov Ivan wrote:
> I have attached the updated Variant A patch with the following changes:
> - Implemented a pg_stat_statements regression test (see similar test results
> on REL_17_3 in Query-ID-collision-at_pg_stat_statements-1ea6e890b22.txt).
> - Added extra des
On Fri, Feb 28, 2025 at 3:55 PM Yura Sokolov wrote:
> 28.02.2025 16:03, Yura Sokolov пишет:
> > 17.02.2025 00:27, Alexander Korotkov wrote:
> >> On Thu, Feb 6, 2025 at 10:31 AM Yura Sokolov
> >> wrote:
> >>> I briefly looked into patch and have couple of minor remarks:
> >>>
> >>> 1. I don't lik
On Sun, Mar 9, 2025 at 12:28 AM Florents Tselai
wrote:
>
>
> On 7 Mar 2025, at 4:40 PM, Aleksander Alekseev
> wrote:
>
> Hi,
>
> Sometimes support for base64url from RFC 4648 would be useful.
> Does anyone else need a patch like this?
>
>
> While not a frequent ask, it has been mentioned in the
On 2025-Mar-09, Alexander Korotkov wrote:
> After second thought it's not so hard to fix. The attached patch does
> it by putting REINDEX commands related to the same table into a single
> SQL statement. Possibly, that could be better than revert given we
> need to handle compatibility. What do
On 06.03.2025 18:04, Sami Imseih wrote:
2. Should we add Assert(kind == PGSS_EXEC) at this place to ensure that
generic_plan_calls and custom_plan_calls are only incremented when
appropriate?
I don't think an assert is needed here. There is an assert at the start of
the block for PGSS_EXEC an
On Monday, March 10, 2025 7:00 PM Kuroda, Hayato
wrote:
>
> I did a self-reviewing and updated a patch. PSA new version. What's new:
Thanks for updating the patch.
I tested the behavior for partitioned table and have a comment on this.
> + relids = GetPublicationRelations(pubform-
On Mon, Mar 10, 2025 at 3:09 PM Nisha Moond wrote:
>
> On Mon, Mar 10, 2025 at 12:11 PM Shubham Khanna
> wrote:
> >
> > On Thu, Mar 6, 2025 at 9:27 AM Peter Smith wrote:
> > >
> > > 6.
> > > - dbinfo->pubname, dbinfo->dbname, PQresultErrorMessage(res));
> > > - dbinfo->made_publication = false;
Dear hackers,
I did a self-reviewing and updated a patch. PSA new version. What's new:
1. Fixed a bug which existing name can be specified by ALTER PUBLICATION RENAME.
A validation is added in RenamePublication().
Just in case, we want to discuss the case that the renaming publication has
th
Hi,
On Fri, Mar 07, 2025 at 12:33:27PM +0100, Jakub Wartak wrote:
> On Fri, Mar 7, 2025 at 11:20 AM Jakub Wartak
> wrote:
> >
> > Hi,
> > On Wed, Mar 5, 2025 at 10:30 AM Jakub Wartak
> > wrote:
> > >Hi,
> >
> > > > Yeah, that's why I was mentioning to use a "shared"
> > > > populate_buffercache
On Mon, 10 Mar 2025 at 17:22, Masahiko Sawada wrote:
> Regarding that patch, we need to note that the lpdead_items is a
> counter that is not reset in the entire vacuum. Therefore, with
> maintenance_work_mem = 64kB, once we collect at least one lpdead item,
> we perform a cycle of index vacuuming
On Mon, Mar 10, 2025 at 12:11 PM Shubham Khanna
wrote:
>
> On Thu, Mar 6, 2025 at 9:27 AM Peter Smith wrote:
> >
> > 6.
> > - dbinfo->pubname, dbinfo->dbname, PQresultErrorMessage(res));
> > - dbinfo->made_publication = false; /* don't try again. */
> > + pubname, dbname, PQresultErrorMessage(res
Hi,
(refer file src/bin/pg_dump/pg_backup_utils.c)
While doing some code changes with pg_dumpall and pg_rsetore[1], we noticed
that on_exit_nicely_list array has only fixed slots (MAX_ON_EXIT_NICELY=20)
but in some cases, we need more slots for pg_restore.
*Ex: restore more than 20 databases by s
Hi,
After commit eaf5027 we should add information about wal_buffers_full.
Any thoughts?
--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.
On Mon, 10 Mar 2025 at 10:30, David Rowley wrote:
> Could you do something similar to what's in hash_agg_check_limits()
> where we check we've got at least 1 item before bailing before we've
> used up the all the prescribed memory? That seems like a safer coding
> practise as if in the future the
The issue seems to have been introduced by 2129d184a206c when
transactionState->priorContext was added and is only present in HEAD.
Hi,
This change seems to have introduced an issue where a deleted context
can be restored. This happens when a replication command exports a
snapshot since the transaction used is aborted at the start of the
next command. This leads to a memory context allocated with itself as
a parent and child,
On Sat, Mar 08, 2025 at 07:53:04AM +, Bertrand Drouvot wrote:
> That would not be an issue should we only access the struct
> fields in the code, but that's not the case as we're making use of
> pg_memory_is_all_zeros() on it.
It does not hurt to keep it as it is, honestly.
I've reviewed the
Hi Sawada-San.
Some review comments for patch v11-0003.
==
src/backend/access/heap/vacuumlazy.c
1.
+typedef struct LVScanData
+{
+ BlockNumber rel_pages; /* total number of pages */
+
+ BlockNumber scanned_pages; /* # pages examined (not skipped via VM) */
+
+ /*
+ * Count of all-visible blo
On Thu, Mar 06, 2025 at 01:44:30PM -0600, Nathan Bossart wrote:
> On Thu, Mar 06, 2025 at 11:30:13AM -0800, Noah Misch wrote:
>> 1. Make v14 and v13 skip WAL recycling and preallocation during archive
>>recovery, like newer branches do. I think that means back-patching the
>> six
>>commit
On Fri, Feb 7, 2025 at 7:15 AM Anton A. Melnikov
wrote:
> Hi!
>
> At the current master i found that if not the last page of
> the FSM bottom layer was corrupted it is not restored after zeroing.
>
> Here is reproduction like that:
> 1) Create a table with FSM of 4 pages:
> create table t (int) a
On Thu, Mar 6, 2025 at 12:49 AM Mahendra Singh Thalor
wrote:
>
> Thanks Alvaro for feedback and review.
>
> On Wed, 5 Mar 2025 at 20:42, Álvaro Herrera wrote:
> >
> > Disclaimer: I didn't review these patches fully.
> >
> > On 2025-Mar-05, Mahendra Singh Thalor wrote:
> >
> > > On Wed, 5 Mar 2025
Hi,
The proposed patch adds reverse(bytea) function.
This allows converting between big-endian and little-endian binary
strings, which works nicely with previous commits [1] and [2].
[1]:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=760162fedb4f
[2]:
https://git.postgresq
On Mon, Mar 10, 2025 at 11:04 AM Ajin Cherian wrote:
>
> On Mon, Mar 10, 2025 at 3:58 PM Ashutosh Bapat
> wrote:
> >
> > On Thu, Mar 6, 2025 at 9:18 AM Ajin Cherian wrote:
> >
> > > + Subscription names, publication names, and replication slot names
> > > are
> > > + automatically g
On Mon, Mar 10, 2025 at 10:28 AM Ashutosh Bapat
wrote:
>
> On Thu, Mar 6, 2025 at 9:18 AM Ajin Cherian wrote:
>
> > + Subscription names, publication names, and replication slot names
> > are
> > + automatically generated. Cannot be used together with
> > + --database, --public
On Thu, Mar 6, 2025 at 9:18 AM Ajin Cherian wrote:
>
> On Fri, Feb 28, 2025 at 11:34 PM Shubham Khanna
> wrote:
> >
> >
> > The attached Patch contains the suggested changes.
> >
> > Thanks and regards,
> > Shubham Khanna.
>
> Some comments:
> 1.
> +
> + -a
> + --all
> +
> +
On Fri, Feb 28, 2025 at 6:33 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Shubham,
>
> Thanks for updating the patch.
>
> I think the modification [1] is not correct - the loop is meaningless because
> the same
> query would be executed every time. How about idea like attached? Here,
> instead of
85 matches
Mail list logo
