Thomas Munro writes:
> ... It works if you're OK creating partial paths
> for everything...
Hmm. The committed patch already causes us to investigate more
paths than before, which I was okay with because it only costs
more if there's an antijoin involved --- which it seems like
there's at least
On Thu, Apr 6, 2023 at 12:17 PM Thomas Munro wrote:
> I tried the original example from the top of this thread and saw a
> decent speedup from parallelism, but only if I set
> min_parallel_table_scan_size=0, and otherwise it doesn't choose
> Parallel Hash Right Anti Join. Same if I embiggen bar
Dear Julien,
> I'm attaching a v3 to fix a recent conflict with pg_dump due to a563c24c9574b7
> (Allow pg_dump to include/exclude child tables automatically).
Thank you for making the patch.
FYI - it could not be applied due to recent commits. SUBOPT_* and attributes
in SubscriptionInfo was
Hi Andrey,
27.03.2023 01:17, Andrey Borodin wrote:
I've ported the B-tree TOAST test to GiST, and, as expected, it fails.
Finds non-indexed tuple for a fresh valid index.
I've tried to use this feature with the latest patch set and discovered that
modified pg_amcheck doesn't find any gist
On Mon, Apr 03, 2023 at 08:56:10AM +0530, Bharath Rupireddy wrote:
> It looks like comments in make file and meson file about not running
> basic_archive tests in NO_INSTALLCHECK mode are wrong. The comments say the
> module needs to be loaded via shared_preload_libraries=basic_archive, but
> it
On Wed, Apr 05, 2023 at 02:31:54PM +, Imseih (AWS), Sami wrote:
>> That seems a valid argument. I was thinking that such an asynchronous
>> state update mechanism would be a good infrastructure for progress
>> reporting of parallel operations. It might be worth considering to use
>> it in more
On Wed, Apr 5, 2023 at 3:43 PM Melanie Plageman
wrote:
>
> On Wed, Apr 5, 2023 at 2:56 PM Robert Haas wrote:
> >
> > + /*
> > + * Balance and update limit values for autovacuum workers. We must
> > + * always do this in case the autovacuum launcher or another
> > + * autovacuum worker has
At Wed, 5 Apr 2023 11:55:14 -0700, Andres Freund wrote in
> Hi,
>
> On 2023-04-05 11:48:53 -0700, Andres Freund wrote:
> > Note that a checkpoint started at "17:50:23.787", but didn't finish before
> > the
> > database was shut down. As far as I can tell, this can not be caused by
> >
Attached is v14 which adds back in tests for the BUFFER_USAGE_LIMIT
option. I haven't included a test for VACUUM (BUFFER_USAGE_LIMIT x,
PARALLEL x) for the reason I mentioned upthread -- even if we force it
to actually do the parallel vacuuming, we are adding exercising the code
where parallel
On Wed, Apr 05, 2023 at 06:54:54PM -0700, Andres Freund wrote:
> On 2023-04-06 01:33:56 +0200, Alvaro Herrera wrote:
>> I'll go over this again tomorrow with fresh eyes, but I think it should
>> be pretty close to ready. (Need to amend docs to note the new NO
>> INHERIT option for NOT NULL table
On Tue, Mar 28, 2023 at 09:35:30AM +0900, Michael Paquier wrote:
> The patch needs to provide more details about the unknown state, IMO,
> to make it crystal-clear to the users what are the limitations of this
> GUC, especially regarding the fact that this is useful when "try"-ing
> to allocate
On Wed, Apr 05, 2023 at 04:35:37PM +0200, Matthias van de Meent wrote:
> I thought that the plan was to use int64 to skip checking for most
> overflows and to do a single check at the end in XLogRecordAssemble,
> so that the checking has minimal overhead in the performance-critical
> log record
Hi,
On 2023-04-06 01:33:56 +0200, Alvaro Herrera wrote:
> I'll go over this again tomorrow with fresh eyes, but I think it should
> be pretty close to ready. (Need to amend docs to note the new NO
> INHERIT option for NOT NULL table constraints, and make sure pg_dump
> complies.)
Missed this
Hi,
On 2023-04-04 17:39:45 -0700, Andres Freund wrote:
> I'm planning to push the patches up to the hio.c changes soon, unless somebody
> would like me to hold off.
Done that.
> After that I'm planning to wait for a buildfarm cycle, and push the changes
> necessary to use bulk extension in
On Wed, Apr 5, 2023 at 3:30 PM Stephen Frost wrote:
> Greetings,
>
> * David Christensen (david...@pgguru.net) wrote:
> > Did a code review pass here; here is some feedback.
>
> Thanks!
>
> > + /* If password was used to connect, make sure it was one provided
> */
> > + if
On Thu, 6 Apr 2023 at 13:14, David Rowley wrote:
> Is it intended that VACUUM t1,t2; now share the same strategy?
> Currently, in master, we'll allocate a new strategy for t2 after
> vacuuming t1. Does this not mean we'll now leave fewer t1 pages in
> shared_buffers because the reuse of the
On Wed, Apr 5, 2023 at 9:15 PM David Rowley wrote:
>
> On Thu, 6 Apr 2023 at 12:42, Melanie Plageman
> wrote:
> > Attached is a v12 of the whole vacuum_buffer_usage_limit patch set which
> > includes a commit to fix the bug in master and a commit to move relevant
> > code from vacuum() up into
On Thu, 6 Apr 2023 at 12:42, Melanie Plageman wrote:
> Attached is a v12 of the whole vacuum_buffer_usage_limit patch set which
> includes a commit to fix the bug in master and a commit to move relevant
> code from vacuum() up into ExecVacuum().
I'm still playing catch up to the moving of the
On Wed, Apr 05, 2023 at 05:39:35PM -0700, Andres Freund wrote:
> Seems like a complicated enough facility to benefit from a test or two? Peter
> Eisentraut added support for the extended query protocol to psql, so it
> shouldn't be too hard...
PQsendQueryGuts() does not split yet the
On Wed, Apr 5, 2023 at 6:55 PM Melanie Plageman
wrote:
>
> On Wed, Apr 5, 2023 at 5:15 PM Andres Freund wrote:
> >
> > Hi,
> >
> > On 2023-04-05 16:17:20 -0400, Melanie Plageman wrote:
> > > On Wed, Apr 5, 2023 at 1:05 PM Andres Freund wrote:
> > > > Perhaps the best solution for autovac vs
On Wed, Apr 05, 2023 at 10:16:19PM +, Imseih (AWS), Sami wrote:
> Here is v6. That was my mistake not to zero out the es_total_processed.
> I had it in the first version.
The update of es_total_processed in standard_ExecutorRun() felt a bit
lonely, so I have added an extra comment, ran an
Hi,
On 2023-04-06 07:09:37 +0900, Michael Paquier wrote:
> I'll look at that again today, potentially apply the fix on HEAD.
Seems like a complicated enough facility to benefit from a test or two? Peter
Eisentraut added support for the extended query protocol to psql, so it
shouldn't be too
On Fri, Feb 17, 2023 at 11:41:32AM -0800, Andres Freund wrote:
> I don't fully now, it's not entirely clear to me what the goals here were. I
> think you'd likely need to do a bit of infrastructure work to do this
> sanely. So far we just didn't have the need to handle files being released in
> a
On Thu, Apr 6, 2023 at 9:11 AM Tom Lane wrote:
> Richard Guo writes:
> > Thanks for reminding. Attached is the rebased patch, with no other
> > changes. I think the patch is ready for commit.
>
> Pushed after a little further fooling with the comments. I also had
> to rebase it over 11c2d6fdf
On Thu, Apr 6, 2023 at 3:33 Tom Lane wrote:
> Amit Langote writes:
> > While thinking about query view locking in context of [1], I realized
> > that we have missed also fixing AcquirePlannerLocks() /
> > ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to
> > a view, which
On Tue, Apr 4, 2023 at 10:29 PM Amit Langote
wrote:
> On Tue, Apr 4, 2023 at 6:41 AM Tom Lane wrote:
> > A few concrete thoughts:
> >
> > * I understand that your plan now is to acquire locks on all the
> > originally-named tables, then do permissions checks (which will
> > involve only those
On Wed, Apr 5, 2023 at 5:15 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-04-05 16:17:20 -0400, Melanie Plageman wrote:
> > On Wed, Apr 5, 2023 at 1:05 PM Andres Freund wrote:
> > > Perhaps the best solution for autovac vs interactive vacuum issue would
> > > be to
> > > move the allocation of
> Makes sense to me. I'll look at that again today, potentially apply
> the fix on HEAD.
Here is v6. That was my mistake not to zero out the es_total_processed.
I had it in the first version.
--
Regards,
Sami Imseih
Amazon Web Services (AWS)
On Wed, Apr 05, 2023 at 05:39:13PM -0400, Tom Lane wrote:
> v5 seems OK to me except I think CreateExecutorState() should explicitly
> zero the new es_total_processed field, alongside zeroing es_processed.
> (I realize that the makeNode would have done it already, but our
> coding conventions
On Wed, Apr 05, 2023 at 10:43:23AM -0400, Tom Lane wrote:
> Robert Haas writes:
>> Maybe we should back up and ask why we need more than "on" and "off".
>> If somebody is using this feature in any form more than very
>> occasionally, they should really go home and reconsider their database
>>
On Wed, Apr 5, 2023 at 2:33 PM David Rowley wrote:
> I read this twice yesterday and again this morning. It looks like
> you're taking an opportunity to complain/vent about
> vacuum_freeze_table_age and didn't really answer my query about why
> all the vacuum GUCs aren't defined in the one file.
Thanks for pushing.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
For what it's worth, I think having the anchors be always-visible when
CSS disabled is a feature. The content is still perfectly readable,
and the core feature from this patch is available. Introducing
JavaScript to lose that functionality seems like a step backwards.
By the way, the latest patch
On Thu, Apr 6, 2023 at 09:23:31AM +1200, David Rowley wrote:
> On Thu, 6 Apr 2023 at 03:12, Bruce Momjian wrote:
> > During two presentations, I was asked if negative cache entries were
> > created for cases where inner-side lookups returned no rows.
> >
> > It seems we don't do that. Has this
Corey Huinker writes:
> Following up here. This addendum patch clearly isn't as important as
> anything currently trying to make it in before the feature freeze, but I
> think the lack of setting the SHELL_ERROR and SHELL_EXIT_CODE vars on piped
> commands would be viewed as a bug, so I'm hoping
Unless there are objections I plan to get this in before the freeze, in order
to have better interactive tests starting with 16. With a little bit of
documentation polish I think it's ready.
--
Daniel Gustafsson
Michael Paquier writes:
> On Wed, Apr 05, 2023 at 04:07:21AM +, Imseih (AWS), Sami wrote:
>> Attached is v5 addressing the comments.
> Thanks, this should be enough to persist the number of tuples tracked
> across multiple ExecutorRun() calls. This looks pretty good to me.
v5 seems OK to
On Wed, 5 Apr 2023 at 16:37, Peter Geoghegan wrote:
>
> On Tue, Apr 4, 2023 at 8:14 PM David Rowley wrote:
> > 14. Not related to this patch, but why do we have half the vacuum
> > related GUCs in vacuum.c and the other half in globals.c? I see
> > vacuum_freeze_table_age is defined in vacuum.c
On Wed, Apr 5, 2023 at 2:27 PM Daniel Gustafsson wrote:
> I squashed and pushed v10 with a few small comment tweaks for typos and some
> pgindenting. Thanks!
Thank you very much!
--Jacob
On Fri, Mar 24, 2023 at 5:21 PM Corey Huinker
wrote:
>
>
> On Tue, Mar 21, 2023 at 3:33 PM Corey Huinker
> wrote:
>
>>
>>> As you had it, any nonzero result would prevent backtick substitution.
>>> I'm not really sure how much thought went into the existing behavior,
>>> but I am pretty sure
> On 3 Apr 2023, at 23:09, Jacob Champion wrote:
>
> On Mon, Apr 3, 2023 at 12:40 PM Daniel Gustafsson wrote:
>> Doh, sorry, my bad. I read and wrote 1.0.1 but was thinking about 1.0.2.
>> You
>> are right, in 1.0.1 that API does not exist. I'm not all too concerned with
>> skipping this
On Thu, 6 Apr 2023 at 03:12, Bruce Momjian wrote:
> During two presentations, I was asked if negative cache entries were
> created for cases where inner-side lookups returned no rows.
>
> It seems we don't do that. Has this been considered or is it planned?
It does allow negative cache entries,
Hi,
On 2023-04-05 16:17:20 -0400, Melanie Plageman wrote:
> On Wed, Apr 5, 2023 at 1:05 PM Andres Freund wrote:
> > Perhaps the best solution for autovac vs interactive vacuum issue would be
> > to
> > move the allocation of the bstrategy to ExecVacuum()?
>
> So, I started looking into
Richard Guo writes:
> Thanks for reminding. Attached is the rebased patch, with no other
> changes. I think the patch is ready for commit.
Pushed after a little further fooling with the comments. I also had
to rebase it over 11c2d6fdf (Parallel Hash Full Join). I think I did
that correctly,
On Wed, Apr 5, 2023 at 1:38 PM Daniel Gustafsson wrote:
> Not to derail this thread, and pre-empt a thread where this can be discussed
> in
> its own context, but isn't that kind of the main problem? Tuning autovacuum
> is
> really complicated and one of the parameters that I think universally
> On 5 Apr 2023, at 22:19, Peter Geoghegan wrote:
> The bigger problem seems to
> be everything else -- the way that tuning autovacuum_max_workers kinda
> makes sense (it shouldn't be an interesting tunable)
Not to derail this thread, and pre-empt a thread where this can be discussed in
its own
Greetings,
* David Christensen (david...@pgguru.net) wrote:
> Did a code review pass here; here is some feedback.
Thanks!
> + /* If password was used to connect, make sure it was one provided */
> + if (PQconnectionUsedPassword(conn) && dblink_connstr_has_pw(connstr))
> +
On Wed, Apr 5, 2023 at 11:56 AM Robert Haas wrote:
> To be honest, I think that the whole system where we divide the cost
> limit across the workers is the wrong idea. Does anyone actually like
> that behavior? This patch probably shouldn't touch that, just in the
> interest of getting something
On Wed, Apr 5, 2023 at 1:05 PM Andres Freund wrote:
>
> Hi,
>
> On 2023-04-04 13:53:15 -0400, Melanie Plageman wrote:
> > > 8. I don't quite follow this comment:
> > >
> > > /*
> > > * TODO: should this be 0 so that we are sure that vacuum() never
> > > * allocates a new bstrategy for us, even if
Nathan Bossart writes:
> On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote:
>> I would not mind having a separate function returning 6 rows, if we really
>> want that, but making pg_buffercache_summary() return 6 rows would imo make
>> it
>> less useful for getting a quick overview.
I wrote:
> Amit Langote writes:
>> While thinking about query view locking in context of [1], I realized
>> that we have missed also fixing AcquirePlannerLocks() /
>> ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to
>> a view, which must be locked the same as RTE_RELATION
On Wed, Apr 5, 2023 at 3:44 PM Melanie Plageman
wrote:
> VacuumUpdateCosts() also calls AutoVacuumUpdateCostLimit(), so this will
> happen if a config reload is pending the next time vacuum_delay_point()
> is called (which is pretty often -- roughly once per block vacuumed but
> definitely more
On Thu, Apr 6, 2023 at 7:46 AM Thomas Munro wrote:
> Initially I was suspicious that there may be tricky races to deal with
> around that wakeup logic, and the poll/sleep loop was due to an
> inability to come up with something reliable.
(Oops lost a sentence) ... but then I realised that we're
Hi,
Currently the standby reaches ResolveRecoveryConflictWithVirtualXIDs()
with a waitlist of VXIDs that are preventing it from making progress.
For each one it enters a sleep/poll loop that repeatedly tries to
acquire (conditionally) the VXID lock with VirtualXactLock(vxid,
wait=false), as a
On Wed, Apr 5, 2023 at 2:56 PM Robert Haas wrote:
>
> + /*
> + * Balance and update limit values for autovacuum workers. We must
> + * always do this in case the autovacuum launcher or another
> + * autovacuum worker has recalculated the number of workers across
> + * which we must balance the
On 4/4/23 05:04, Justin Pryzby wrote:
> On Mon, Apr 03, 2023 at 11:26:09PM +0200, Tomas Vondra wrote:
>> On 4/3/23 21:17, Justin Pryzby wrote:
>>> On Sat, Apr 01, 2023 at 10:26:01PM +0200, Tomas Vondra wrote:
> Feel free to mess around with threads (but I'd much rather see the patch
>
On Wed, Apr 5, 2023 at 3:04 PM Daniel Gustafsson wrote:
> > Daniel: Are you intending to commit this?
>
> Yes, my plan is to get it in before feature freeze.
All right, let's make it happen! I think this is pretty close to ready
to ship, and it would solve a problem that is real, annoying, and
On Wed, Apr 05, 2023 at 12:09:21PM -0700, Andres Freund wrote:
> I would not mind having a separate function returning 6 rows, if we really
> want that, but making pg_buffercache_summary() return 6 rows would imo make it
> less useful for getting a quick overview. At least I am not that quick
On Wed, Apr 05, 2023 at 03:07:10PM -0400, Tom Lane wrote:
> Seems to me that six rows would be easier to aggregate manually.
> An array column seems less SQL-ish and harder to manipulate.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
v11 attached with updates detailed below.
On Tue, Apr 4, 2023 at 11:14 PM David Rowley wrote:
>
> On Wed, 5 Apr 2023 at 05:53, Melanie Plageman
> wrote:
> > Attached v10 addresses the review feedback below.
>
> Thanks. Here's another round on v10-0001:
>
> 1. The following documentation
Hi,
On 2023-04-05 15:00:20 -0400, Robert Haas wrote:
> On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart
> wrote:
> > On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> > > On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
> > >> > Replacing that with a six-element integer array
Robert Haas writes:
> On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart
> wrote:
>> The six-element array approach won't show the number of dirty and pinned
>> buffers for each usage count, but I'm not sure that's a deal-breaker.
>> Barring objections, I'll post an updated patch shortly with that
> On 5 Apr 2023, at 20:55, Robert Haas wrote:
> Again, I don't think this is something we should try to
> address right now under time pressure, but in the future, I think we
> should consider ripping this behavior out.
I would not be opposed to that, but I wholeheartedly agree that it's not
On Wed, Apr 5, 2023 at 1:51 PM Nathan Bossart wrote:
> On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> > On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
> >> > Replacing that with a six-element integer array would be a clear
> >> > improvement
> >> > and, IMHO, better than
On Wed, Apr 5, 2023 at 11:29 AM Melanie Plageman
wrote:
> Thanks all for the reviews.
>
> v16 attached. I put it together rather quickly, so there might be a few
> spurious whitespaces or similar. There is one rather annoying pgindent
> outlier that I have to figure out what to do about as well.
Hi,
On 2023-04-05 11:48:53 -0700, Andres Freund wrote:
> Note that a checkpoint started at "17:50:23.787", but didn't finish before the
> database was shut down. As far as I can tell, this can not be caused by
> checkpoint_timeout, because by the time we get to invalidating replication
> slots,
Hi,
I just saw the following failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon=2023-04-05%2017%3A47%3A03
after a commit of mine. The symptoms look unrelated though.
[17:54:42.188](258.345s) # poll_query_until timed out executing this query:
# SELECT wal_status FROM
> On 5 Apr 2023, at 16:30, Robert Haas wrote:
>
> On Wed, Apr 5, 2023 at 4:57 AM Daniel Gustafsson wrote:
>>> - Being able to write a list of event triggers working would be much
>>> more interesting than just individual elements.
>>> - There may be an argument for negated patterns? Say,
>>> a
Amit Langote writes:
> While thinking about query view locking in context of [1], I realized
> that we have missed also fixing AcquirePlannerLocks() /
> ScanQueryForLocks() to consider that an RTE_SUBQUERY rte may belong to
> a view, which must be locked the same as RTE_RELATION entries.
I think
Hi,
On 2023-04-05 17:56:14 +0200, Drouvot, Bertrand wrote:
> @@ -7963,6 +7963,23 @@ xlog_redo(XLogReaderState *record)
> /* Update our copy of the parameters in pg_control */
> memcpy(, XLogRecGetData(record),
> sizeof(xl_parameter_change));
>
> + /*
> +
st 5. 4. 2023 v 19:20 odesílatel Greg Stark napsal:
> On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
> >
> > This feature can significantly increase log size, so it's disabled by
> default.
> > For testing or development environments it's recommended to enable it if
> you
> > use session
On Wed, Apr 05, 2023 at 09:44:58AM -0400, Robert Haas wrote:
> On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
>> > Replacing that with a six-element integer array would be a clear
>> > improvement
>> > and, IMHO, better than adding yet another function to the extension.
>>
>> I'd have no
Hi,
On 2023-04-05 13:26:53 -0400, Greg Stark wrote:
> On Wed, 5 Apr 2023 at 11:15, Andres Freund wrote:
> >
> > The freebsd test that failed is running tests in parallel, against an
> > existing
> > cluster. In that case it's expected that there's some concurrency.
> >
> > Why does this cause
On Wed, 5 Apr 2023 at 11:15, Andres Freund wrote:
>
> The freebsd test that failed is running tests in parallel, against an existing
> cluster. In that case it's expected that there's some concurrency.
>
> Why does this cause your tests to fail? They're in separate databases, so the
> visibility
On Sun, 26 Mar 2023 at 07:34, Julien Rouhaud wrote:
>
> This feature can significantly increase log size, so it's disabled by default.
> For testing or development environments it's recommended to enable it if you
> use session variables.
I think it's generally not practical to have warnings for
Hi,
On 2023-04-04 13:53:15 -0400, Melanie Plageman wrote:
> > 8. I don't quite follow this comment:
> >
> > /*
> > * TODO: should this be 0 so that we are sure that vacuum() never
> > * allocates a new bstrategy for us, even if we pass in NULL for that
> > * parameter? maybe could change how
Greg Stark writes:
> On Mon, 3 Apr 2023 at 19:32, Tom Lane wrote:
>> Or we could rethink the design goal of not allowing enable_foo switches
>> to cause us to fail to make a plan. That might be unusable though.
> The only one that gives me pause is enable_seqscan. I've seen multiple
> sites
st 5. 4. 2023 v 17:47 odesílatel Robert Haas napsal:
> On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule
> wrote:
> > If the GUC_REPORT should not be used, then only one possibility is
> enhancing the protocol, about the possibility to read some predefined
> server's features from the client.
> >
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Push, thanks again!
>
> Why'd you only change HEAD? Isn't the test equally fragile in the
> back branches?
Following on from this after some additional cross-platform testing,
turns out there's other options we
Hi,
On 4/5/23 4:24 PM, Robert Haas wrote:
On Tue, Apr 4, 2023 at 8:33 PM Jeff Davis wrote:
For comments, I agree that WalSndWakeup() clearly needs a comment
update. The call site in ApplyWalRecord() could also use a comment. You
could add a comment at every call site, but I don't think that's
Hi,
On 4/5/23 3:15 PM, Amit Kapila wrote:
On Wed, Apr 5, 2023 at 6:14 PM Drouvot, Bertrand
wrote:
On 4/5/23 12:28 PM, Amit Kapila wrote:
On Wed, Apr 5, 2023 at 2:41 PM Drouvot, Bertrand
wrote:
minor nitpick:
+
+ /* Intentional fall through to session cancel */
+ /* FALLTHROUGH */
Do we
Hi,
On 4/5/23 1:59 PM, Amit Kapila wrote:
On Wed, Apr 5, 2023 at 3:58 PM Amit Kapila wrote:
On Wed, Apr 5, 2023 at 2:41 PM Drouvot, Bertrand
wrote:
minor nitpick:
+
+ /* Intentional fall through to session cancel */
+ /* FALLTHROUGH */
Do we need to repeat fall through twice in different
> On 5 Apr 2023, at 17:29, Melanie Plageman wrote:
>>
>> I think I wasn't clear in my comment, sorry. I don't have a problem with
>> introducing a new variable to split the balanced value from the GUC value.
>> What I don't think we should do is repurpose an exported symbol into doing a
>> new
On Wed, Apr 5, 2023 at 11:34 AM Pavel Stehule wrote:
> If the GUC_REPORT should not be used, then only one possibility is enhancing
> the protocol, about the possibility to read some predefined server's features
> from the client.
> It can be much cheaper than SQL query, and it can be used
On Mon, 3 Apr 2023 at 19:32, Tom Lane wrote:
>
> Or we could rethink the design goal of not allowing enable_foo switches
> to cause us to fail to make a plan. That might be unusable though.
Off the top of my head I don't see why. It's not like the possible
plans are going to change on you
st 5. 4. 2023 v 16:02 odesílatel Robert Haas napsal:
> On Wed, Apr 5, 2023 at 9:56 AM Tom Lane wrote:
> > Robert Haas writes:
> > > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
> > >> Basically, I want to reject this on the grounds that it's not
> > >> useful enough to justify the overhead
Thanks all for the reviews.
v16 attached. I put it together rather quickly, so there might be a few
spurious whitespaces or similar. There is one rather annoying pgindent
outlier that I have to figure out what to do about as well.
The remaining functional TODOs that I know of are:
- Resolve
I wrote an optimizer talk that explains memoize, slides 24-25:
https://momjian.us/main/writings/pgsql/beyond.pdf#page=25
During two presentations, I was asked if negative cache entries were
created for cases where inner-side lookups returned no rows.
It seems we don't do that. Has this
Hi,
On 2023-04-05 10:19:10 -0400, Greg Stark wrote:
> On Wed, 5 Apr 2023 at 01:41, Greg Stark wrote:
> >
> > On Wed, 29 Mar 2023 at 17:48, Justin Pryzby wrote:
> > >
> > > The patch still occasionally fails its tests under freebsd.
> > >
st 5. 4. 2023 v 15:56 odesílatel Tom Lane napsal:
> Robert Haas writes:
> > On Tue, Apr 4, 2023 at 12:42 PM Tom Lane wrote:
> >> Basically, I want to reject this on the grounds that it's not
> >> useful enough to justify the overhead of marking the "role" GUC
> >> as GUC_REPORT.
>
> > I agree
Hi,
On 2023-04-05 12:24:04 +0200, Peter Eisentraut wrote:
> On 15.03.23 08:14, Peter Eisentraut wrote:
> > 3. The various build targets and their combinations are mismatching and
> > incomplete.
>
> This has been improved, and I see there is documentation.
>
> I think it's still an issue that
Robert Haas writes:
> Maybe we should back up and ask why we need more than "on" and "off".
> If somebody is using this feature in any form more than very
> occasionally, they should really go home and reconsider their database
> schema.
+1 ... this seems perhaps overdesigned.
"Anton A. Melnikov" writes:
> On 03.04.2023 21:49, Tom Lane wrote:
>> I did not think this case was worth memorializing in a test before,
>> and I still do not. I'm inclined to reject this patch.
> Could you help me to figure out, please.
The problem was an Assert that was speculative when it
On Tue, 28 Mar 2023 at 13:42, Michael Paquier wrote:
>
> On Mon, Dec 19, 2022 at 12:37:19PM +0100, Alvaro Herrera wrote:
> > I have created one in the January commitfest,
> > https://commitfest.postgresql.org/41/
> > and rebased the patch on current master. (I have not reviewed this.)
>
> I have
> > The key point of the patch is here. From what I understand based on
> > the information of the thread, this is used as a way to make the
> progress reporting done by the leader more responsive so as we'd
> > update the index counters each time the leader is poked at with a 'P'
> > message by
On Wed, Apr 5, 2023 at 4:57 AM Daniel Gustafsson wrote:
> > - Being able to write a list of event triggers working would be much
> > more interesting than just individual elements.
> > - There may be an argument for negated patterns? Say,
> > a "!sql_drop,!ddl_command_start" would cause sql_drop
On Wed, Apr 5, 2023 at 6:58 AM Tom Lane wrote:
> Pavel Luzanov writes:
> > What if this long output will be available only for \du+, and for \du
> > just show distinct (without duplicates)
> > roles in the current array format? For those, who don't care about these
> > new membership options,
On Tue, Apr 4, 2023 at 8:33 PM Jeff Davis wrote:
> Perhaps a commit message like:
>
> "For cascading replication, wake up physical walsenders separately from
> logical walsenders.
>
> Physical walsenders can't send data until it's been flushed; logical
> walsenders can't decode and send data
On Wed, 5 Apr 2023 at 01:41, Greg Stark wrote:
>
> On Wed, 29 Mar 2023 at 17:48, Justin Pryzby wrote:
> >
> > The patch still occasionally fails its tests under freebsd.
> > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/42/3358
>
> I wonder if some other test is behaving
Hello!
On 03.04.2023 21:49, Tom Lane wrote:
"Anton A. Melnikov" writes:
Now there are no any pending questions, so moved it to RFC.
I did not think this case was worth memorializing in a test before,
and I still do not. I'm inclined to reject this patch.
Earlier, when discussing this
1 - 100 of 134 matches
Mail list logo
