Hi Alvaro,
Thanks for looking at this one.
On Thu, Dec 1, 2022 at 3:12 AM Alvaro Herrera wrote:
> Looking at 0001, I wonder if we should have a crosscheck that a
> PartitionPruneInfo you got from following an index is indeed constructed
> for the relation that you think it is: previously, you
On Wed, Nov 30, 2022 at 10:51 PM houzj.f...@fujitsu.com
wrote:
>
> On Wednesday, November 30, 2022 9:41 PM houzj.f...@fujitsu.com
> wrote:
> >
> > On Tuesday, November 29, 2022 8:34 PM Amit Kapila
> > > Review comments on v53-0001*
> >
> > Attach the new version patch set.
>
> Sorry, there were
On Thu, 1 Dec 2022 15:48:21 +0900
Michael Paquier wrote:
> On Tue, Oct 18, 2022 at 05:29:58PM +0900, Yugo NAGATA wrote:
> > Thank you for your review. I agree that an isolation test is required.
> > The attached patch contains the test using the scenario as explained in
> > the previous post.
>
On 10.11.22 11:08, Juan José Santamaría Flecha wrote:
This looks pretty good to me. The refactoring of the
non-Windows parts
makes sense. The Windows parts look reasonable on manual
inspection,
but again, I don't have access to Windows here, so someone
On 13.10.22 07:23, Andres Freund wrote:
0005: meson: Add PGXS compatibility
The actual meson PGXS compatibility. Plenty more replacements to do, but
suffices to build common extensions on a few platforms.
What level of completeness do we want to require here?
I have tried this
On Mon, Nov 07, 2022 at 03:58:13PM +0900, Michael Paquier wrote:
> The patch has been switched as waiting on author for now.
Seeing no replies after three weeks, I have marked the patch as
returned with feedback for now.
--
Michael
signature.asc
Description: PGP signature
st 30. 11. 2022 v 10:43 odesílatel Fabien COELHO
napsal:
>
> >> Now some of the output generated by test_extdepend gets a bit
> >> confusing:
> >> +-- QUERY:
> >> +
> >> +
> >> +-- QUERY:
> >>
> >> That's not entirely this patch's fault. Still that's not really
> >> intuitive to see the output
On Wed, Nov 30, 2022 at 2:28 PM Masahiko Sawada
wrote:
>
> On Fri, Nov 25, 2022 at 5:00 PM John Naylor
> wrote:
> > These hacks were my work, but I think we can improve that by having two
versions of NODE_HAS_FREE_SLOT -- one for fixed- and one for variable-sized
nodes. For that to work, in
On Wed, Nov 30, 2022 at 11:09 PM Masahiko Sawada
wrote:
>
> I've investigated this issue and have a question about using atomic
> variables on palloc'ed memory. In non-parallel vacuum cases,
> radix_tree_control is allocated via aset.c. IIUC in 32-bit machines,
> the memory allocated by aset.c is
On Tue, Oct 18, 2022 at 05:29:58PM +0900, Yugo NAGATA wrote:
> Thank you for your review. I agree that an isolation test is required.
> The attached patch contains the test using the scenario as explained in
> the previous post.
Cool, thanks. Sorry for my late reply here. I have put my head on
On Wed, Nov 30, 2022 at 7:54 PM Amit Kapila wrote:
>
> On Tue, Nov 29, 2022 at 10:18 AM houzj.f...@fujitsu.com
> wrote:
> >
> > Attach the new version patch which addressed all comments.
> >
>
> Some comments on v53-0002*
>
> 1. I think testing the scenario where the
On Thu, 1 Dec 2022 at 18:27, John Naylor wrote:
> I don't see why the non-decimal literal patch needs to be "immediately"
> faster? If doing this first leads to less code churn, that's another
> consideration, but you haven't made that argument.
My view is that Peter wants to keep the code
On Thu, Dec 1, 2022 at 6:42 AM David Rowley wrote:
>
> I was thinking that we should likely apply this before doing the hex
> literals, which is the main focus of [1]. The reason being is so that
> that patch can immediately have faster conversions by allowing the
> compiler to use bit shifting
On Wed, Nov 23, 2022 at 4:58 AM David Rowley wrote:
> My current thoughts are that it might be best to go with 0005 to start
> with.
+1
> I know Melanie is working on making some changes in this area,
> so perhaps it's best to leave 0002 until that work is complete.
There seem to be some open
On Wed, Nov 30, 2022 at 5:35 PM Tom Lane wrote:
> Also, I'd like to structure things so that the first para covers what
> you need to know in a clean v15+ installation, and details that only
> apply in upgrade scenarios are in the second para. The upgrade scenario
> is going to be interesting to
On Wed, Nov 23, 2022 at 1:53 AM Steve Chavez wrote:
> So from my side this all looks good!
Thank you for your feedback.
The next revision of the patch is attached. It contains code
improvements, comments and documentation. I'm going to also write
sode tests. pg_db_role_setting doesn't seem
On Thu, 1 Dec 2022 at 15:41, David G. Johnston
wrote:
> I don't get the point of adding a function here (or at least one called
> round) - the type itself is inexact so, as you say, it is actually more of a
> type conversion with an ability to specify precision, which is exactly what
> you get
On Wed, Nov 30, 2022 at 6:45 PM Tom Lane wrote:
> David Rowley writes:
>
>
> I'm unsure what the repercussions of the fact that REAL and FLOAT8 are
> > not represented as decimals.
>
> The main thing is that I think the output will still have to be
> NUMERIC, or you're going to get complaints
Hi Mr.Pyhalov.
> One more issue I started to think about - now we don't check
> partialagg_minversion for "simple" aggregates at all. Is it correct? It seems
> that ,
> for example, we could try to pushdown bit_or(int8) to old servers, but it
> didn't
> exist, for example, in 8.4. I think it's
On Wed, Nov 30, 2022 at 05:11:44PM +, gkokola...@pm.me wrote:
> Fair enough. The atteched v11 does that. 0001 introduces compression
> specification and is using it throughout. 0002 paves the way to the
> new interface by homogenizing the use of cfp. 0003 introduces the new
> API and stores
David Rowley writes:
> We do have some weirdness in some existing overloaded functions.
> pg_size_pretty() is an example.
> If you run: SELECT pg_size_pretty(1000); you get:
> ERROR: function pg_size_pretty(integer) is not unique
Yeah, you have to be careful about that when proposing to
On Thu, 1 Dec 2022 at 07:39, Sayyid Ali Sajjad Rizavi
wrote:
>
> Whenever rounding a number to a fixed number of decimal points in a
> calculation, we need to cast the number into a numeric before using
> round((col1/100.0)::numeric, 2).
>
> It would be convenient for everyone if round() also
Andres Freund writes:
> On 2022-11-30 18:33:06 -0500, Tom Lane wrote:
>> Even if somebody comes up with a rewrite to avoid doing interesting stuff in
>> the postmaster's signal handlers, we surely wouldn't risk back-patching it.
> Would that actually fix anything, given netbsd's brokenness? If
Hi,
On 2022-11-30 18:33:06 -0500, Tom Lane wrote:
> Also, I dug into my stuck processes some more, and I have to take
> back the claim that this is happening later than postmaster startup.
> All the stuck children are ones that either are launched on request
> from the startup process, or are
On Wed, Nov 30, 2022 at 12:33:59PM -0600, Justin Pryzby wrote:
> I think you could do that with a perl 0-liner.
Right. And this could do something similar to
025_stuck_on_old_timeline.pl in terms of finding the binary for perl.
--
Michael
signature.asc
Description: PGP signature
Over on [1], Dean and I were discussing why both gcc and clang don't
seem to want to optimize the multiplication that we're doing in
pg_strtoint16, pg_strtoint32 and pg_strtoint64 into something more
efficient. It seems that this is down to the overflow checks.
Removing seems to allow the
David Rowley writes:
> I agree that it should be a separate patch. But thinking about what
> Tom mentioned in [1], I had in mind this patch would need to wait
> until the new standard is out so that we have a more genuine reason
> for breaking existing queries.
Well, we already broke them in
Andres Freund writes:
> On 2022-11-30 00:55:42 -0500, Tom Lane wrote:
>> Googling LD_BIND_NOW suggests that that's a Linux thing; do you know that
>> it should have an effect on NetBSD?
> I'm not at all sure it does, but I did see it listed in
> https://man.netbsd.org/ld.elf_so.1
>
On Thu, 1 Dec 2022 at 00:34, Dean Rasheed wrote:
> So something
> like:
>
> // Accumulate positive value using unsigned int, with approximate
> // overflow check. If acc >= 1 - INT_MIN / 10, then acc * 10 is
> // sure to exceed -INT_MIN.
> unsigned int cutoff = 1 - INT_MIN / 10;
>
On Wed, Nov 30, 2022 at 3:35 PM Tom Lane wrote:
>
> BTW, is "create a schema with the same name" sufficient detail?
> You have to either make it owned by that user, or explicitly
> grant CREATE permission on it. I'm not sure if that detail
> belongs here, but it feels like maybe it does.
>
>
On Wed, 30 Nov 2022 at 17:35, Tom Lane wrote:
BTW, is "create a schema with the same name" sufficient detail?
> You have to either make it owned by that user, or explicitly
> grant CREATE permission on it. I'm not sure if that detail
> belongs here, but it feels like maybe it does.
It might
On Wed, Nov 16, 2022 at 10:49 AM Peter Eisentraut
wrote:
>
> On 04.11.22 16:51, Melanie Plageman wrote:
> > Thanks for the review!
> > Attached is v2 with feedback addressed.
>
> Your 0001 had already been pushed.
>
> I have pushed your 0002.
>
> I have also pushed the renaming of page -> block,
Robert Haas writes:
> On Wed, Nov 30, 2022 at 10:01 AM Noah Misch wrote:
>> Could remove the paragraph about v14. Could have that paragraph say
>> explicitly that the REVOKE is a no-op. Would either of those be an
>> improvement?
> Well, I thought what I proposed was a nice improvement, but I
On Tue, 29 Nov 2022 at 21:16, Tom Lane wrote:
>
> I actually think that that problem should be soluble with a
> slightly different approach. The thing that feels insoluble
> is that you can't do this without acquiring sufficient locks
> to prevent addition of new partitions while the insertion
Yes, I agree that infrequent statements don't need stats. Actually I was
distracted with the use case that I had in mind other than stats, maybe
bringing that up will help.
If someone's interested how frequent are deletes being run on a particular
table, or what was the exact query that ran.
Whenever rounding a number to a fixed number of decimal points in a
calculation, we need to cast the number into a numeric before using
round((col1/100.0)::numeric, 2).
It would be convenient for everyone if round() also accepts float and
double precision.
Is this something I could work with?
On Wed, Nov 30, 2022 at 02:50:16PM +0900, Michael Paquier wrote:
> On Wed, Nov 23, 2022 at 09:18:57PM +0100, Daniel Verite wrote:
> > PFA a new patch addressing these issues.
>
> Thanks, the tests part of the main regression test suite look good to
> me, so I have applied them after fixing a few
Michael Paquier wrote:
> Thanks, the tests part of the main regression test suite look good to
> me, so I have applied them after fixing a few typos and tweaking the
> style of the test.
Thanks!
> Regarding the tests with pipes, I had cold feet with the
> dependencies on cat for
Sayyid Ali Sajjad Rizavi writes:
> Hi, I'd like to propose a change and get advice if I should work on it.
> The extension pg_stat_statements is very helpful, but the downside is that
> it will take up too much disk space when storing query stats if it's
> enabled for all statements like SELECT,
Looking at 0001, I wonder if we should have a crosscheck that a
PartitionPruneInfo you got from following an index is indeed constructed
for the relation that you think it is: previously, you were always sure
that the prune struct is for this node, because you followed a pointer
that was set up in
Hi, I'd like to propose a change and get advice if I should work on it.
The extension pg_stat_statements is very helpful, but the downside is that
it will take up too much disk space when storing query stats if it's
enabled for all statements like SELECT, INSERT, UPDATE, DELETE.
For example,
Alvaro Herrera writes:
> I find it a bit shocking to have had it backpatched, even to 15 -- a
> whole chapter in the documentation? I don't see why it wouldn't be
> treated like any other "major feature" patch, which we only consider for
> the development branch. Also, this is a first cut --
On 2022-Nov-30, Bruce Momjian wrote:
> On Wed, Nov 30, 2022 at 07:33:44AM +0100, Peter Eisentraut wrote:
> > On 30.11.22 02:51, Bruce Momjian wrote:
> > > Patch applied back to PG 11. Thanks to Simon for getting this important
> > > information in our docs, and for the valuable feedback from
Xing Guo writes:
> While playing with pg_regress and pg_isolation_regress, I noticed that
> there's a potential nullptr deference in both of them.
> How to reproduce:
> Specify the `--dbname=` option without providing any database name.
Hmm, yeah, I see that too.
> Patch is attached.
This
On Wed, Nov 30, 2022 at 8:13 AM Robert Haas wrote:
> I haven't checked the patches to see whether they look correct, and
> I'm concerned in particular about upgrade scenarios. But if there's a
> way we can get that part committed, I think it would be a clear win.
+1
--
Peter Geoghegan
On Tue, Nov 29, 2022 at 9:35 PM Chris Travers wrote:
> My proposal would be to make the threshold configurable and start warning on
> every transaction after that. There are a couple reasons to do that.
>
> The first is that noisy warnings are extremely easy to see. You get them in
> cron
On Wed, Nov 23, 2022 at 2:10 AM Andres Freund wrote:
>
> On 2022-11-21 17:06:56 +0900, Masahiko Sawada wrote:
> > Sure. I've attached the v10 patches. 0004 is the pure refactoring
> > patch and 0005 patch introduces the pointer tagging.
>
> This failed on cfbot, with som many crashes that the VM
On Wed, Nov 23, 2022 at 3:56 PM Andres Freund wrote:
> Indeed. This is why I was thinking that just alerting for overflowed xact
> isn't particularly helpful. You really want to see how much they overflow and
> how often.
I think if we just expose the is-overflowed feld and the count, people
can
On Wed, Nov 30, 2022 at 12:23 AM Tom Lane wrote:
> pg_dump scripts are *designed* to be tolerant of errors, mainly so
> that you can restore into a situation that's not exactly like where
> you dumped from, with the possible need to resolve errors or decide
> that they're not problems. So your
On Wed, Nov 30, 2022 at 10:01 AM Noah Misch wrote:
> On Wed, Nov 30, 2022 at 08:39:23AM -0500, Robert Haas wrote:
> > On Wed, Nov 30, 2022 at 2:07 AM Noah Misch wrote:
> > > In general, the documentation should prefer simpler decision trees.
> >
> > True, but I found the current text confusing,
On Wed, Nov 30, 2022 at 08:25:19AM -0700, David G. Johnston wrote:
> On Wed, Nov 30, 2022 at 8:02 AM Bruce Momjian wrote:
> On Wed, Nov 30, 2022 at 07:10:35AM -0700, David G. Johnston wrote:
> If everyone agrees this new chapter is helpful, and as helpful to PG 11
> users as PG 16
On Wed, Nov 30, 2022 at 8:02 AM Bruce Momjian wrote:
> On Wed, Nov 30, 2022 at 07:10:35AM -0700, David G. Johnston wrote:
> > On Wed, Nov 30, 2022 at 6:52 AM Bruce Momjian wrote:
> > I'd maybe accept having it back-patched to v15 on that basis but not any
> > further.
> >
> > But I agree that
On Wed, Nov 30, 2022 at 07:10:35AM -0700, David G. Johnston wrote:
> On Wed, Nov 30, 2022 at 6:52 AM Bruce Momjian wrote:
> I'd maybe accept having it back-patched to v15 on that basis but not any
> further.
>
> But I agree that our general behavior is to only apply this scope of update of
> the
Hi hackers,
While playing with pg_regress and pg_isolation_regress, I noticed that
there's a potential nullptr deference in both of them.
How to reproduce:
Specify the `--dbname=` option without providing any database name.
//pg_regress --dbname= foo
//pg_isolation_regress --dbname= foo
On Wed, Nov 30, 2022 at 08:39:23AM -0500, Robert Haas wrote:
> On Wed, Nov 30, 2022 at 2:07 AM Noah Misch wrote:
> > In general, the documentation should prefer simpler decision trees.
>
> True, but I found the current text confusing, which is also something
> to consider.
Could remove the
fujii.y...@df.mitsubishielectric.co.jp писал 2022-11-30 13:01:
2) Do we really have to look at pg_proc in partial_agg_ok() and
deparseAggref()? Perhaps, looking at aggtranstype is enough?
You are right. I fixed according to your comment.
partial_agg_ok() still looks at pg_proc.
--
Best
On Wed, Nov 30, 2022 at 6:52 AM Bruce Momjian wrote:
> On Wed, Nov 30, 2022 at 07:33:44AM +0100, Peter Eisentraut wrote:
> > On 30.11.22 02:51, Bruce Momjian wrote:
> > > Patch applied back to PG 11. Thanks to Simon for getting this
> important
> > > information in our docs, and for the
On Wed, Nov 30, 2022 at 12:22:57AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > FYI, you might wonder why so many bugs reported on pg_upgrade eventually
> > are bugs in pg_dump. Well, of course, partly is it because pg_upgrade
> > relies on pg_dump, but a bigger issue is that pg_upgrade
On Wed, Nov 30, 2022 at 07:33:44AM +0100, Peter Eisentraut wrote:
> On 30.11.22 02:51, Bruce Momjian wrote:
> > Patch applied back to PG 11. Thanks to Simon for getting this important
> > information in our docs, and for the valuable feedback from others that
> > made this even better.
>
> I
On Wed, Nov 30, 2022 at 2:07 AM Noah Misch wrote:
> In general, the documentation should prefer simpler decision trees.
True, but I found the current text confusing, which is also something
to consider.
--
Robert Haas
EDB: http://www.enterprisedb.com
fujii.y...@df.mitsubishielectric.co.jp писал 2022-11-30 13:01:
Hi Mr.Pyhalov.
1) In previous version of the patch aggregates, which had
partialaggfn, were ok
to push down. And it was a definite sign that aggregate can be pushed
down.
Now we allow pushing down an aggregate, which prorettype is
Hi Dag
2022年2月3日(木) 23:27 Dag Lem :
>
> Hi,
>
> Just some minor adjustments to the patch:
>
> * Removed call to locale-dependent toupper()
> * Cleaned up input normalization
This patch was marked as "Waiting on Author" in the CommitFest entry [1]
but I see you provided an updated version which
2022年10月19日(水) 6:06 Thomas Munro :
>
> On Wed, Apr 6, 2022 at 10:40 AM Victor Spirin wrote:
> > Updated patch: we use the posix semantic features in Windows build 17763
> > and up.
> > We found an issue with this feature on Windows Server 2016 without
> > updates (Windows 1607 Build 14393)
>
> Hi
On Wed, 2022-11-30 at 10:09 +0100, Vik Fearing wrote:
> On 11/29/22 17:29, Laurenz Albe wrote:
> > On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
> > > I disagree. A user does not need to know that a table is partitionned,
> > > and if the user wants a unique constraint on the table then
On Wed, Nov 30, 2022 at 4:52 PM Bharath Rupireddy
wrote:
>
> On Wed, Nov 30, 2022 at 10:48 AM Nathan Bossart
> wrote:
> >
> >
> > cfbot is not happy with v16. AFAICT this is just due to poor placement, so
> > here is another attempt with the tests moved to a new location. Apologies
> > for the
On Wed, Nov 30, 2022 at 12:44 PM Drouvot, Bertrand
wrote:
>
> +CREATE VIEW pg_stat_checkpointer AS
> +SELECT
> +pg_stat_get_timed_checkpoints() AS checkpoints_timed,
> +pg_stat_get_requested_checkpoints() AS checkpoints_req,
> +pg_stat_get_checkpoint_write_time() AS
Dear hackers,
> 1. I think testing the scenario where the shm_mq buffer is full
> between the leader and parallel apply worker would require a large
> amount of data and then also there is no guarantee. How about having a
> developer GUC [1] force_apply_serialize which allows us to serialize
>
On Wed, 30 Nov 2022 at 05:50, David Rowley wrote:
>
> I spent a bit more time trying to figure out why the compiler does
> imul instead of bit shifting and it just seems to be down to a
> combination of signed-ness plus the overflow check. See [1]. Neither
> of the two compilers I tested could
On Wed, Nov 30, 2022 at 10:48 AM Nathan Bossart
wrote:
>
>
> cfbot is not happy with v16. AFAICT this is just due to poor placement, so
> here is another attempt with the tests moved to a new location. Apologies
> for the noise.
Thanks for the patches. I spent some time on reviewing v17 patch
On Tue, Nov 29, 2022 at 10:18 AM houzj.f...@fujitsu.com
wrote:
>
> Attach the new version patch which addressed all comments.
>
Some comments on v53-0002*
1. I think testing the scenario where the shm_mq buffer is full
between the leader and parallel apply worker would
On Thu, Nov 10, 2022 at 3:38 AM Andres Freund wrote:
>
> > + }
> > +
> > + /*
> > + * Loop over offset and populate predecessor array from
> all entries
> > + * that are present in successor array.
> > + */
> > +
Hi Mr.Pyhalov.
> 1) In previous version of the patch aggregates, which had partialaggfn, were
> ok
> to push down. And it was a definite sign that aggregate can be pushed down.
> Now we allow pushing down an aggregate, which prorettype is not internal and
> aggfinalfn is not defined. Is it safe
Now some of the output generated by test_extdepend gets a bit
confusing:
+-- QUERY:
+
+
+-- QUERY:
That's not entirely this patch's fault. Still that's not really
intuitive to see the output of a query that's just a blank spot..
Hmmm.
What about adding an explicit \echo before these empty
Hmm. The refactoring is worth it as much as the differentiation
between QUERY and INTERNAL QUERY as the same pattern is repeated 5
times.
Now some of the output generated by test_extdepend gets a bit
confusing:
+-- QUERY:
+
+
+-- QUERY:
That's not entirely this patch's fault. Still that's
> This version of the patch no longer applies, a rebased version is needed.
Attached is a patch that applies cleanly again and is also changed
to use the recently introduced libpq_append_conn_error.
I also attached a patch that runs pgindent after the introduction of
libpq_append_conn_error. I
On 11/29/22 17:29, Laurenz Albe wrote:
On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
I disagree. A user does not need to know that a table is partitionned,
and if the user wants a unique constraint on the table then making them
type an extra word to get it is just annoying.
Hmm. But
On Tue, Nov 29, 2022 at 1:36 PM John Naylor
wrote:
>
> While creating a benchmark for inserting into node128-inner, I found a bug.
> If a caller deletes from a node128, the slot index is set to invalid, but the
> child pointer is still valid. Do that a few times, and every child pointer is
>
Στις Τρί 29 Νοε 2022 στις 3:27 μ.μ., ο/η Ashutosh Bapat <
ashutosh.bapat@gmail.com> έγραψε:
> That would be too restrictive - not necessarily in your application
> but generally. There could be some tables where consolidating rows
> with same PK from different publishers into a single row in
Hello
On 2022-Nov-29, Amit Langote wrote:
> Thanks for taking a look and all the fixup patches. Was working on
> that test I said we should add and then was spending some time
> cleaning things up and breaking some things out into their patches,
> mainly for the ease of review.
Right,
Hi, Yuki.
1) In previous version of the patch aggregates, which had partialaggfn,
were ok to push down. And it was a definite sign that aggregate can be
pushed down. Now we allow pushing down an aggregate, which prorettype is
not internal and aggfinalfn is not defined. Is it safe for all
> On 30 Nov 2022, at 08:04, Peter Eisentraut
> wrote:
>
> For historical reasons, pg_dump refers to large objects as "BLOBs". This term
> is not used anywhere else in PostgreSQL, and it also means something
> different in the SQL standard and other SQL systems.
>
> This patch renames
81 matches
Mail list logo
