Hi Shubham, Here are some review comments for v9-0001.
==
Commit message
1.
You've changed the option to '--all' but the comment message still
refers to '-all-databases'
==
doc/src/sgml/ref/pg_createsubscriber.sgml
2.
+
+ Automatically fetch all non-template databases from t
On Mon, Feb 17, 2025 at 9:49 AM Peter Smith wrote:
>
> Hi Shubham
>
> Some review comments for v7-0001.
>
> (I am late to this thread. If some of my comments have already been
> discussed and rejected please let me know).
>
> ==
> 1 GENERAL. Option Name?
>
> Wondering why the patch is introduc
Thanks Álvaro for feedback.
On Thu, 20 Feb 2025 at 02:39, Álvaro Herrera wrote:
>
> Hello,
>
> I think the business with an evergrowing on_exit list needs a different
> solution than a gigantic array of entries. Maybe it would make sense to
> restructure that code so that there's a single on_exi
On 2025/02/19 1:08, Fujii Masao wrote:
Just an idea, but how about updating ConditionalXactLockTableWait() to
do the followings?
- Use LockAcquireExtended() instead of LockAcquire() to retrieve the
LOCALLOCK value.
- Generate a log message about the lock holders, from the retrieved
the LOCALL
On Wed, Feb 19, 2025 at 3:43 PM Amit Kapila wrote:
>
> Pushed after minor modifications.
>
I have closed the corresponding CF entry. Please feel free to start a
new thread for xid age based parameter.
--
With Regards,
Amit Kapila.
Dear Horiguchi-san,
I really appreciate your post-commit reviewing.
> However, the existing message for the same situation is written
> without "The value of" at the beginning.
Right. To clarify, max_slot_wal_keep_size has similar check hook which rejects
the upgrade mode, and it starts with "\"
On Wed, Feb 19, 2025 at 09:24:41AM +, Bertrand Drouvot wrote:
> That's right but that would mean almost duplicating the pg_stat_wal related
> stuff (because it can't be removed from the doc until the fields are gone). I
> think it's simpler to do it as proposed initially (the end result is the
Hello, (this mail is not a duplicate sent by mistake.)
The recent commit ac0e33136ab introduced the following message:
+ GUC_check_errdetail("The value of \"%s\" must be set to 0 during binary
upgrade mode.",
However, the existing message for the same situation is written
without "The val
On Wed, Feb 19, 2025 at 11:25 PM Dean Rasheed wrote:
>
> On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
> >
> > One thing I don't like about this is that it's introducing more code
> > duplication between pullup_replace_vars() and
> > ReplaceVarsFromTargetList(). Those already had a lot of cod
Gayatri Singh writes:
> We are using postgresql ver 15 , some Talend jobs to load data when we
> start to do this , DB server goes into kernel panic and reboot .
> Any idea how to troubleshoot this?
A repeatable kernel panic indicates either a buggy kernel or
a hardware fault; there is no univers
Hi Gayatri,
On Thu, Feb 20, 2025 at 10:04 AM Gayatri Singh
wrote:
>
> Hi All,
>
> We are using postgresql ver 15 , some Talend jobs to load data when we start
> to do this , DB server goes into kernel panic and reboot .
>
> Any idea how to troubleshoot this?
>
> DBA says there is some binary dat
Hi All,
We are using postgresql ver 15 , some Talend jobs to load data when we
start to do this , DB server goes into kernel panic and reboot .
Any idea how to troubleshoot this?
DBA says there is some binary data usage .
Regards,
Gayatri.
On Wed, Feb 19, 2025 at 11:57 AM Jelte Fennema-Nio wrote:
> On Tue, 18 Feb 2025 at 00:38, Peter Geoghegan wrote:
> > On Mon, Feb 17, 2025 at 4:33 PM Thomas Munro wrote:
> > > This looks fantastic. Thanks so much for working on it! And all the
> > > other usability improvements too.
> >
> > +1.
On Thu, Feb 20, 2025 at 1:30 PM Ajin Cherian wrote:
>
> On Fri, Feb 14, 2025 at 6:18 PM Amit Kapila wrote:
> >
> > On Wed, Feb 12, 2025 at 10:41 AM Ajin Cherian wrote:
> > >
> > > On Wed, Jan 29, 2025 at 9:31 AM Peter Smith wrote:
> > >
> > > Hi Ajin,
> > >
> > > Some review comments fo
Dear Ajin,
> I compared the patch 1 which does not employ a hash cache and has the
> overhead of starting a transaction every time the filter is checked.
>
> I created a test setup of 10 million inserts in 3 different scenarios:
> 1. All inserts on unpublished tables
> 2. Half of the inserts on u
Hi all,
Please find attached a new version of this patch. I rebased on master,
added better error reporting and skipped the permissions check on
windows. Please let me know if this needs any changes. I tested this
locally using meson running all TAP tests.
Thanks
On Fri, Jan 10, 2025 at 5:16 PM
On Wed, Feb 19, 2025 at 7:23 PM Hayato Kuroda (Fujitsu) <
kuroda.hay...@fujitsu.com> wrote:
> I intentionally used elog() because I thought single user mode is not
> user-facing.
> But it is OK for me to use ereport() instead.
>
Single-user mode is also known as "Oh crap!" mode, something used wh
Dear Michael,
> I did not check how these call behave individually, just a few
> comments while putting my eyes on the patch.
>
> + if (!IsUnderPostmaster)
> + elog(ERROR,
> + "slot operation is prohibited in the single user
> mode");
>
> elog() should not b
On Wed, Feb 19, 2025 at 05:35:18PM +, David Steele wrote:
> I like this idea but I would prefer to get the patch committed as-is first.
> The reason is that I'm hoping to see this batch-patched (since it is a bug)
> and that is less likely if the message wording is change.
(Had this thread fla
On Tue, Feb 18, 2025 at 4:43 PM Melanie Plageman
wrote:
>
> On Mon, Feb 17, 2025 at 1:11 PM Masahiko Sawada wrote:
> >
> > On Fri, Feb 14, 2025 at 2:21 PM Melanie Plageman
> > wrote:
> > >
> > > Since the failure rate is defined as a percent, couldn't we just have
> > > parallel workers set eage
> But instead of blindly reducing the frequency via PRNG, we can take a more
> thoughtful approach with threshold by execute time:
> Find the most frequent query by column 'calls' in pg_stat_statements;
> In this query look at info about execution time: min_exec_time,
> max_exec_time, etc;
> Gra
On Wed, Feb 19, 2025 at 3:35 PM Andres Freund wrote:
> After thinking about this for an embarassingly long time, I think there's
> actually a considerably better answer for a case like this: A function that
> returns a fixed-length string by value:
>
> - Compilers can fairly easily warn about on-s
Hi,
On 2025-02-17 21:25:33 +0100, Jelte Fennema-Nio wrote:
> On Mon, 17 Feb 2025 at 18:24, Andres Freund wrote:
> > Why not do this only in the if (rlim.rlim_cur < nclients + 3) case?
>
> Done, I also changed it to not bump to rlim_max, but only to nclients
> + 3. The rest of the patches I'll up
> As you can see, the query has not been normalized. Is it a bug, expected or
> undefined behavior?
No, this behavior is expected. The ability to normalize a statement is
only available
during post_parse_analyze (pgss_post_parse_analyze), as this is when
we have access to
JumbleState.
In your ex
On Wed, Feb 19, 2025 at 02:57:34AM +, Hayato Kuroda (Fujitsu) wrote:
> Based on the discussion, I feel it is enough to add quick error out
> for SQL functions. PSA attached.
I did not check how these call behave individually, just a few
comments while putting my eyes on the patch.
+ if
> On 19 Feb 2025, at 23:08, Andrew Dunstan wrote:
> On 2024-10-31 Th 6:18 PM, Heikki Linnakangas wrote:
Thanks for review!
>> Perhaps sommething like this:
>>
>> "Close the psql session and clean up resources. Each psql session must be
>> closed with C before the end of the test.
>> Returns TR
On Wed, Feb 19, 2025 at 03:40:56PM +0800, Zhang Mingli wrote:
> Thanks for the correction.
No problem. If you see anything else that you think is misleading,
please feel free to ping me on this thread.
--
Michael
signature.asc
Description: PGP signature
On Wed, Feb 19, 2025 at 12:02 PM Matheus Alcantara
wrote:
> > Hardcoding to scram-sha-256 would also prohibit the use of GSS or
> > standard password auth, now that I think about it. The docs currently
> > have a note about being able to choose... Should we add the other
> > permitted authenticati
Attached is a rebase which fixes a few smaller things (and a pgperltidy run);
and adds a paragraph to the docs about how HBA clientname settings can't be
made per certificate set in an SNI config. As discussed with Jacob offlist,
there might be a case for supporting that but it will be a niche use
On Fri, Feb 14, 2025 at 9:32 AM Andres Freund wrote:
> I think we'll need to add some logic in read stream that only disables advice
> after a longer sequential sequence. Writing logic for that shouldn't be too
> hard, I think? Determining the concrete cutoffs is probably harder, although I
> thin
On 19.02.2025 22:11, Sami Imseih wrote:
I don't see v18 attached.
Ah, sorry, I attached v18.
But, I think it's wrong that you changed the design of this patch
(sample rate to duration based ) after it was ready for committer.
I've decided to reconsider how to better reduce the load on
On 2/18/25 13:29, Heikki Linnakangas wrote:
> On 18/02/2025 14:01, Tomas Vondra wrote:
>> On 2/4/25 17:54, Tomas Vondra wrote:
>>> On 2/4/25 16:02, Tomas Vondra wrote:
...
Thanks for the report. And yeah, clamping it to 1 seems like the right
fix for this. I wonder if it's worth
> On 19 Feb 2025, at 23:44, Magnus Hagander wrote:
> One thing that should work is to send it from an account with the actual
> postgresql.org domain on it.
I've just confirmed that this works, so we have a way forward on this.
--
Daniel Gustafsson
On Wed, Feb 19, 2025 at 11:19 PM Jelte Fennema-Nio
wrote:
> On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson wrote:
> > There is functionality in the CF app to send an email to authors with a
> patch
> > still in the previous commitfest, it would be quite trivial to alert
> everyone.
> >
> > We s
> On 19 Feb 2025, at 23:18, Jelte Fennema-Nio wrote:
>
> On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson wrote:
>> There is functionality in the CF app to send an email to authors with a patch
>> still in the previous commitfest, it would be quite trivial to alert
>> everyone.
>>
>> We should
On 2025-02-19 We 1:03 PM, Jelte Fennema-Nio wrote:
On Wed, 19 Feb 2025 at 17:32, Robert Haas wrote:
What *I* think is incredibly painful is that I can spend an
hour going through the CommitFest and not find a single patch that
needs a review. And it's not just me.I have heard of multiple cases
On 2025-02-19 We 4:23 PM, Florents Tselai wrote:
On 18 Jan 2025, at 11:51 AM, Florents Tselai
wrote:
On 8 Jan 2025, at 6:45 PM, Andrew Dunstan wrote:
On 2024-09-17 Tu 4:53 PM, Florents Tselai wrote:
We could, if we're going to do anything at all in this area.
Another possib
On Wed, 19 Feb 2025 at 17:24, Daniel Gustafsson wrote:
> There is functionality in the CF app to send an email to authors with a patch
> still in the previous commitfest, it would be quite trivial to alert everyone.
>
> We should of course also add some form of messaging in the app itself to make
On 2024-10-31 Th 6:18 PM, Heikki Linnakangas wrote:
On 31/10/2024 14:27, Daniel Gustafsson wrote:
On 28 Oct 2024, at 11:56, Heikki Linnakangas wrote:
On 09/04/2024 20:10, Daniel Gustafsson wrote:
=item $session->quit
Close the session and clean up resources. Each test run must be
closed wi
On Wed, Feb 19, 2025 at 04:36:05PM -0500, Melanie Plageman wrote:
> This makes me think I should also not cap relallfrozen when using it
> in relation_needs_vacanalyze(). There I cap it to relallvisible and
> relallvisible is capped to relpages. One of the ideas behind letting
> people modify these
Sergey Belyashov writes:
> The 4th patch is not applicable for the current REL_17_STABLE branch.
> There are a lot of differences from master in the worker.c.
If you want to try the committed v17 patch, see
https://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=788baa9a25ae83b576621166367
On Mon, Feb 17, 2025 at 11:11 AM Nathan Bossart
wrote:
>
> On Fri, Feb 07, 2025 at 03:05:09PM -0600, Nathan Bossart wrote:
> > Okay, I'll actually look at the patches next...
Thanks for taking a look!
> I'm not sure I understand the reason for capping relallfrozen to
> relallvisible. From upthr
On 18 Jan 2025, at 11:51 AM, Florents Tselai wrote:On 8 Jan 2025, at 6:45 PM, Andrew Dunstan wrote:On 2024-09-17 Tu 4:53 PM, Florents Tselai wrote:We could, if we're going to do anything at all in this area. Another possibility would be to provide a second optional parameter for json{b}_strip_nul
On Thu, Feb 13, 2025 at 5:51 PM Thomas Munro wrote:
>
> On Fri, Feb 14, 2025 at 5:52 AM Melanie Plageman
> wrote:
> > On Thu, Feb 13, 2025 at 11:28 AM Tomas Vondra wrote:
> > > On 2/13/25 17:01, Melanie Plageman wrote:
> > > I know it's not changing how much memory we allocate (compared to
> > >
Hello,
I think the business with an evergrowing on_exit list needs a different
solution than a gigantic array of entries. Maybe it would make sense to
restructure that code so that there's a single on_exit item, but there
exists a list of per-database entries to clean up which are all done in
one
I've pushed the first (and main) part of the patch series, after some
more cleanup and comment polishing.
As explained in my previous message, I'm not sure about 0002. I don't
know if we need to worry about it (no reports AFAICS). And while the
patch works I'm not sure it's the best fix, or whethe
On Thu, Feb 13, 2025 at 8:25 PM Jacob Champion
wrote:
> > I also agree that we should enforce the use of the SCRAM on the remote for
> > safety. To do this I think that we could set require_auth=scram-sha-256 on
> > connection options if SCRAM pass-through is being used, with this we will
> > get
On Wed, Feb 19, 2025 at 6:13 AM Daniel Gustafsson wrote:
> The attached rebased has your 0002 fix as well as some minor tweaks like a few
> small whitespace changes from a pgperltidy run and a copyright date fix which
> still said 2024.
LGTM.
Thanks!
--Jacob
I don't see v18 attached.
But, I think it's wrong that you changed the design of this patch
(sample rate to duration based ) after it was ready for committer.
This CF [0] should go back to "Needs Review" if this is the case.
--
Sami
[0] https://commitfest.postgresql.org/patch/5390/
On Tue, Feb 18, 2025 at 3:23 PM Noah Misch wrote:
>
> Apart from two doc issues, this is ready:
>
> On Tue, Feb 18, 2025 at 01:23:20PM -0800, Masahiko Sawada wrote:
> > On Mon, Feb 17, 2025 at 2:57 PM Noah Misch wrote:
> > > On Fri, Jan 17, 2025 at 05:11:41PM -0800, Masahiko Sawada wrote:
>
> > +
st 19. 2. 2025 v 19:05 odesílatel Andres Freund napsal:
> Hi,
>
> On 2025-02-19 01:48:53 -0500, Tom Lane wrote:
> > Pavel Stehule writes:
> > > I investigated the crashes in "xmlnamespaces to xmlelement" patch and
> it
> > > looks like there was a badly used makeString function. The argument
> s
On Wed, Feb 19, 2025 at 8:32 AM Robert Haas wrote:
> I respectfully but firmly question your definition of "incredibly
> painful". What *I* think is incredibly painful is that I can spend an
> hour going through the CommitFest and not find a single patch that
> needs a review. And it's not just me
Hi,
On 2025-02-19 01:48:53 -0500, Tom Lane wrote:
> Pavel Stehule writes:
> > I investigated the crashes in "xmlnamespaces to xmlelement" patch and it
> > looks like there was a badly used makeString function. The argument should
> > not be null, elsewhere serialization to string fails - and dese
On Wed, 19 Feb 2025 at 17:32, Robert Haas wrote:
> What *I* think is incredibly painful is that I can spend an
> hour going through the CommitFest and not find a single patch that
> needs a review. And it's not just me.I have heard of multiple cases
> of people wanting to get involved in patch rev
Em qua., 19 de fev. de 2025 às 14:48, Ranier Vilela
escreveu:
> Em ter., 18 de fev. de 2025 às 13:29, Ranier Vilela
> escreveu:
>
>>
>> Em ter., 18 de fev. de 2025 13:21, Tom Lane escreveu:
>>
>>> Ranier Vilela writes:
>>> > There are some reports that Postgres does not handle correctly
>>> cl
Em ter., 18 de fev. de 2025 às 13:29, Ranier Vilela
escreveu:
>
> Em ter., 18 de fev. de 2025 13:21, Tom Lane escreveu:
>
>> Ranier Vilela writes:
>> > There are some reports that Postgres does not handle correctly cleaning
>> the
>> > files used when it crashes. [1]
>> > I think that function
You mentioned fillfactor only on cluster notes, would be good to mention it
on refsynopsisdiv, I think.
+
+ REPACK reclaims storage occupied by dead
+ tuples. Unlike VACUUM, it does so by rewriting the
+ entire contents of the table specified
+ by table_name into a new
disk
- file wit
Hi,
On 2025-02-19 10:41:53 -0500, Andres Freund wrote:
> I'm planning to wait for a few hours and see what the BF says and then push
> the fix this thread is about to all supported branches.
Not having seen any issues, I pushed the fix.
Thanks for the reviews etc!
Greetings,
Andres Freund
On 2/19/25 03:51, Benoit Lobréau wrote:
I think the changes make sense. Would it be helpful to add the origin of
the checkpoint record we are referring to ? (i.e. control file or backup
label).
For example:
* Latest checkpoint in the control file is at %X/%X on timeline %u,
* Checkpoint loc
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.
> >
> > Well, looks like this patch-set
Hi,
On 2025-02-17 09:24:24 +0900, Michael Paquier wrote:
> On Sun, Feb 16, 2025 at 07:03:39PM -0500, Andres Freund wrote:
> > Cool, will after the minor release freeze.
>
> Thanks, Andres. If you'd prefer that I double-check the code and do
> it as the former committer of these two ones, please l
On Wed, Feb 19, 2025 at 10:30 AM Jelte Fennema-Nio wrote:
> Moving stuff to the next commitfest is incredibly painful at the
> moment. It currently takes 4 clicks per patch to move it to the next
> commitfest. We could probably get this to 1 per patch with some UX
> redesign. But that still means
On Wed, Feb 19, 2025 at 8:30 AM Jelte Fennema-Nio
wrote:
> On Wed, 19 Feb 2025 at 16:02, Daniel Gustafsson wrote:
> > The opposite, which was discussed at length at FOSDEM, was to ask
> authors to
> > click a single button once a month at most. If that level of engagement
> is too
> > much to a
> On 19 Feb 2025, at 16:24, Aleksander Alekseev
> wrote:
>
> Hi,
>
>> How about having the cfbot send out some nagmail to patch authors,
>> saying "please move your patch forward, or close it if no longer
>> interested"? If nothing happens after a few rounds of that,
>> an auto-close could be
On 2025-Feb-10, Suraj Kharage wrote:
> Thanks, Alvaro, for the review.
>
> I have addressed your comments per the above suggestions in the attached v4
> patch.
Okay, thanks. It looks good to me, but I realized a few days ago that
this patch affects the same code as the patch from Amul Sul to ch
On 19/2/2025 15:01, Ilia Evdokimov wrote:
If we want to convey this information more clearly, we should consider a
more explicit approach. For example, instead of using a fractional
value, we could display the minimum and maximum row counts observed
during execution (e.g.,rows=10..20, formattin
On Wed, 19 Feb 2025 at 16:02, Daniel Gustafsson wrote:
> The opposite, which was discussed at length at FOSDEM, was to ask authors to
> click a single button once a month at most. If that level of engagement is
> too
> much to ask then maybe said authors should question why they in return ask
>
On Wed, 19 Feb 2025 at 01:42, Dean Rasheed wrote:
>
> One thing I don't like about this is that it's introducing more code
> duplication between pullup_replace_vars() and
> ReplaceVarsFromTargetList(). Those already had a lot of code in common
> before RETURNING OLD/NEW was added, and this is dupl
Hi,
> How about having the cfbot send out some nagmail to patch authors,
> saying "please move your patch forward, or close it if no longer
> interested"? If nothing happens after a few rounds of that,
> an auto-close could be justified.
Well, it is a possibility of course. If I read the current
Aleksander Alekseev writes:
>> On Feb 19, 2025, at 10:02 AM, Daniel Gustafsson wrote:
>>> The opposite, which was discussed at length at FOSDEM, was to ask authors to
>>> click a single button once a month at most. If that level of engagement is
>>> too
>>> much to ask then maybe said authors s
Hi,
> > On Feb 19, 2025, at 10:02 AM, Daniel Gustafsson wrote:
> > The opposite, which was discussed at length at FOSDEM, was to ask authors to
> > click a single button once a month at most. If that level of engagement is
> > too
> > much to ask then maybe said authors should question why they
> On Feb 19, 2025, at 10:02 AM, Daniel Gustafsson wrote:
> The opposite, which was discussed at length at FOSDEM, was to ask authors to
> click a single button once a month at most. If that level of engagement is
> too
> much to ask then maybe said authors should question why they in return as
> On 19 Feb 2025, at 10:25, Jelte Fennema-Nio wrote:
>
> Since the next commitfest is starting soon, I think for now we should
> move all entries still open in the January commitfest to the March
> commitfest. There's a bunch that are still not moved, that I know
> should be moved. For example[1]
Hi,
> I think this sounds much more reasonable than what's happening now.
> But I think we need to make the flow a bit more clear:
> 1. Add a "no interest" reason for closing.
> 2. Add a label[2]/column that specifies that an entry will be closed
> as "no interest" automatically at the end of this
On 14.02.2025 16:17, Ilia Evdokimov wrote:
Hi hackers,
I've decided to explore a slightly different approach to reducing
spinlock contention—by introducing a simple execution time threshold.
If a query’s execution time exceeds this threshold, it is recorded in
pg_stat_statements; otherwise,
On 18.02.2025 23:55, Andrei Lepikhov wrote:
On 17/2/2025 15:19, Robert Haas wrote:
On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov
if (nloops > 1)
Instead of:
if (nloops > 1 && rows_is_fractonal)
I don't think it's really safe to just cast a double back to int64. In
practice, the number of t
On Fri, Feb 14, 2025 at 7:16 PM Andres Freund wrote:
Hi,
> On 2025-02-14 18:36:37 +0100, Tomas Vondra wrote:
> > All of this is true, ofc, but maybe it's better to have a tool providing
> > at least some advice
>
> I agree, a tool like that would be useful!
>
> One difficulty is that the relevan
On Wed, 19 Feb 2025 at 15:57, Amit Kapila wrote:
>
> On Wed, Dec 18, 2024 at 12:51 PM vignesh C wrote:
> >
> > The attached patch has the changes for the same.
> >
>
> @@ -3037,10 +3037,6 @@ my %tests = (
> \QALTER PUBLICATION pub1 ADD TABLE ONLY dump_test.test_table;\E
> /xm,
> like => { %
On Tue, 18 Feb 2025 at 10:00, Srinath Reddy wrote:
>
> Hi,
> i think during restore we should not force user to use -C during cases like
> ./pg_restore pdd -g -f -
> ./pg_restore pdd -a -f -
> ./pg_restore pdd -s -f -
> because its not good to use -C to create database every time when we are
> us
hi.
Currently, pg_retore says
--exit-on-error
Exit if an error is encountered while sending SQL commands to the
database. The default is to continue and to display a count of errors
at the end of the restoration.
Do we need to apply this to restore executing global commands (create
role, create ta
On Tue, 18 Feb 2025 at 15:26, Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, February 17, 2025 7:31 PM Shlok Kyal
> wrote:
> >
> > On Thu, 13 Feb 2025 at 15:54, vignesh C wrote:
> > >
> > > On Tue, 4 Feb 2025 at 15:27, Shlok Kyal wrote:
> > > >
> > > > Hi,
> > > >
> > > > Currently, we can copy an
On Tue, 18 Feb 2025 at 10:00, Srinath Reddy wrote:
>
> Hi,
> i think during restore we should not force user to use -C during cases like
> ./pg_restore pdd -g -f -
> ./pg_restore pdd -a -f -
> ./pg_restore pdd -s -f -
> because its not good to use -C to create database every time when we are
> us
Dear Shubham,
Thanks for updating the patch!
> I have added a test case for non-dry-run mode to ensure that
> replication slots, subscriptions, and publications work as expected
> when '--all' is specified. Additionally, I have split the test file
> into two parts:
> 1) Command-line sanity checks
On Wed, Feb 19, 2025 at 11:27 AM Jakub Wartak
wrote:
>
> Hi pg-hackers and postgis-hackers, sorry for cross-posting but we
> think it really affects how those two products work together. This is
> about pg_upgrade failure for tables with custom SRIDs.
>
> PostGIS is an extension that uses a specia
Added the CF entry for the same -
https://commitfest.postgresql.org/patch/5583/
Regards,
Ayush Vatsa
SDE AWS
>
Hi pg-hackers and postgis-hackers, sorry for cross-posting but we
think it really affects how those two products work together. This is
about pg_upgrade failure for tables with custom SRIDs.
PostGIS is an extension that uses a special table called
public.spatial_ref_sys for handling available spat
On Wed, Dec 18, 2024 at 12:51 PM vignesh C wrote:
>
> The attached patch has the changes for the same.
>
@@ -3037,10 +3037,6 @@ my %tests = (
\QALTER PUBLICATION pub1 ADD TABLE ONLY dump_test.test_table;\E
/xm,
like => { %full_runs, section_post_data => 1, },
- unlike => {
- exclude_dump_te
Hello Everyone,
It seems there's a general consensus that we should maintain a
original design to support pg_prewarm, with a minor adjustment:
when querying indexes, we should verify the privileges of the parent table.
I’ve attached a patch for this, which includes some test cases as well.
Let me
On Tue, Feb 18, 2025 at 8:42 AM Amit Kapila wrote:
>
> On Mon, Feb 17, 2025 at 10:18 PM Nathan Bossart
> wrote:
> >
> > On Mon, Feb 17, 2025 at 07:57:22AM +0530, Amit Kapila wrote:
> >
> > > Alvaro, Nathan, do let us know if you would like to discuss more on
> > > the use case for this new GUC id
Hi,
On Mon, Feb 17, 2025 at 12:07:56PM -0800, Masahiko Sawada wrote:
> On Fri, Feb 14, 2025 at 2:35 AM Bertrand Drouvot
> wrote:
> > Yeap, that was exactly my point when I mentioned the custodian thread
> > (taking
> > into account Tom's comment quoted above).
> >
>
> I've written PoC patches t
On Tue, Feb 18, 2025 at 2:52 PM Andrei Lepikhov wrote:
> On 17/2/2025 02:06, Alexander Korotkov wrote:
> > On Thu, Nov 28, 2024 at 4:39 AM Andrei Lepikhov wrote:
> >> Here we also could count number of scanned NULLs separately in
> >> vardata_extra and use it in upper GROUP-BY estimation.
> >
> >
Hi,
I think the changes make sense. Would it be helpful to add the origin of
the checkpoint record we are referring to ? (i.e. control file or backup
label).
For example:
* Latest checkpoint in the control file is at %X/%X on timeline %u,
* Checkpoint location in the backup_label file is at
Hi, Vlada.
On Tue, Feb 18, 2025 at 6:56 PM Vlada Pogozhelskaya
wrote:
> Following the discussion on improving statistics estimation by considering
> GROUP BY as a unique constraint, I’ve prepared a patch that integrates GROUP
> BY into cardinality estimation in a similar way to DISTINCT.
>
> Th
Since the next commitfest is starting soon, I think for now we should
move all entries still open in the January commitfest to the March
commitfest. There's a bunch that are still not moved, that I know
should be moved. For example[1] which we discussed at FOSDEM and seems
to have a reasonable chan
> Hm. Any idea why that is? I wonder if the compiler isn't using as many
> SVE registers as it could for this.
Not sure, we tried forcing loop unrolling using the below line in the MakeFile
but the results are the same.
pg_popcount_sve.o: CFLAGS += ${CFLAGS_UNROLL_LOOPS} -march=native
> I've
Hi,
On Wed, Feb 19, 2025 at 01:32:33PM +0900, Michael Paquier wrote:
> These additions feel unbalanced with the existing contents, and
> overlap with the follow-up paragraph about the tuning that can be
> guessed from the contents of pg_stat_io because the new content refers
> twice to the section
Ok you mean that xid64 will remove the need for freezing... it's a way to
see things.
Le mar. 18 févr. 2025 à 15:57, Greg Sabino Mullane a
écrit :
> On Tue, Feb 18, 2025 at 9:17 AM Sébastien wrote:
>
>> Sorry it won't work. It just delays the problem. But still the freeze
>> procedure must rewr
Tom Lane writes:
> Andy Fan writes:
>> Tom Lane writes:
>>> Many years ago, we committed a patch to do exactly that. We had
>>> to back it out again because it broke too many real-world scenarios.
>>> I'm too lazy to search the archives for you, but you might be able
>>> to find the commit and
On 2025/02/19 2:06, Sagar Shedge wrote:
Hi Fujii,
On Tue, Feb 18, 2025 at 10:25 PM Fujii Masao
wrote:
I assume you're planning to extend postgres_fdw_get_connections() to
also return the result of PQbackendPID(entry->conn).
However, the patch you attached doesn't seem to include that chan
It seems that the patch doesn't compile on macOS, it is unable to map 'i'
and 'len' which are of type 'size_t' to 'uint64'. This appears to be a mac
specific
issue. The latest patch should resolve this by casting 'size_t' to 'uint64'
before
passing it to 'svwhilelt_b8'.
[11:04:07.478] ../src/back
100 matches
Mail list logo
