Hi,
On 6/29/23 12:36 PM, Amit Kapila wrote:
On Wed, Jun 28, 2023 at 12:19 PM Drouvot, Bertrand
wrote:
Yeah, I think once the slot is dropped we just have to wait for the slot to
be re-created on the standby according to the new synchronize_slot_names GUC.
Assuming the initial slot "creation"
On Fri, Jun 30, 2023 at 12:05:17PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 29 Jun 2023 13:56:38 -0700, Nathan Bossart
> wrote in
>> Sorry, I'm not following. I intentionally avoided allowing combinations of
>> --schema and --table in the patches I sent. This is the current behavior
>> of
On Thu, Jun 29, 2023 at 08:53:56PM -0400, Tom Lane wrote:
> I'm leaning to Robert's thought that we need to revert this for now,
> and think harder about how to make it work cleanly and safely.
Since it sounds like this is headed towards a revert, here's a patch for
removing MAINTAIN and
On Thu, Jun 29, 2023 at 4:43 PM Joel Jacobson wrote:
>
> On Thu, Jun 29, 2023, at 08:54, jian he wrote:
> > Anyway, this time, I added another macro,which seems to simplify the code.
> >
> > #define SET_DATA_PTR(a) \
> > (((char *) (a->data)) + CEIL_DIV(a->capacity, 8))
> >
> > it passed all the
On Thu, Jun 29, 2023 at 9:40 PM vignesh C wrote:
>
> On Thu, 29 Jun 2023 at 09:58, Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Thursday, June 29, 2023 12:06 PM vignesh C wrote:
> > >
> >
> > Thanks for the patches.
> >
> > I tried to understand the following check:
> >
> > /*
> >
On Wed, Jun 28, 2023 at 7:26 PM Ashutosh Bapat
wrote:
>
> Hi Vignesh,
> Thanks for working on this.
>
> On Wed, Jun 28, 2023 at 4:52 PM vignesh C wrote:
> >
> > Here is a patch having the fix for the same. I have not added any
> > tests as the existing tests cover this scenario. The same issue
Hi,
On 2023-06-30 14:13:11 +1200, Thomas Munro wrote:
> On Fri, Jun 30, 2023 at 3:39 AM Andres Freund wrote:
> > I am wondering if we don't want something more generic than stashing this in
> > rd_amcache. Don't want to end up duplicating relevant code across the uses
> > of
> > rd_amcache in
On Fri, Jun 30, 2023 at 12:20 AM Tom Lane wrote:
> Richard Guo writes:
> > On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
> >> Those cases will go through calc_non_nestloop_required_outer
> >> which has
> >> /* neither path can require rels from the other */
> >>
At Thu, 29 Jun 2023 13:56:38 -0700, Nathan Bossart
wrote in
> Thanks for taking a look.
>
> On Thu, Jun 29, 2023 at 02:16:26PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart
> > wrote in
> >> I debated also allowing users to specify different types of
On Fri, Jun 30, 2023 at 12:16 AM Tom Lane wrote:
> Pushed with that and defenses added to try_mergejoin_path and
> try_hashjoin_path. It looks like the various try_partial_xxx_path
> functions already reject cases that could be problematic. (They
> will not accept inner parameterization that
On Wed, Jun 28, 2023 at 7:26 AM Zhijie Hou (Fujitsu)
wrote:
>
> On Monday, June 26, 2023 12:18 PM Amit Kapila wrote:
> >
> > Fair enough. If we could have been convinced of this then we can keep the
> > required change only for HEAD. But anyway let's remove the work related to
> > both commits
On Fri, Jun 30, 2023 at 3:39 AM Andres Freund wrote:
> I am wondering if we don't want something more generic than stashing this in
> rd_amcache. Don't want to end up duplicating relevant code across the uses of
> rd_amcache in every AM.
I suppose we could try to track hot pages automatically.
Hello,
Thank you for your reply and for creating a new patch.
On Wed, Jun 28, 2023 at 7:58 PM David Rowley wrote:
> Linux with AMD 3990x, again using the patch from [1] with make installcheck
>
> master: 1.41720145 seconds
> v4: 1.392969606 seconds (1.74% faster than master)
> v4 with 0th word
On Tue, May 09, 2023 at 12:26:16PM +0900, Michael Paquier wrote:
> That looks pretty much OK to me. One tiny comment I have is that this
> lacks brackets for the inner blocks, so I have added some in the v4
> attached.
The indentation was a bit wrong, so fixed it, and applied on HEAD.
--
Michael
Jeff Davis writes:
> On Thu, 2023-06-29 at 11:19 -0400, Robert Haas wrote:
>> We shouldn't ship a new feature with a built-in
>> security hole like that.
> Let's take David's suggestion[1] then, and only restrict the search
> path for those without owner privileges on the object.
I think that's
On Thu, 2023-06-29 at 11:19 -0400, Robert Haas wrote:
> Yeah. I mean, as things stand, it seems like giving someone the
> MAINTAIN privilege will be sufficient to allow them to escalate to
> the
> table owner if there are any expression indexes involved. That seems
> like a real problem. We
Hi,
On 2023-06-29 11:58:27 +0200, Tomas Vondra wrote:
> On 6/29/23 01:34, Andres Freund wrote:
> > On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
> >> Yeah. FWIW I was interested what the patch does in practice, so I
> >> checked what pahole says about impact on struct sizes:
> >>
> >>
On Wed, Jun 14, 2023 at 10:30:23AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Thanks for the review!
v17 is now open, so applied this one.
--
Michael
signature.asc
Description: PGP signature
Hi there.
in v28-0005-Add-Incremental-View-Maintenance-support-to-psql.patch
I don't know how to set psql to get the output
"Incremental view maintenance: yes"
On Wed, Jun 28, 2023 at 10:24:09PM -0700, Nathan Bossart wrote:
> On Wed, Jun 28, 2023 at 09:20:03PM -0700, Gurjeet Singh wrote:
>> Nitpicking: The patch seems to have Windows line endings, which
>> explains why my `patch` complained so loudly.
>>
>> $ patch -p1 < v1-0001-harmonize-patch
>>
Thanks for taking a look.
On Thu, Jun 29, 2023 at 02:16:26PM +0900, Kyotaro Horiguchi wrote:
> At Wed, 28 Jun 2023 16:24:02 -0700, Nathan Bossart
> wrote in
>> I debated also allowing users to specify different types of objects in the
>> same command (e.g., "vacuumdb --schema myschema --table
On Thu, Jun 29, 2023 at 11:19:38AM -0400, Robert Haas wrote:
> [ emerges from hibernation ]
Welcome back.
> If we're not going to fix the feature so that it doesn't break the
> security model, we should probably just revert it. I don't understand
> at all the idea of shipping something that we
On 6/29/23 10:12 AM, Jonathan S. Katz wrote:
Hi,
plan_create_index_workers[1] does not consider the amount of tuples
existing in TOAST pages when determining the number of parallel workers
to use for a build. The estimation comes from estimate_rel_size[2],
which in this case, will just take
On Thu Jun 29, 2023 at 2:13 PM CDT, Andres Freund wrote:
> Hi,
>
> On 2023-06-29 14:07:19 -0500, Tristan Partin wrote:
> > I still think the overrides are important, at the very least for libpq,
> > but I will defer to your aforementioned decision for now.
>
> libpq makes sense to me, fwiw. Just
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Hello,
I've reviewed your latest v3 patches on Ubuntu 23.04. Both
Hi,
On 2023-06-29 14:07:19 -0500, Tristan Partin wrote:
> I still think the overrides are important, at the very least for libpq,
> but I will defer to your aforementioned decision for now.
libpq makes sense to me, fwiw. Just doing it for all binaries individually
didn't seem as obviously
On 2023-06-29 Th 11:19, Robert Haas wrote:
Now we're proposing to ship a brand-new feature with a hole that we
definitely already know exists. I can't understand that at all. Should
we just go file the CVE against ourselves right now, then? Seriously,
what are we doing?
If we're not going to
On Thu Jun 29, 2023 at 2:02 PM CDT, Andres Freund wrote:
> Hi,
>
> On 2023-06-13 14:56:36 -0500, Tristan Partin wrote:
> > I was thinking today. When you initially wrote the build, did you try
> > using the src/bin/meson.build file as the place where all the binaries
> > were built? As you say,
On Thu Jun 29, 2023 at 1:58 PM CDT, Andres Freund wrote:
> Hi,
>
> On 2023-06-29 13:34:42 -0500, Tristan Partin wrote:
> > On Thu Jun 29, 2023 at 12:35 PM CDT, Andres Freund wrote:
> > > > v5-0012-Make-finding-pkg-config-python3-more-robust.patch
> > >
> > > The commit message here is clearly
Hi,
On 2023-06-13 14:56:36 -0500, Tristan Partin wrote:
> I was thinking today. When you initially wrote the build, did you try
> using the src/bin/meson.build file as the place where all the binaries
> were built? As you say, most of the src/bin/xxx/meson.build files are
> extrememly reptitive.
Hi,
On 2023-06-29 13:34:42 -0500, Tristan Partin wrote:
> On Thu Jun 29, 2023 at 12:35 PM CDT, Andres Freund wrote:
> > > v5-0012-Make-finding-pkg-config-python3-more-robust.patch
> >
> > The commit message here is clearly outdated (still talking about Python.h
> > check not being required).
On Thu, Jun 29, 2023 at 1:50 PM Nikolay Samokhvalov wrote:
> Does this make sense or I'm missing something and the current docs describe a
> reliable process? (As I said, we have deviated from the process, to involve
> logical replication, so I'm not 100% sure I'm right suspecting the original
On Thu Jun 29, 2023 at 12:35 PM CDT, Andres Freund wrote:
> Hi,
>
> On 2023-06-29 13:18:21 +0200, Peter Eisentraut wrote:
> > On 13.06.23 22:47, Tristan Partin wrote:
> > > Forgot that I had gotten a review from a Meson maintainer. The last two
> > > patches in this set are new. One is just a
Hi!
(posting this to -hackers rather than to -docs since it seems a deeper
problem than just adjusting the docs)
I recently observed a case with standby corruption after upgrading pg12 to
pg14, which was presented in the form of XX001 errors on the new cluster's
standby nodes. e.g.:
ERROR:
Hi,
On 2023-06-29 13:18:21 +0200, Peter Eisentraut wrote:
> On 13.06.23 22:47, Tristan Partin wrote:
> > Forgot that I had gotten a review from a Meson maintainer. The last two
> > patches in this set are new. One is just a simple spelling correction.
>
> I have committed patches 0001-0006, 0008,
On 5/19/23 15:01, Jacob Champion wrote:
> But I don't want to
> gold-plate it if this overall approach is unacceptable. So, questions
> for the gallery:
>
> 1) Would starting up a background thread (pooled or not) be acceptable
> on Windows? Alternatively, does anyone know enough Winsock deep
On 3/20/23 10:43, Tom Lane wrote:
> I'd be more willing to consider the proposed patch if it weren't such
> a hack --- as you say, it doesn't fix the problem when the table has
> policies, so it's hardly a general-purpose solution. I fear that it's
> also fairly expensive: adding sub-selects to
Richard Guo writes:
> On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
>> Those cases will go through calc_non_nestloop_required_outer
>> which has
>> /* neither path can require rels from the other */
>> Assert(!bms_overlap(outer_paramrels, inner_path->parent->relids));
>>
Richard Guo writes:
> BTW, it seems that extra->sjinfo would always have a valid value here.
> So maybe we do not need to check if it is not NULL explicitly?
Right, I was being conservative but this module expects that to
always be provided.
Pushed with that and defenses added to
On Thu, 29 Jun 2023 at 09:58, Zhijie Hou (Fujitsu)
wrote:
>
> On Thursday, June 29, 2023 12:06 PM vignesh C wrote:
> >
> > On Wed, 28 Jun 2023 at 19:26, Ashutosh Bapat
> > wrote:
> > >
> > > Hi Vignesh,
> > > Thanks for working on this.
> > >
> > > On Wed, Jun 28, 2023 at 4:52 PM vignesh C
On Wed, Jun 28, 2023 at 5:41 PM Michael Paquier wrote:
> Agreed. I am not sure that this is worth changing to have
> boolean-like checks. Hence, I would also to keep the patch that
> checks if the environment variable is defined to enforce the behavior,
> without checking for a specific value.
Hi,
On 2023-06-29 19:35:30 +1200, Thomas Munro wrote:
> I (re)discovered why I used the lock-then-pin approach. In the
> comments I mentioned InvalidBuffer(), but the main problem is in its
> caller GetVictimBuffer() which has various sanity checks about
> reference counts that can occasionally
[ emerges from hibernation ]
On Mon, Jun 19, 2023 at 6:58 PM Jeff Davis wrote:
> On Mon, 2023-06-19 at 16:03 -0400, Robert Haas wrote:
> > I'm inclined to think that this is a real security issue and am not
>
> Can you expand on that a bit? You mean a practical security issue for
> the intended
On 29.06.2023 14:23, Ranier Vilela wrote:
Em qui., 29 de jun. de 2023 às 06:56, Alena Rybakina
escreveu:
I apologize for breaks the original thread. In my defense, I can
say that I'm new to all this and I'm just learning. I will try to
make as few mistakes as possible.
By no
Hi!
At the moment, I'm not sure that the constant is the right number
for applying transformations, so I'm in search of it, to be
honest. I will post my observations on this issue later. If you
don't mind, I'll leave the constant equal to 15 for now.
It's hard to predict.
Hi,
plan_create_index_workers[1] does not consider the amount of tuples
existing in TOAST pages when determining the number of parallel workers
to use for a build. The estimation comes from estimate_rel_size[2],
which in this case, will just take the value from rel->rd_rel->relpages.
We
ALTER TABLE DETACH CONCURRENTLY had to deal with this also, and it did it by
having a COMPLETE option you can run later in case things got stuck the first
time around. I suppose we could do something similar, where the server
automatically does the needful, whatever that is.
On Thu Jun 29, 2023 at 6:18 AM CDT, Peter Eisentraut wrote:
> On 13.06.23 22:47, Tristan Partin wrote:
> > Forgot that I had gotten a review from a Meson maintainer. The last two
> > patches in this set are new. One is just a simple spelling correction.
>
> I have committed patches 0001-0006,
Em qui., 29 de jun. de 2023 às 02:50, Alena Rybakina <
lena.riback...@yandex.ru> escreveu:
> Hi!
> On 29.06.2023 04:36, Ranier Vilela wrote:
>
> I don't want to be rude, but this doesn't seem very helpful.
>>
> Sorry, It was not my intention to cause interruptions.
>
>
>> - You made some changes,
On Thu, Jun 29, 2023 at 6:51 PM jian he wrote:
>
> I cannot build the doc.
> git clean -fdx
> git am ~/Desktop/tmp/*.patch
>
> Applying: Add a syntax to create Incrementally Maintainable Materialized Views
> Applying: Add relisivm column to pg_class system catalog
> Applying: Allow to prolong
On Fri, 2023-06-16 at 00:34 +0200, Tomas Vondra wrote:
> On 6/15/23 22:36, Tom Lane wrote:
> > Tomas Vondra writes:
> > > On 6/15/23 22:11, Tom Lane wrote:
> > > > I see zero leakage in that example after applying the attached quick
> > > > hack. (It might be better to make the check in the
Em qui., 29 de jun. de 2023 às 06:56, Alena Rybakina <
lena.riback...@yandex.ru> escreveu:
> I apologize for breaks the original thread. In my defense, I can say that
> I'm new to all this and I'm just learning. I will try to make as few
> mistakes as possible.
>
By no means, your work is
On 13.06.23 22:47, Tristan Partin wrote:
Forgot that I had gotten a review from a Meson maintainer. The last two
patches in this set are new. One is just a simple spelling correction.
I have committed patches 0001-0006, 0008, 0010, 0013, 0014, 0016, which
are all pretty much cosmetic.
The
Andreas Karlsson writes:
> On 6/29/23 11:13, Thom Brown wrote:
>> I get the feeling that this is deliberate, and perhaps an attempt to
>> mitigate locking issues, or some other explanation, but the rationale
>> isn't immediately apparent to me if this is the case.
> I have always assumed the
On 6/29/23 11:13, Thom Brown wrote:
I get the feeling that this is deliberate, and perhaps an attempt to
mitigate locking issues, or some other explanation, but the rationale
isn't immediately apparent to me if this is the case.
I have always assumed the reason is that there might be other
On 2023-Jun-28, Peter Eisentraut wrote:
> The MergeAttributes() and related code in and around tablecmds.c is huge and
> ancient, with many things bolted on over time, and difficult to deal with.
> I took some time to make careful incremental updates and refactorings to
> make the code easier to
I cannot build the doc.
git clean -fdx
git am ~/Desktop/tmp/*.patch
Applying: Add a syntax to create Incrementally Maintainable Materialized Views
Applying: Add relisivm column to pg_class system catalog
Applying: Allow to prolong life span of transition tables until transaction end
Applying:
On Thu, Jun 29, 2023 at 3:52 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Drouvot,
>
> Hi, I'm also interested in the feature. Followings are my high-level comments.
> I did not mention some detailed notations because this patch is not at the
> stage.
> And very sorry that I could not follow all
On Wed, Jun 28, 2023 at 12:19 PM Drouvot, Bertrand
wrote:
>
> On 6/26/23 12:34 PM, Amit Kapila wrote:
> > On Mon, Jun 26, 2023 at 11:15 AM Drouvot, Bertrand
> > wrote:
> >>
> >> On 6/20/23 12:22 PM, Amit Kapila wrote:
> >>> On Mon, Jun 19, 2023 at 9:56 PM Drouvot, Bertrand
> >>> wrote:
> >>
>
Dear Drouvot,
Hi, I'm also interested in the feature. Followings are my high-level comments.
I did not mention some detailed notations because this patch is not at the
stage.
And very sorry that I could not follow all of this discussions.
1. I thought that we should not reuse logical
On Thu, Jun 29, 2023 at 12:40 AM jian he wrote:
>
> On Wed, Jun 28, 2023 at 4:06 PM Yugo NAGATA wrote:
> >
> > On Wed, 28 Jun 2023 00:01:02 +0800
> > jian he wrote:
> >
> > > On Thu, Jun 1, 2023 at 2:47 AM Yugo NAGATA wrote:
> > > >
> > > > On Thu, 1 Jun 2023 23:59:09 +0900
> > > > Yugo NAGATA
On 6/29/23 01:34, Andres Freund wrote:
> Hi,
>
> On 2023-06-28 23:26:00 +0200, Tomas Vondra wrote:
>> Yeah. FWIW I was interested what the patch does in practice, so I
>> checked what pahole says about impact on struct sizes:
>>
>> AllocSetContext 224B -> 208B (4 cachelines)
>>
I apologize for breaks the original thread. In my defense, I can say
that I'm new to all this and I'm just learning. I will try to make as
few mistakes as possible.
I try to fix it by forwarding this message to you, besides it might be
interesting to you too. This message to you, because it
On 2023-06-29 10:25, Kyotaro Horiguchi wrote:
Thanks for the comment!
At Wed, 28 Jun 2023 22:28:13 +0900, torikoshia
wrote in
On 2022-09-29 17:18, Polina Bungina wrote:
> I agree with your suggestions, so here is the updated version of
> patch. Hope I haven't missed anything.
> Regards,
>
Hi! I'm sorry I didn't answer you right away, I was too busy with work.
On 27.06.2023 22:50, Peter Geoghegan wrote:
On Tue, Jun 27, 2023 at 6:19 AM Alena Rybakina wrote:
I learned something new from your letter, thank you very much for that!
Cool. The MDAM paper is also worth a read:
Hi,
It's documented that a failed REINDEX can leave behind a transient
index, and I'm not going to speculate on all the conditions that could
lead to this situation. However, cancelling a REINDEX CONCURRENTLY
will reliably leave behind the index it was building (_ccnew).
Doesn't a cancellation
Dear Jian,
Thank you for checking my patch!
>
> in your patch:
> > printable ASCII characters will be replaced with a hex escape.
>
> My wording is not good. I think the result will be: ASCII characters
> will be as is, non-ASCII characters will be replaced with "a hex
> escape".
Yeah,
On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
> Those cases will go through calc_non_nestloop_required_outer
> which has
>
> /* neither path can require rels from the other */
> Assert(!bms_overlap(outer_paramrels, inner_path->parent->relids));
>
I (re)discovered why I used the lock-then-pin approach. In the
comments I mentioned InvalidBuffer(), but the main problem is in its
caller GetVictimBuffer() which has various sanity checks about
reference counts that can occasionally fail if you have code randomly
pinning any old buffer.
New
On 29/06/2023 02:36, Michael Paquier wrote:
Hi all,
While working on a different patch, I have noted three code paths that
call changeDependencyFor() but don't check that they do not return
errors. In all the three cases (support function, extension/schema
and object/schema), it seems to me
On Wed, Jun 28, 2023 at 4:50 PM Joel Jacobson wrote:
>
> On Wed, Jun 28, 2023, at 08:26, jian he wrote:
>
> > Hi there.
> > I changed the function hashset_contains to strict.
>
> Changing hashset_contains to STRICT would cause it to return NULL
> if any of the operands are NULL, which I don't
On Thu, Jun 29, 2023 at 10:39 AM Richard Guo wrote:
> On Wed, Jun 28, 2023 at 10:09 PM Tom Lane wrote:
>
>> However, given that what we need is to exclude parameterization
>> that depends on the currently-formed OJ, it seems to me we can do
>> it more simply and without any new
Sorry for the possible duplicate. I have a suspicion that the previous
email was not sent.
Hi!
On 29.06.2023 04:36, Ranier Vilela wrote:
Em qua., 28 de jun. de 2023 às 18:45, Tomas Vondra
escreveu:
On 6/27/23 20:55, Ranier Vilela wrote:
> Hi,
>
>>I finished writing the code
73 matches
Mail list logo
