On Wed, Jan 18, 2023 at 10:35:29AM +0100, Jelte Fennema wrote:
> Anything I can do to help with this? Or will you do that yourself?
So, I have done a second lookup, and tweaked a few things:
- Addition of a macro for pg_strcasecmp(), to match with
token_matches().
- Fixed a bit the documentation.
Justin Pryzby писал 2023-01-19 04:49:
On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
Hi,
Currently there is no error in this case, so additional thrown error
would
require a new test.
Besides, throwing an error here does not make sense - it is just a
check
for a vacuum
Hi!
I've found the discussion you'd mentioned before, checking now.
On Thu, Jan 19, 2023 at 4:49 AM Justin Pryzby wrote:
> On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
> > Hi,
> >
> > Currently there is no error in this case, so additional thrown error
> would
> > require a
On Wednesday, January 18, 2023 4:06 PM Peter Smith
wrote:
> Here are my review comments for the latest patch v16-0001. (excluding the
> test code)
Hi, thank you for your review !
> ==
>
> General
>
> 1.
>
> Since the value of min_apply_delay cannot be < 0, I was thinking probably it
>
On Thu, Jan 19, 2023 at 8:39 AM Zheng Li wrote:
>
> On Wed, Jan 18, 2023 at 6:27 AM Amit Kapila wrote:
> >
> > On Sat, Jan 7, 2023 at 8:58 PM Zheng Li wrote:
> > >
>
> Foreign Tables can also be considered replicated with DDL replication because
> we
> don't even need to replicate the data as
On 1/19/23 11:01, Tom Lane wrote:
Andrey Lepikhov writes:
On 1/9/23 23:52, Tom Lane wrote:
BTW, if this does bring the probability of failure down to the
one-in-a-billion range, I think we could also nuke the whole
"ignore:" business, simplifying pg_regress and allowing the
random test to be
On Thursday, January 19, 2023 10:49 AM Peter Smith
wrote:
> On Wed, Jan 18, 2023 at 6:06 PM Peter Smith
> wrote:
> >
> > Here are my review comments for the latest patch v16-0001. (excluding
> > the test code)
> >
>
> And here are some review comments for the v16-0001 test code.
Hi, thanks
On Wed, Jan 18, 2023 at 02:04:16PM +0530, Bharath Rupireddy wrote:
> [1]
> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
> index 89d53f2a64..6f9509267c 100644
> --- a/doc/src/sgml/config.sgml
> +++ b/doc/src/sgml/config.sgml
> @@ -4326,7 +4326,8 @@ restore_command = 'copy
>
Andrey Lepikhov writes:
> On 1/9/23 23:52, Tom Lane wrote:
>> BTW, if this does bring the probability of failure down to the
>> one-in-a-billion range, I think we could also nuke the whole
>> "ignore:" business, simplifying pg_regress and allowing the
>> random test to be run in parallel with
pg_stat_progress_copy was added in v14 (8a4f618e7, 9d2d45700).
But if a command JOINs file_fdw tables, the progress report gets bungled
up. This will warn/assert during file_fdw tests.
diff --git a/src/backend/utils/activity/backend_progress.c
b/src/backend/utils/activity/backend_progress.c
On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
>
> So I took a look into what it would take to do and I think it would
> actually be quite feasible. The first byte of a standard TLS
> connection can't look anything like the first byte of any flavour of
> Postgres startup packet because it
On Wed, Jan 18, 2023 at 12:09 PM Amit Kapila wrote:
>
> On Fri, Jan 13, 2023 at 11:50 AM Peter Smith wrote:
> >
> > Here are some review comments for patch v79-0002.
> >
>
> So, this is about the latest v84-0001-Stop-extra-worker-if-GUC-was-changed.
>
> >
> > I feel this patch just adds more
On 1/9/23 23:52, Tom Lane wrote:
BTW, if this does bring the probability of failure down to the
one-in-a-billion range, I think we could also nuke the whole
"ignore:" business, simplifying pg_regress and allowing the
random test to be run in parallel with others.
With 'ignore' option we get used
On 19/01/23 08:58, David Rowley wrote:
The problem is that the next item looked at is 1 and the value 2 is skipped.
Okay, I see the issue.
I think you are misinterpreting the results, but the main point
remains - it's slower. The explain analyze timing shows the time
between outputting
On Tue, Jan 17, 2023 at 07:55:53PM +0530, Bharath Rupireddy wrote:
> On Tue, Jan 17, 2023 at 12:31 PM Michael Paquier wrote:
>> Oops. It looks like you are right here. This would impact the
>> calculation of CheckPointSegments on reload when
>> checkpoint_completion_target is updated. This is
On Tue, 17 Jan 2023 16:43:13 -0600
"Karl O. Pinc" wrote:
> It might be useful to add --nonet to the xsltproc invocation(s)
> in the Makefile(s). Just in case; to keep from retrieving
> stylesheets from the net. (If the option is not already there.
> I didn't look.)
>
> If this is the first
st 18. 1. 2023 v 16:27 odesílatel Isaac Morland
napsal:
> On Wed, 18 Jan 2023 at 00:00, Pavel Stehule
> wrote:
>
>>
>> út 17. 1. 2023 v 20:29 odesílatel Isaac Morland
>> napsal:
>>
>>>
>>> I welcome comments and feedback. Now to try to find something manageable
>>> to review.
>>>
>>
>> looks
On Thu, 19 Jan 2023 at 06:27, Ankit Kumar Pandey wrote:
> Hmm, not really sure why did I miss that. I tried this again (added
> following in postgres.c above
>
> PortalStart)
>
> List* l = NIL;
> l = lappend(l, 1);
> l = lappend(l, 2);
> l = lappend(l, 3);
> l = lappend(l, 4);
>
> ListCell *lc;
>
On Wed, Jan 18, 2023 at 7:04 PM Andres Freund wrote:
> > You seem to be saying that it's a problem if we don't update reltuples
> > -- an estimate -- when less than 2% of the table is scanned by VACUUM.
> > But why? Why can't we just do nothing sometimes? I mean in general,
> > leaving aside the
I had a conversation a while back with Heikki where he expressed that
it was annoying that we negotiate SSL/TLS the way we do since it
introduces an extra round trip. Aside from the performance
optimization I think accepting standard TLS connections would open the
door to a number of other
On Wed, Jan 18, 2023 at 6:27 AM Amit Kapila wrote:
>
> On Sat, Jan 7, 2023 at 8:58 PM Zheng Li wrote:
> >
> > I added documentation and changed user interface design in the
> > attached v60 patch set.
> > The patch set addressed comments from Peter in [1].
> >
> > The motivation for the user
On Wed, Jan 18, 2023 at 6:26 PM Bharath Rupireddy
wrote:
>
> Hi,
>
> logicalrep_read_tuple() duplicates code for LOGICALREP_COLUMN_TEXT and
> LOGICALREP_COLUMN_BINARY introduced by commit 9de77b5. While it
> doesn't hurt anyone, deduplication makes code a bit leaner by 57 bytes
> [1]. I've
Hi,
On 2023-01-18 18:21:33 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 5:49 PM Andres Freund wrote:
> > On 2023-01-18 15:28:19 -0800, Peter Geoghegan wrote:
> > > Perhaps we should make vac_estimate_reltuples focus on the pages that
> > > VACUUM newly set all-visible each time (not
On Wed, Jan 18, 2023 at 6:10 PM Andres Freund wrote:
> > This creates an awkward but logical question, though: what if
> > dead_tuples doesn't go down at all? What if VACUUM actually has to
> > increase it, because VACUUM runs so slowly relative to the workload?
>
> Sure, that can happen - but
Hi,
On 2023-01-18 11:24:19 +0100, Drouvot, Bertrand wrote:
> On 1/6/23 4:40 AM, Andres Freund wrote:
> > Hm, that's quite expensive. Perhaps worth adding a C helper that can do that
> > for us instead? This will likely also be needed in real applications after
> > all.
> >
>
> Not sure I got
On Wed, Jan 18, 2023 at 2:09 PM Tomas Vondra
wrote:
>
> Hi,
>
> This patch hasn't been updated since September, and it got broken by
> 4a29eabd1d91c5484426bc5836e0a7143b064f5a which the incremental sort
> stuff a little bit. But the breakage was rather limited, so I took a
> stab at fixing it -
On Wed, Jan 18, 2023 at 5:49 PM Andres Freund wrote:
> On 2023-01-18 15:28:19 -0800, Peter Geoghegan wrote:
> > Perhaps we should make vac_estimate_reltuples focus on the pages that
> > VACUUM newly set all-visible each time (not including all-visible
> > pages that got scanned despite being
Hi,
On 2023-01-18 17:00:48 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 4:37 PM Andres Freund wrote:
> > I can, it should be just about trivial code-wise. A bit queasy about trying
> > to
> > forsee the potential consequences.
>
> That's always going to be true, though.
>
> > A
On Fri, Jan 13, 2023 at 9:55 PM Andres Freund wrote:
> How about a float autovacuum_no_auto_cancel_age where positive values are
> treated as absolute values, and negative values are a multiple of
> autovacuum_freeze_max_age? And where the "computed" age is capped at
> vacuum_failsafe_age? A
On Wed, Jan 18, 2023 at 6:06 PM Peter Smith wrote:
>
> Here are my review comments for the latest patch v16-0001. (excluding
> the test code)
>
And here are some review comments for the v16-0001 test code.
==
src/test/regress/sql/subscription.sql
1. General
For all comments
"time
On Mon, Jan 16, 2023 at 08:12:18PM +0300, Nikita Malakhov wrote:
> Hi,
>
> Currently there is no error in this case, so additional thrown error would
> require a new test.
> Besides, throwing an error here does not make sense - it is just a check
> for a vacuum
> permission, I think the right way
Hi,
On 2023-01-18 16:19:02 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 4:02 PM Andres Freund wrote:
> > vacuum-no reltuples/n_live_tupn_dead_tup
> > 1 476 500
> > 2 2500077 500
> > 3
On Wed, Jan 18, 2023 at 6:06 PM Peter Smith wrote:
>
> Here are my review comments for the latest patch v16-0001. (excluding
> the test code)
>
...
>
> 8. AlterSubscription (general)
>
> I observed during testing there are 3 different errors….
>
> At subscription CREATE time you can get this
On Wed, Jan 18, 2023 at 10:35:29AM +0100, Jelte Fennema wrote:
> Anything I can do to help with this? Or will you do that yourself?
Nope. I just need some time to finish wrapping it, that's all.
--
Michael
signature.asc
Description: PGP signature
On Wed, Jan 18, 2023 at 4:37 PM Andres Freund wrote:
> I can, it should be just about trivial code-wise. A bit queasy about trying to
> forsee the potential consequences.
That's always going to be true, though.
> A somewhat related issue is that pgstat_report_vacuum() sets dead_tuples to
> what
On Tue, Jan 17, 2023 at 07:44:52PM +0530, Bharath Rupireddy wrote:
> On Thu, Jan 12, 2023 at 6:21 AM Nathan Bossart
> wrote:
>> With your patch, we might replay one of these "old" files in pg_wal instead
>> of the complete version of the file from the archives,
>
> That's true even today,
Hi,
On 2023-01-18 13:45:19 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 1:08 PM Andres Freund wrote:
> > I suggested nearby to only have ANALYZE dead_tuples it if there's been no
> > [auto]vacuum since the stats entry was created. That allows recovering from
> > stats resets, be it
On Wed, Jan 18, 2023 at 08:43:01AM -0500, Andrew Dunstan wrote:
> Looks fine.
Thanks for double-checking, will apply shortly.
> Interesting it's not caught by perlcritic on my Fedora 35
> instance, nor my Ubuntu 22.04 instance.
Perhaps that just shows up on the latest version of perlcritic? I
Just my luck, I had to dig into a two-"character" emoji that came to me
as part of a Google Calendar entry --- here it is:
⚕️喙
libc
Unicode UTF8 len
U+1F469 f0 9f 91 a9 2 woman
U+1F3FC f0 9f 8f bc 2 emoji
On Wed, Jan 18, 2023 at 4:02 PM Andres Freund wrote:
> vacuum-no reltuples/n_live_tupn_dead_tup
> 1 476 500
> 2 2500077 500
> 3 1250184 500
> 4625266
Hi,
On 2023-01-18 14:37:20 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 2:22 PM Andres Freund wrote:
> > The problem with the change is here:
> >
> > /*
> > * Okay, we've covered the corner cases. The normal calculation is
> > to
> > * convert the old
On Wed, Jan 18, 2023 at 3:28 PM Peter Geoghegan wrote:
> The problems in this area tend to be that vac_estimate_reltuples()
> behaves as if it sees a random sample, when in fact it's far from
> random -- it's the same scanned_pages as last time, and the ten other
> times before that. That's a
On Thu, Jan 19, 2023 at 2:55 AM David G. Johnston
wrote:
>
> On Wed, Jan 18, 2023 at 8:38 AM Tom Lane wrote:
>>
>> "David G. Johnston" writes:
>> > ... I was going for the html effect
>> > of having these views chunked into their own pages, any other changes being
>> > non-detrimental.
>>
>>
On Wed, Jan 18, 2023 at 2:37 PM Peter Geoghegan wrote:
> Maybe you're right to be concerned to the degree that you're concerned
> -- I'm not sure. I'm just adding what I see as important context.
The problems in this area tend to be that vac_estimate_reltuples()
behaves as if it sees a random
On Wed, Jan 18, 2023 at 12:15:33PM -0500, Robert Haas wrote:
> On Mon, Jan 16, 2023 at 2:29 PM Robert Haas wrote:
>> 1. It's still possible for a CREATEROLE user to hand out role
>> attributes that they don't possess. The new prohibitions in
>> cf5eb37c5ee0cc54c80d95c1695d7fca1f7c68cb prevent a
Alvaro Herrera writes:
> I tried this other test, based on looking at the new regression tests
> you added,
> SELECT ts_headline('english', '
> Day after day, day after day,
> We stuck, nor breath nor motion,
> As idle as a painted Ship
> Upon a painted Ocean.
> Water, water, every where
>
On Wed, Jan 18, 2023 at 2:22 PM Andres Freund wrote:
> The problem with the change is here:
>
> /*
> * Okay, we've covered the corner cases. The normal calculation is to
> * convert the old measurement to a density (tuples per page), then
> * estimate the
Hi,
On 2023-01-18 13:42:40 -0800, Andres Freund wrote:
> The real point of change appears to be 10->11.
>
> There's a relevant looking difference in the vac_estimate_reltuples call:
> 10:
> /* now we can compute the new value for pg_class.reltuples */
> vacrelstats->new_rel_tuples =
Andrew Dunstan writes:
> I think we can do what you want but it's a bit harder than what you've
> done. If we're not going to save the current run's product then we need
> to run the upgrade test from a different directory (probably directly in
> "$buildroot/$this_branch/inst"). Otherwise we'll
On 2023-01-18 We 16:14, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2023-01-18 We 14:32, Tom Lane wrote:
>>> I suppose that the reason for not running under $from_source is to
>>> avoid corrupting the saved installations with unofficial versions.
>>> However, couldn't we skip the "save" step
> On Mon, Jan 16, 2023 at 11:57:30PM -0500, Regina Obe wrote:
>
> > What would be more bullet-proof is having an extra column in
> > pg_extension or adding an extra array element to
> > pg_extension.extcondition[] that allows you to say "Hey, don't allow
> > this to be relocatable cause other
On Wed, Jan 18, 2023 at 1:08 PM Andres Freund wrote:
> I suggested nearby to only have ANALYZE dead_tuples it if there's been no
> [auto]vacuum since the stats entry was created. That allows recovering from
> stats resets, be it via crashes or explicitly. What do you think?
I like that idea.
Hi,
On 2023-01-18 13:08:44 -0800, Andres Freund wrote:
> One complicating factor is that VACUUM sometimes computes an incrementally
> more bogus n_live_tup when it skips pages due to the VM, whereas ANALYZE
> computes something sane. I unintentionally encountered one when I was trying
> something
On Mon, Jan 16, 2023 at 11:57:30PM -0500, Regina Obe wrote:
> What would be more bullet-proof is having an extra column in pg_extension or
> adding an extra array element to pg_extension.extcondition[] that allows you
> to say "Hey, don't allow this to be relocatable cause other extensions
>
On Wed, Jan 18, 2023 at 10:15:18AM +0100, Laurenz Albe wrote:
> On Tue, 2023-01-17 at 16:16 -0500, Bruce Momjian wrote:
> > On Tue, Jan 17, 2023 at 03:00:50PM -0600, Justin Pryzby wrote:
> > > Maybe (all?) the clarification the docs need is to say:
> > > "Partitioned tables are not *themselves*
Andrew Dunstan writes:
> On 2023-01-18 We 14:32, Tom Lane wrote:
>> I suppose that the reason for not running under $from_source is to
>> avoid corrupting the saved installations with unofficial versions.
>> However, couldn't we skip the "save" step and still run the upgrade
>> tests against
On Wed, Jan 18, 2023 at 02:51:38PM -0500, Robert Haas wrote:
> Should (nfree < SuperuserReservedBackends) be using <=, or am I confused?
I believe < is correct. At this point, the new backend will have already
claimed a proc struct, so if the number of remaining free slots equals the
number of
On Wed, Jan 18, 2023 at 1:02 PM Peter Geoghegan wrote:
> Some of what I'm proposing arguably amounts to deliberately adding a
> bias. But that's not an unreasonable thing in itself. I think of it as
> related to the bias-variance tradeoff, which is a concept that comes
> up a lot in machine
Hi,
On 2023-01-18 12:15:17 -0800, Peter Geoghegan wrote:
> On Wed, Jan 18, 2023 at 11:02 AM Robert Haas wrote:
> > On Wed, Jan 18, 2023 at 1:31 PM Peter Geoghegan wrote:
> > > pgstat_report_analyze() will totally override the
> > > tabentry->dead_tuples information that drives autovacuum.c,
On 2023-01-18 We 14:32, Tom Lane wrote:
> One more thing before we move on from this topic. I'd been testing
> modified versions of the AdjustUpgrade.pm logic by building from a
> --from-source source tree, which seemed way easier than dealing
> with a private git repo. As it stands,
On Wed, Jan 18, 2023 at 12:44 PM Robert Haas wrote:
> I don't know enough about the specifics of how this works to have an
> intelligent opinion about how likely these particular ideas are to
> work out. However, I think it's risky to look at estimates and try to
> infer whether they are
> On Jan 18, 2023, at 12:51 PM, Robert Haas wrote:
>
> Unless I'm missing something, it seems like this could be a quite small patch.
I didn't like the idea of the create/alter subscription commands needing to
parse the connection string and think about what it might do, because at some
On Wed, Jan 18, 2023 at 3:26 PM Mark Dilger
wrote:
> Prior to the patch, if a superuser created a subscription, then later was
> demoted to non-superuser, the subscription apply workers still applied the
> changes with superuser force. So creating a superuser Alice, letting Alice
> create a
On Wed, Jan 18, 2023 at 3:15 PM Peter Geoghegan wrote:
> Suppose that we notice that its new
> estimate for live_tuples approximately matches what the stats
> subsystem already thought about live_tuples, while dead_tuples is far
> far lower. We shouldn't be so credulous as to believe the new
>
> On Jan 18, 2023, at 11:38 AM, Robert Haas wrote:
>
> I was just noticing that what was committed here didn't actually fix
> the problem implied by the subject line. That is, non-superuser still
> can't own subscriptions.
Not so. They can. See src/test/subscription/027_nosuperuser.pl
>
Hi,
On 2023-01-17 12:08:01 -0800, Peter Geoghegan wrote:
> > I think that's not the fault of relfrozenxid as a trigger, but that we
> > simply
> > don't keep enough other stats. We should imo at least keep track of:
>
> If you assume that there is chronic undercounting of dead tuples
> (which I
On Wed, Jan 18, 2023 at 11:02 AM Robert Haas wrote:
> On Wed, Jan 18, 2023 at 1:31 PM Peter Geoghegan wrote:
> > pgstat_report_analyze() will totally override the
> > tabentry->dead_tuples information that drives autovacuum.c, based on
> > an estimate derived from a random sample -- which seems
Laurenz Albe writes:
> On Tue, 2023-01-17 at 10:32 -0500, Tom Lane wrote:
>> I seem to recall that the original idea was to report the timestamp
>> of the commit/abort record we are stopping at. Maybe my memory is
>> faulty, but I think that'd be significantly more useful than the
>> current
On Wed, Jan 18, 2023 at 2:00 PM Nathan Bossart wrote:
> On Wed, Jan 18, 2023 at 11:28:57AM -0500, Robert Haas wrote:
> > In general, looks good. I think this will often call HaveNFreeProcs
> > twice, though, and that would be better to avoid, e.g.
>
> I should have thought of this. This is fixed
Hi,
I was playing around with splitting up the tablespace test in regress so
that I could use the tablespaces it creates in another test and happened
to notice that the pg_class validity checks in type_sanity.sql are
incomplete.
It seems that 8b08f7d4820fd did not update the pg_class tests in
On Sat, Jan 8, 2022 at 2:38 AM Jeff Davis wrote:
> Committed.
I was just noticing that what was committed here didn't actually fix
the problem implied by the subject line. That is, non-superuser still
can't own subscriptions. To put that another way, there's no way for
the superuser to delegate
One more thing before we move on from this topic. I'd been testing
modified versions of the AdjustUpgrade.pm logic by building from a
--from-source source tree, which seemed way easier than dealing
with a private git repo. As it stands, TestUpgradeXversion.pm
refuses to run under $from_source,
Hi Tomas,
Thanks for picking up the patch and for the interesting discussions that
you bring !
> Interesting. Are there any particular differences compared to how we
> estimate for example range clauses on regular columns?
The theory is the same for scalar types. Yet, the statistics that are
On Wed, 2023-01-18 at 11:49 -0600, Justin Pryzby wrote:
> I tweaked this a bit to end up with:
>
> > - Partitioned tables are not processed by autovacuum. Statistics
> > - should be collected by running a manual ANALYZE
> > when it is
> > + The leaf partitions of a partitioned table
Hi,
This patch hasn't been updated since September, and it got broken by
4a29eabd1d91c5484426bc5836e0a7143b064f5a which the incremental sort
stuff a little bit. But the breakage was rather limited, so I took a
stab at fixing it - attached is the result, hopefully correct.
I also added a couple
On Wed, 18 Jan 2023 18:34:47 +0100
Alvaro Herrera wrote:
> On 2023-Jan-18, Karl O. Pinc wrote:
>
> > On Wed, 18 Jan 2023 13:30:45 +0100
> > Alvaro Herrera wrote:
> >
> > > Not related to this patch: it's very annoying that in the PDF
> > > output, each section in the appendix doesn't start
Hi Tomas,
On Wed, 2023-01-18 at 17:29 +0100, Tomas Vondra wrote:
> I took a quick look at this patch, to see if there's something we
> want/can get into v16. The last version was submitted about 9 months
> ago, and it doesn't apply cleanly anymore, but the bitrot is fairly
> minor. Not sure
On Wed, Jan 18, 2023 at 1:31 PM Peter Geoghegan wrote:
> pgstat_report_analyze() will totally override the
> tabentry->dead_tuples information that drives autovacuum.c, based on
> an estimate derived from a random sample -- which seems to me to be an
> approach that just doesn't have any sound
On Wed, 18 Jan 2023 13:25:57 +0100
Alvaro Herrera wrote:
> On 2023-Jan-02, Karl O. Pinc wrote:
> > Attached is a patch: contrib_v1.patch
> >
> > It modifies Appendix F, the contrib directory.
> >
> > It adds brief text into the titles shown in the
> > table of contents so it's easier to tell
On Wed, Jan 18, 2023 at 11:28:57AM -0500, Robert Haas wrote:
> In general, looks good. I think this will often call HaveNFreeProcs
> twice, though, and that would be better to avoid, e.g.
I should have thought of this. This is fixed in v2.
> In the common case where we hit neither limit, this
.
On Wed, Jan 18, 2023 at 7:54 AM Robert Haas wrote:
> > It just fits: the dead tuples approach can sometimes be so
> > completely wrong that even an alternative triggering condition based
> > on something that is virtually unrelated to the thing we actually care
> > about can do much better in
Hi,
On 2023-01-18 10:22:14 -0800, Andres Freund wrote:
> On 2023-01-12 08:34:25 +0100, Peter Eisentraut wrote:
> > On 07.01.23 08:21, Peter Eisentraut wrote:
> > > This patch version looks correct to me. It is almost the same as the
> > > one that Andres had posted in his thread, except that
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This needs regression test support for the feature and some minimal
Hi,
On 2023-01-12 08:34:25 +0100, Peter Eisentraut wrote:
> On 07.01.23 08:21, Peter Eisentraut wrote:
> > On 23.11.22 14:57, Aleksander Alekseev wrote:
> > > Hi Andres,
> > >
> > > Thanks for the review!
> > >
> > > > I don't think it is correct for any of these to add const. The
> > > > only
On Wed, Jan 18, 2023 at 11:49:19AM -0600, Justin Pryzby wrote:
> On Wed, Jan 18, 2023 at 10:15:18AM +0100, Laurenz Albe wrote:
> > On Tue, 2023-01-17 at 16:16 -0500, Bruce Momjian wrote:
> > > On Tue, Jan 17, 2023 at 03:00:50PM -0600, Justin Pryzby wrote:
> > > > Maybe (all?) the clarification the
Also, calc_hist_selectivity_contains in multirangetypes_selfuncs.c needs
a proper comment, not just "this is a copy from rangetypes".
However, it seems the two functions are exactly the same. Would the
functions diverge in the future? If not, maybe there should be just a
single shared function?
On Wed, Jan 18, 2023 at 10:15:18AM +0100, Laurenz Albe wrote:
> On Tue, 2023-01-17 at 16:16 -0500, Bruce Momjian wrote:
> > On Tue, Jan 17, 2023 at 03:00:50PM -0600, Justin Pryzby wrote:
> > > Maybe (all?) the clarification the docs need is to say:
> > > "Partitioned tables are not *themselves*
On 2023-Jan-18, Karl O. Pinc wrote:
> On Wed, 18 Jan 2023 13:30:45 +0100
> Alvaro Herrera wrote:
>
> > Not related to this patch: it's very annoying that in the PDF output,
> > each section in the appendix doesn't start on a blank page -- which
> > means that the doc page for many modules
David Rowley writes:
> No objections from me.
Pushed, thanks for looking at it.
regards, tom lane
On 18/01/23 15:12, David Rowley wrote:
I also thought I'd better test that foreach_delete_current() works
with foreach_reverse(). I can confirm that it *does not* work
correctly. I guess maybe you only tested the fact that it deleted the
current item and not that the subsequent loop
Hello Mahmoud,
Thanks for the patch and sorry for not taking a look earlier.
On 6/30/22 16:31, Mahmoud Sakr wrote:
> Hi,
> Given a query:
> SELECT * FROM t1, t2 WHERE t1.r << t2.r
> where t1.r, t2.r are of range type,
> currently PostgreSQL will estimate a constant selectivity for the <<
>
On Mon, Jan 16, 2023 at 2:29 PM Robert Haas wrote:
> 1. It's still possible for a CREATEROLE user to hand out role
> attributes that they don't possess. The new prohibitions in
> cf5eb37c5ee0cc54c80d95c1695d7fca1f7c68cb prevent a CREATEROLE user
> from handing out membership in a role on which
On 1/18/23 16:06, Peter Eisentraut wrote:
On 05.12.22 21:18, Vik Fearing wrote:
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value
from the rows in its group.
PFA an
On Wed, Jan 18, 2023 at 9:44 PM Tom Lane wrote:
>
> Possibly a better answer is to refactor into separate functions,
> along the lines of
>
> static bool
> ConfigOptionIsShowable(struct config_generic *conf)
>
> static void
> GetConfigOptionValues(struct config_generic *conf, const char **values)
Hi,
I took a quick look at this patch, to see if there's something we
want/can get into v16. The last version was submitted about 9 months
ago, and it doesn't apply cleanly anymore, but the bitrot is fairly
minor. Not sure there's still interest, though.
As for the patch, I wonder if it's
On Tue, Jan 17, 2023 at 7:15 PM Nathan Bossart wrote:
> Great. Here is a first attempt at the patch.
In general, looks good. I think this will often call HaveNFreeProcs
twice, though, and that would be better to avoid, e.g.
if (!am_superuser && !am_walsender && (SuperuserReservedBackends +
Nitin Jadhav writes:
> GetConfigOptionValues function extracts the config parameters for the
> given variable irrespective of whether it results in noshow or not.
> But the parent function show_all_settings ignores the values parameter
> if it results in noshow. It's unnecessary to fetch all the
On 1/18/23 16:55, Tom Lane wrote:
Peter Eisentraut writes:
On 05.12.22 21:18, Vik Fearing wrote:
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value
from the rows in its
Peter Eisentraut writes:
> On 05.12.22 21:18, Vik Fearing wrote:
>> On 12/5/22 15:57, Vik Fearing wrote:
>>> The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
>>> returns an implementation-dependent (i.e. non-deterministic) value
>>> from the rows in its group.
> Since the
On Wed, Jan 18, 2023 at 8:38 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > ... I was going for the html effect
> > of having these views chunked into their own pages, any other changes
> being
> > non-detrimental.
>
> But is that a result we want? It will for example break any
1 - 100 of 146 matches
Mail list logo
