On Thu, Jan 16, 2025 at 3:05 PM Zhang Mingli wrote:
>
>
> Thank you for your help! That’s certainly a viable approach to logging the
> plan during the REFRESH operation.
> However, I want to clarify that we’re particularly interested in examining
> the SQL cases. When there are numerous queries
On Thu, Jan 16, 2025 at 07:12:34AM +, Bertrand Drouvot wrote:
> From what I can see, the above proposal does (at least) silent the warning
> here (clang 5.0.1 and same as demoiselle): https://godbolt.org/z/cGosfzGne (we
> can see the warning by using the current define and that the warning is g
On Wed, Jan 15, 2025 at 05:00:51PM -0800, Noah Misch wrote:
> I agree with accepting +4 bytes in GlobalTransactionData.
Let's just bite the bullet and do that on HEAD and v17, then,
integrating deeper FullTransactionIds into the internals of
twophase.c.
> I think "using the current epoch" is wron
On 15.01.2025 23:09, Melanie Plageman wrote:
On Wed, Jan 15, 2025 at 12:08 PM Alena Rybakina
wrote:
This is interesting, but I think it might belong as commentary in
vacuumparallel.c instead.
I added some description about it, I hope it is fine. I attached
vacuum_description.diff
Alena, tha
Hi,
On Thu, Jan 16, 2025 at 04:09:44PM +0900, Shinya Kato wrote:
> On Thu, Jan 16, 2025 at 3:31 PM Michael Banck wrote:
> > I do think having a whitelist of allowed-to-be-installed extensions
> > (similar/like https://github.com/dimitri/pgextwlist) makes sense
> > additionally in today's containe
Hi
st 15. 1. 2025 v 21:35 odesílatel Jim Jones
napsal:
> Hi Umar, Hi Pavel,
>
> On 26.12.24 14:46, Jim Jones wrote:
> > The idea of NO DEFAULT is pretty much to free an element (and its
> > children) from a previous DEFAULT in the same scope.
> >
> > SELECT
> > xmlserialize(DOCUMENT
> > xm
On 16.01.25 07:11, Pavel Stehule wrote:
> It is better.
v2 attached updates the documentation.
>
> My note was related to a very different description of this
> functionality in DB2. So if you propose this function for better
> compatibility (and this function is implemented only by db2), it is
>
Hi,
On Thu, Jan 16, 2025 at 12:47:17AM -0500, Tom Lane wrote:
> Michael Paquier writes:
> > Not completely sure about the number of parenthesis, but I hope that
> > this should be enough (extra set around io_op):
> > +#define pgstat_is_ioop_tracked_in_bytes(io_op) \
> > + (((unsigned int) (io_o
On Thu, Jan 16, 2025 at 3:31 PM Michael Banck wrote:
I agree with this idea.
I think it is natural to delegate a part of superuser privileges to
another role because superuser privilege is too strong.
> > In general, this concept is rather dubious. Why should we have such a
> > dangerous pre-def
On Mon, Jan 13, 2025 at 12:22 PM vignesh C wrote:
>
> On Thu, 2 Jan 2025 at 15:57, Nisha Moond wrote:
> >
> > Thank you for your feedback! Please find the v59 patch set addressing
> > all the comments.
> > Note: There are no new changes in patch-0001.
>
> Few comments:
> 1) I felt we should not i
Hi
Zhang Mingli
www.hashdata.xyz
On Jan 16, 2025 at 14:04 +0800, Yugo Nagata , wrote:
>
> You will be able to log the plan during the REFRESH by using auto_explain and
> setting
> log_analyze and log_nested_statements to on.
Hi Yugo,
Thank you for your help! That’s certainly a viable approach
On Wed, Jan 15, 2025 at 11:37 AM Shlok Kyal wrote:
>
> On Thu, 2 Jan 2025 at 15:57, Nisha Moond wrote:
> >
> > On Thu, Jan 2, 2025 at 8:16 AM Peter Smith wrote:
> > >
> > > Hi Nisha,
> > >
> > > Here are some minor review comments for patch v58-0002.
> > >
> >
> > Thank you for your feedback! Pl
On Thu, Jan 16, 2025 at 12:12 PM Shlok Kyal wrote:
>
> On Thu, 16 Jan 2025 at 10:48, Shubham Khanna
> wrote:
> >
> > On Wed, Jan 15, 2025 at 3:28 AM Peter Smith wrote:
> > >
> > > Hi Shubham.
> > >
> > > Patch v9-0001 LGTM.
> > >
> >
> > Upon reviewing the v9-0001 patch, I noticed that running '
Hi,
On Thu, Jan 16, 2025 at 09:55:10AM +0900, Michael Paquier wrote:
> On Wed, Jan 15, 2025 at 05:20:57PM +0300, Nazir Bilal Yavuz wrote:
> > I think allowing only pgStatPendingContext to have
> > MemoryContextAllowInCriticalSection() is not enough. We need to allow
> > at least pgStatSharedRefCon
On Thu, 16 Jan 2025 at 10:48, Shubham Khanna
wrote:
>
> On Wed, Jan 15, 2025 at 3:28 AM Peter Smith wrote:
> >
> > Hi Shubham.
> >
> > Patch v9-0001 LGTM.
> >
>
> Upon reviewing the v9-0001 patch, I noticed that running 'pg perltidy'
> was necessary. To ensure the patch adheres to the required co
Hi,
>
> c=1 && \
> psql -c checkpoint -c 'select pg_switch_wal()' && \
> pgbench -n -M prepared -c$c -j$c -f <(echo "SELECT
> pg_logical_emit_message(true, 'test', repeat('0', 8192));";) -P1 -t 1
>
> wal_init_zero = 1: 885 TPS
> wal_init_zero = 0: 286 TPS.
Your theory looks clear and t
st 15. 1. 2025 v 22:05 odesílatel Jim Jones
napsal:
> Hi Pavel
>
> On 14.01.25 09:14, Pavel Stehule wrote:
> > I did some research and the design of this document is different
> >
> > 1. Oracle doesn't support this
> > 2. DB2 has different implementations for z/OS (variadic) and for unix
> > (non
On Thu, 16 Jan 2025 12:39:06 +0800
Zhang Mingli wrote:
> Hi, all
>
>
> I am currently exploring the execution of the REFRESH MATERIALIZED VIEW
> command and have a specific question regarding the underlying query plan. As
> you know, the REFRESH command is a utility command, and using EXPLAI
On Wed, 15 Jan 2025 14:40:19 -0800
Jeff Davis wrote:
> My apologies, I sent the previous email prematurely. Let me try again:
>
> On Wed, 2025-01-15 at 14:34 -0800, Jeff Davis wrote:
> > On Wed, 2025-01-15 at 01:40 +0900, Yugo NAGATA wrote:
> > > > > For example, "t ~~ '123foo%'" is converted to
Michael Paquier writes:
> Not completely sure about the number of parenthesis, but I hope that
> this should be enough (extra set around io_op):
> +#define pgstat_is_ioop_tracked_in_bytes(io_op) \
> + (((unsigned int) (io_op)) < IOOP_NUM_TYPES && \
> + ((unsigned int) (io_op)) >= IOOP_EXT
On Thu, Jan 16, 2025 at 12:18:38AM -0500, Tom Lane wrote:
> However, the macro does provide a convenient place to hang the
> warning comment about keeping it sync'd with the enum.
> Personally I'd keep the macro but move it to pgstat.h, close
> to the enum declaration, so that there's more than eps
On Thu, Jan 16, 2025 at 3:26 PM Tom Lane wrote:
>
> Peter Smith writes:
> > During some recent reviews, I came across some comments mentioning "toast"
> > ...
> > TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
> > Technique" [1].
>
> It is indeed an acronym, but usages such a
On Wed, Jan 15, 2025 at 10:12:51PM -0300, Ranier Vilela wrote:
> Fix by checking the return and reporting a message to the user,
> in case of failure.
You are right that it is inconsistent to not check the result returned
by these two calls of pg_b64_encode(), as introduced in 761c79508e7f.
Peter?
hi.
in master src/bin/pg_dump/pg_restore.c: main function
if (opts->tocSummary)
PrintTOCSummary(AH);
else
{
ProcessArchiveRestoreOptions(AH);
RestoreArchive(AH);
}
opts->tocSummary is true (pg_restore --list), no query will be executed.
but your patch (pg_re
Michael Paquier writes:
> Just for an assert, I would just remove the macro rather than have an
> inline function.
Oh, I'd not noticed that there is only one caller.
However, the macro does provide a convenient place to hang the
warning comment about keeping it sync'd with the enum.
Personally I
On Wed, Jan 15, 2025 at 3:28 AM Peter Smith wrote:
>
> Hi Shubham.
>
> Patch v9-0001 LGTM.
>
Upon reviewing the v9-0001 patch, I noticed that running 'pg perltidy'
was necessary. To ensure the patch adheres to the required coding
standards, I have applied 'pg perltidy' and made the necessary
adju
On Wed, Jan 15, 2025 at 11:34:14PM -0500, Tom Lane wrote:
> Michael Paquier writes:
> > I cannot reproduce that, perhaps I'm just missing something with these
> > switches. Do you think that a cast would cool things? Please see the
> > attached for the idea.
>
> There are only three animals sho
On Wed, Jan 15, 2025 at 4:57 PM Amit Kapila wrote:
>
> LGTM. I'll push this tomorrow unless there are more comments. I am
> planning to push this to HEAD as this is an improvement in existing
> docs and not any bug fix.
>
Pushed.
--
With Regards,
Amit Kapila.
Hi, all
I am currently exploring the execution of the REFRESH MATERIALIZED VIEW command
and have a specific question regarding the underlying query plan. As you know,
the REFRESH command is a utility command, and using EXPLAIN REFRESH does not
provide a plan structure for analysis.
During de
Peter Smith writes:
> During some recent reviews, I came across some comments mentioning "toast" ...
> TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
> Technique" [1].
It is indeed an acronym, but usages such as "toasting" are all over
our code and docs, as you see. I questio
Michael Paquier writes:
> I cannot reproduce that, perhaps I'm just missing something with these
> switches. Do you think that a cast would cool things? Please see the
> attached for the idea.
There are only three animals showing this warning (ayu, batfish,
demoiselle) so it likely requires par
On Wed, 15 Jan 2025 at 12:00, Peter Smith wrote:
>
> During my review of Vignesh's patch for the enum-version of
> publish_generated_columns, I was thinking of yet another way to
> specify which columns to replicate.
>
> My idea below is analogous to the existing 'publish' option; Instead
> of add
On Wed, Jan 15, 2025 at 12:19:03PM -0500, Tom Lane wrote:
> I don't see a reasonable way to alter that check to suppress this;
> for instance, "(io_op) <= IOOP_WRITE" would probably still draw the
> same warning. I think most likely we have to remove that check, ie
>
> #define pgstat_is_ioop_tra
Hi,
During some recent reviews, I came across some comments mentioning "toast" ...
TOAST is a PostgreSQL acronym for "The Oversized-Attribute Storage
Technique" [1].
But, toast is just toast [2].
~
AFAIK it is usual practice to uppercase acronyms to distinguish them
from ordinary words, but Po
hi.
in src/bin/pg_dump/pg_dumpall.c
appendPQExpBuffer(buf, " FROM pg_auth_members a "
"LEFT JOIN %s ur on ur.oid = a.roleid "
"LEFT JOIN %s um on um.oid = a.member "
"LEFT JOIN %s ug on ug.oid = a.grantor "
jian he writes:
> in src/bin/pg_dump/pg_dumpall.c
> appendPQExpBuffer(buf, " FROM pg_auth_members a "
> "LEFT JOIN %s ur on ur.oid = a.roleid "
> "LEFT JOIN %s um on um.oid = a.member "
> "LEFT JOIN %s ug on ug.oid = a.grantor "
On Wed, Jan 15, 2025 at 02:41:31PM +0900, Michael Paquier wrote:
> On Tue, Jan 14, 2025 at 11:48:28AM -0800, Noah Misch wrote:
> > I misunderstood, and I was mistaken to see this as a bug fix. The
> > isolationtester is acting per its definition, and this would be a definition
> > change. Do othe
On Sun, Dec 15, 2024 at 10:10 AM Tomas Vondra wrote:
>
> I've been looking at some other vacuum-related patches, so I took a look
> at these remaining bits too. I don't have much to say about the code
> (seems perfectly fine to me), so I decided to do a bit of testing.
Thanks for doing this!
> I
On Thu, Jan 16, 2025 at 4:28 AM Masahiko Sawada wrote:
>
> On Sun, Jan 12, 2025 at 10:52 PM Peter Smith wrote:
> >
> > On Fri, Jan 10, 2025 at 8:28 PM Masahiko Sawada
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jan 7, 2025 at 11:30 PM Peter Smith wrote:
> > > >
> > > > Hi Sawada-San.
> > >
"Anton A. Melnikov" writes:
> Seems it is possible to exclude much less code from checking
> under valgrind and get the same result by replacing the only
> function call pg_rightmost_one_pos64() with a valgrind-safe
> code. See the attached patch, please.
There is no place anywhere in our code ba
David Rowley writes:
> I agree that the evidence you (John) gathered is enough reason to use
> memcpy().
Okay ... doesn't quite match my intuition, but intuition is a poor
guide to such things.
regards, tom lane
On Thu, Jan 16, 2025 at 12:47 PM Nathan Bossart
wrote:
> On Thu, Jan 16, 2025 at 11:07:41AM +1300, Thomas Munro wrote:
> > +1 for your idea of not defining them at all outside the backend, it's
> > just confusing noise.
>
> I tried that, but these extra signals are needed even in the frontend for
Hi, John!
On 19.12.2024 12:48, John Naylor wrote:
That would actually be a maintenance headache because the function is
inlined, but here's a better idea: We already have a fallback path for
when the string is not suitably aligned, or in 32-bit builds. We could
just use that under Valgrind:
s
Hi.
Per Coverity.
CID 1590024:(CHECKED_RETURN)
Calling "pg_b64_encode" without checking return value (as is done elsewhere
8 out of 10 times).
The function *pg_b64_encode* has in the comments:
[0] "and -1 in the event of an error"
So, the function can fail.
All other calls check the return
On Mon, Dec 30, 2024 at 10:08:31AM +0900, Michael Paquier wrote:
> On Fri, Dec 27, 2024 at 06:16:24PM +0300, Vitaly Davydov wrote:
> > As an idea, I would like to propose to store FullTransactionId in
> > global transaction state instead of TransactionId. I'm not sure, it
> > will consume significa
On Wed, Jan 15, 2025 at 05:20:57PM +0300, Nazir Bilal Yavuz wrote:
> I think allowing only pgStatPendingContext to have
> MemoryContextAllowInCriticalSection() is not enough. We need to allow
> at least pgStatSharedRefContext as well to have
> MemoryContextAllowInCriticalSection() as it can be allo
On Wed, Jan 15, 2025 at 4:44 PM Tom Lane wrote:
> With this, I got plausible-looking html output (I didn't vet it
> in detail, but a couple of spot checks looked sane).
>
> I'm curious whether a similar workaround will help with the
> Debian toolchain.
Looks like it will.
I was able to get the l
On Wed, Jan 15, 2025 at 5:49 PM Amit Kapila wrote:
>
> On Wed, Jan 15, 2025 at 3:11 AM Masahiko Sawada wrote:
> >
> > It seems we agreed on RBTXN_IS_PREPARED and rbtxn_is_prepared().
> > Adding 'IS' seems to clarify the transaction having this flag *is* a
> > prepared transaction. Both other two
On Wed, Jan 15, 2025 at 10:35:42AM +0100, Alexander Kukushkin wrote:
> Thank you for picking it up. I briefly looked at both patches. The actual
> fix in XLogPageRead() looks good to me.
> I also agree with suggested refactoring, where there is certainly some room
> for improvement - $WAL_SEGMENT_
On Wed, 15 Jan 2025 at 23:57, John Naylor wrote:
>
> On Wed, Jan 15, 2025 at 2:14 PM Tom Lane wrote:
> > Compilers that inline memcpy() may arrive at the same machine code,
> > but why rely on the compiler to make that optimization? If the
> > compiler fails to do so, an out-of-line memcpy() cal
On Thu, Jan 16, 2025 at 11:07:41AM +1300, Thomas Munro wrote:
> +1 for your idea of not defining them at all outside the backend, it's
> just confusing noise.
I tried that, but these extra signals are needed even in the frontend for
pgkill(), etc. My next thought was to simply ignore signal() err
On Wed, Jan 15, 2025 at 9:24 PM Ajin Cherian wrote:
>
>
>
> On Wed, Jan 15, 2025 at 5:33 PM Shubham Khanna
> wrote:
> > Previously, the warning was necessary because the 'two-phase' option
> > was not available, and users needed to be informed about the default
> > behavior regarding 'two-phase'
My apologies, I sent the previous email prematurely. Let me try again:
On Wed, 2025-01-15 at 14:34 -0800, Jeff Davis wrote:
> On Wed, 2025-01-15 at 01:40 +0900, Yugo NAGATA wrote:
> > > > For example, "t ~~ '123foo%'" is converted to "(t >= '123foo'
> > > > AND
> > > > t < '123fop')"
> > > > and
On Wed, 2025-01-15 at 01:40 +0900, Yugo NAGATA wrote:
> > > For example, "t ~~ '123foo%'" is converted to "(t >= '123foo' AND
> > > t < '123fop')"
> > > and index scan can be used for this condition. On the other hand,
> > > "t ~~* '123foo'"
> > > cannot be converted and sequential scan is used.
On 15.01.25 12:28, Jakob Egger wrote:
On 14.01.2025, at 16:51, Jakob Egger wrote:
I've tried to create a patch with this change. I'm attaching it to
this message so that cfbot picks it up. (I was unable to reproduce the
issue locally)
Apologies, please disregard my last patch. It does not wo
On 15.01.25 22:15, Nathan Bossart wrote:
On Wed, Jan 15, 2025 at 03:31:12PM +0100, Peter Eisentraut wrote:
On 04.12.24 15:49, Peter Eisentraut wrote:
Here is a patch set in that direction. It renames RowCompareType to
CompareType and updates the surrounding commentary a bit. And then I'm
chan
On Thu, Jan 16, 2025 at 8:47 AM Nathan Bossart wrote:
> On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
> > Could be due to calling native signal() with a signal number other
> > than the 6 values required to work by the C standard?
>
> Looking closer, that probably makes more sense
Peter Geoghegan writes:
> On Wed, Oct 30, 2024 at 5:26 PM Peter Geoghegan wrote:
>> I've also been unable to generate coverage reports for some time (at
>> least on Debian, with LCOV version 2.0-1).
> I found a temporary workaround. I'm now once again able to produce
> html coverage reports on m
On Fri, 2025-01-10 at 16:36 -0800, Jeff Davis wrote:
> On Mon, 2024-12-16 at 12:49 -0800, Jeff Davis wrote:
> > On Wed, 2024-12-11 at 15:52 -0800, Jeff Davis wrote:
> > > Attached is a series of patches to implement full case mapping as
> > > the
> > > locale PG_UNICODE_FAST.
> >
> > Rebased and a
On Wed, Jan 15, 2025 at 03:31:12PM +0100, Peter Eisentraut wrote:
> On 04.12.24 15:49, Peter Eisentraut wrote:
>> Here is a patch set in that direction. It renames RowCompareType to
>> CompareType and updates the surrounding commentary a bit. And then I'm
>> changing the gist strategy mapping to
Hi Pavel
On 14.01.25 09:14, Pavel Stehule wrote:
> I did some research and the design of this document is different
>
> 1. Oracle doesn't support this
> 2. DB2 has different implementations for z/OS (variadic) and for unix
> (nonvariadic)
> 3. looks so db2 allows some concatenation of xml content
On Wed, Jan 15, 2025 at 01:47:18PM -0600, Nathan Bossart wrote:
> On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
>> Could be due to calling native signal() with a signal number other
>> than the 6 values required to work by the C standard?
>
> Looking closer, that probably makes mor
>
>
>
> I do like the idea of a "Statistics for ..." prefix, and I think it's
> doable.
>
And that's now implemented.
The caller needs some knowledge about that anyway, to correctly output
> the statistics dump when the schema is not requested. Tests should
> cover those cases, too.
>
Tests for
On Wed, Jan 15, 2025 at 3:03 PM Melanie Plageman
wrote:
>
> On Wed, Jan 15, 2025 at 2:36 PM Marcos Pegoraro wrote:
> >>
> > There is a typo on committed vacuumlazy.c file
> > * If the TID store fills up in phase I, vacuum suspends phase I, proceeds
> > to
> > * phases II and II, cleaning up th
On Thu, 2025-01-09 at 16:19 -0800, Jeff Davis wrote:
> On Mon, 2024-12-02 at 23:58 -0800, Jeff Davis wrote:
> > On Mon, 2024-12-02 at 16:39 +0100, Andreas Karlsson wrote:
> > > I feel your first patch in the series is something you can just
> > > commit.
> >
> > Done.
> >
> > I combined your pat
Hi Umar, Hi Pavel,
On 26.12.24 14:46, Jim Jones wrote:
> The idea of NO DEFAULT is pretty much to free an element (and its
> children) from a previous DEFAULT in the same scope.
>
> SELECT
> xmlserialize(DOCUMENT
> xmlelement(NAME "root",
> xmlnamespaces(DEFAULT 'http:/x.y/ns1'),
>
Thanks Jian for the review and testing.
On Wed, 15 Jan 2025 at 14:29, jian he wrote:
>
> On Sun, Jan 12, 2025 at 5:31 AM Mahendra Singh Thalor
> wrote:
> >
> > >
> > > you also need change
> > >
> > > -f > > class="parameter">filename
> > > --file= > > class="parameter">filena
On Wed, Jan 15, 2025 at 12:08 PM Alena Rybakina
wrote:
>
> This is interesting, but I think it might belong as commentary in
> vacuumparallel.c instead.
>
> I added some description about it, I hope it is fine. I attached
> vacuum_description.diff
Alena, thanks again for your review. I pushed th
Hi,
On 2025-01-15 09:12:17 +, Andy Fan wrote:
> It is unclear to me why do we need wal_init_zero. Per comments:
>
> /*
>* Zero-fill the file. With this setting, we do this the hard
> way to
>* ensure that all the file space has really been alloca
On Wed, Jan 15, 2025 at 2:36 PM Marcos Pegoraro wrote:
>>
>> On 14.01.2025 22:51, Melanie Plageman wrote:
>
>
> There is a typo on committed vacuumlazy.c file
> * If the TID store fills up in phase I, vacuum suspends phase I, proceeds to
> * phases II and II, cleaning up the dead tuples referenc
On Wed, Jan 15, 2025 at 2:21 PM Peter Eisentraut wrote:
> I have committed this. Thanks for the feedback.
Thanks for working on this.
Is it worth documenting how to get clangd working sensibly with
"--header-insertion=iwyu"?
I enabled it just now. I find that I can now use completion with a
ty
On Thu, Jan 16, 2025 at 08:21:08AM +1300, Thomas Munro wrote:
> On Thu, Jan 16, 2025 at 8:15 AM Nathan Bossart
> wrote:
>> On Tue, Jan 14, 2025 at 11:08:05PM -0500, Tom Lane wrote:
>> > I wonder why we redefine those values?
>>
>> I wondered the same. Those redefines have been there since commit
On 15.01.25 08:11, vignesh C wrote:
On Tue, 14 Jan 2025 at 19:08, Peter Eisentraut wrote:
I've also added a patch that addresses logical replication. It
basically adds back some of the prohibitions against including generated
columns in publications that have been lifted, but this time only
On 15.01.25 15:12, Dean Rasheed wrote:
On Tue, 14 Jan 2025 at 13:37, Peter Eisentraut wrote:
Here is a new patch with that fixed and also a few
tweaks suggested by Jian.
I'm hoping to push my RETURNING OLD/NEW patch [1] soon, so I thought
that I would check how it works together with this p
>
> On 14.01.2025 22:51, Melanie Plageman wrote:
>
There is a typo on committed vacuumlazy.c file
* If the TID store fills up in phase I, vacuum suspends phase I, proceeds
to
* phases II and II, cleaning up the dead tuples referenced in the current
TID
* store. This empties the TID store resume
On Thu, Jan 16, 2025 at 8:15 AM Nathan Bossart wrote:
> On Tue, Jan 14, 2025 at 11:08:05PM -0500, Tom Lane wrote:
> > Nathan Bossart writes:
> >> My guess is that this has something to do with redefining SIG_ERR in
> >> win32_port.h. We might be able to use push_macro/pop_macro to keep the old
>
On 10.01.25 09:10, Peter Eisentraut wrote:
On 02.01.25 17:15, Tom Lane wrote:
It's a fair point that some documentation could be provided. I suppose
we don't want to verbosely explain each pragma individually. Should
there be some central explanation, maybe in src/tools/pginclude/README?
Tha
On 15.01.2025 12:47, Ilia Evdokimov wrote:
On 06.01.2025 18:57, Andrey M. Borodin wrote:
1. This code seems a little different from your patch. It is trying to avoid engaging PRNG. I'm not sure
it's a good idea, but still. Also, it uses "<=", not "<".
xact_is_sampled = log_xact_sample_rat
On Tue, Jan 14, 2025 at 11:08:05PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> My guess is that this has something to do with redefining SIG_ERR in
>> win32_port.h. We might be able to use push_macro/pop_macro to keep the old
>> value around, but at the moment I'm leaning towards just remo
One concern that I have about this --link mode, which Euler Taveira
also got concerned about: the fact that it can invalidate the original
backups if the user modifies or starts the synthetic backup without
moving it to another file system or machine.
At the moment, pg_combinebackup issues a warni
On Wed, Jan 15, 2025 at 07:50:38PM +0800, Jingtang Zhang wrote:
> Seems that great performance could be gained if s_lock contention is severe.
> This may be more likely to happen on bigger machines.
>
> On c8y.2xlarge (8 cores), I failed to make s_lock contended severely, and
> as a result this pa
On Wed, Oct 30, 2024 at 5:26 PM Peter Geoghegan wrote:
> I use Debian unstable for most of my day to day work. Apparently
> Debian unstable has exactly the same version of lcov as Ubuntu 24.04.
>
> I've also been unable to generate coverage reports for some time (at
> least on Debian, with LCOV ve
Am Mittwoch, dem 15.01.2025 um 14:20 +0100 schrieb Bernd Helmle:
> Commit 630f9a43cece93cb4a5c243b30e34abce6a89514 created a conflict
> with
> this patch so that it doesn't apply anymore.
Seems i broke something during rebase (see cfbot). I will look at this
tomorrow.
Bernd
I noticed that v2 of this patch series failed to apply after
7b27f5fd3, so here's v3. No non-trivial changes.
regards, tom lane
From d82b50dc222fb8751f45875fb3627bf08ca2e0cf Mon Sep 17 00:00:00 2001
From: Tom Lane
Date: Wed, 15 Jan 2025 12:37:54 -0500
Subject: [PATCH v3
On Tue, Jan 14, 2025 at 9:46 PM Ashutosh Bapat
wrote:
>
> On Tue, Jan 14, 2025 at 3:15 AM Masahiko Sawada wrote:
> >
> > On Mon, Jan 13, 2025 at 1:31 AM Ashutosh Bapat
> > wrote:
> > >
> > > On Mon, Jan 13, 2025 at 2:52 PM vignesh C wrote:
> > > >
> > > > I felt that the only disadvantage with
Hello all,
With the current implementation of pg_combinebackup, we have a few
copy methods: --clone, --copy and --copy-file-range. By using either of
them, it implicates an actual file copy in the file system, i.e. among
other things, disk usage.
While discussing with some people, e.g. Robert Haa
On Sun, Jan 12, 2025 at 10:52 PM Peter Smith wrote:
>
> On Fri, Jan 10, 2025 at 8:28 PM Masahiko Sawada wrote:
> >
> > Hi,
> >
> > On Tue, Jan 7, 2025 at 11:30 PM Peter Smith wrote:
> > >
> > > Hi Sawada-San.
> > >
> > > FWIW, I also thought it was a good idea suggested by Bertrand [1] to
> > >
Nazir Bilal Yavuz writes:
> On Tue, 14 Jan 2025 at 06:18, Michael Paquier wrote:
>> And I've somewhat managed to fat-finger the business with
>> pgstat_count_io_op() with an incorrect rebase. Will remove in a
>> minute..
> Thank you!
Commit f92c854cf has caused some of the buildfarm members to
> Probably, but first I suggest benchmarking with sampling applied to all
> queries. If the results are good, we can later filter certain queries based
> on different characteristics.
Absolutely. The benchmark numbers to justify this feature are
the next step. Thanks for your work on this!
Rega
> Appart from the above that LGTM.
thanks! I took care of your comments. I was not sure
about the need to cast "double" but as you mention this
is consistent with other parts of pgstatfuncs.c
v4 attached.
Regards,
Sami
v4-0001-Track-per-relation-cumulative-time-spent-in-vacuu.patch
Descriptio
On 14.01.2025 22:51, Melanie Plageman wrote:
On Mon, Jan 13, 2025 at 5:37 PM Alena Rybakina
wrote:
Thank you for working on this patch, without this explanation it is difficult
to understand what is happening, to put it mildly.
Thanks for the review! I've incorporated most of them into attac
On 14.01.25 15:14, Matheus Alcantara wrote:
Attached is a fixup patch where I have tried to expand the documentation
a bit in an attempt to clarify how to use this. Maybe check that what I
wrote is correct.
It looks good to me, it's much clearer now. Thanks.
v4 attached with these fixes and a
On 2025-01-15 We 11:13 AM, Robert Treat wrote:
On Mon, Jan 13, 2025 at 8:56 AM Michael Banck wrote:
Hi,
On Sat, Jan 11, 2025 at 09:01:54AM -0500, Andrew Dunstan wrote:
On 2025-01-09 Th 8:35 AM, Alvaro Herrera wrote:
Maybe we should have a new toplevel command. Some ideas that have been
thr
On Mon, Jan 13, 2025 at 8:56 AM Michael Banck wrote:
> Hi,
> On Sat, Jan 11, 2025 at 09:01:54AM -0500, Andrew Dunstan wrote:
> > On 2025-01-09 Th 8:35 AM, Alvaro Herrera wrote:
> > > Maybe we should have a new toplevel command. Some ideas that have been
> > > thrown around:
> > >
> > > - RETABLE
On 14.01.25 10:10, Alvaro Herrera wrote:
On 2024-Dec-20, Peter Eisentraut wrote:
On 20.12.24 12:47, Peter Eisentraut wrote:
In aclchk.c, there are a few error messages that use ereport() but it
seems like they should be internal error messages. Moreover, they are
using get_object_class_descr(
Hi,
On Wed, Jan 15, 2025 at 05:20:57PM +0300, Nazir Bilal Yavuz wrote:
> While doing the initdb, we are restoring stats with the
> pgstat_restore_stats() and we do not expect any pending stats. The
> problem goes like that:
>
> I was a bit surprised that Bertrand did not encounter the same proble
Hi Michael,
> My understanding was that if we have pre-allocated wal space (and
> re-cycle already used wal files), we can still write wal records into
> that pre-allocated space and still issue changes to data files as long
> as we don't need to enlarge any. So an out-of-space situation is less
>
Hi,
On Wed, Jan 15, 2025 at 09:12:17AM +, Andy Fan wrote:
> I can understand that "the file space has really been allocated", but
> why do we care about this?
>
> One reason I can think of is it has something with "out-of-disk-space"
> sistuation, even though what's the benefit of it since we
07.10.2024 17:53, Aya Iwata (Fujitsu) wrote:
Hi All,
Suggestions
==
When analyzing real-time data collected by PostgreSQL,
it can be difficult to tune the current PostgreSQL server for
satisfactory performance.
Therefore, we propose Vertical Clustered Indexing (VCI), an in-memory
On Wed, Jan 15, 2025 at 1:58 AM Richard Guo wrote:
> I understand that we're currently quite bad at estimating the number
> of groups after aggregation. In fact, it's not just aggregation
> estimates — we're also bad at join estimates in some cases. This is a
> reality we have to face. Here's w
1 - 100 of 137 matches
Mail list logo
