> On 5 Apr 2023, at 07:27, Koshi Shibagaki (Fujitsu)
> wrote:
> I found out that there is a mistake written in
> contrib/postgres_fdw/postgres_fdw.c.
Thanks for the report, fixed.
--
Daniel Gustafsson
Hi Tom:
Sorry for the delayed response! I think my knowledge has been refreshed
for this discussion.
> One thing I'm not at all clear about is whether we need to restrict
> the optimization so that it doesn't occur if the subquery contains
> outer references falling outside available_rels. I
Hi.
About 0001:
+ * VacuumFailsafeActive is a defined as a global so that we can determine
+ * whether or not to re-enable cost-based vacuum delay when vacuuming a table.
+ * If failsafe mode has been engaged, we will not re-enable cost-based delay
+ * for the table until after vacuuming has comp
On 2023-Apr-04, Andrew Dunstan wrote:
> On 2023-04-04 Tu 08:36, Alvaro Herrera wrote:
> >
> > Surely this can be made cleaner.
> >
> > By the way -- that comment about clauses being non-standard, can you
> > spot exactly *which* clauses that comment applies to?
>
> Sadly, I don't think we're go
Dear hackers,
> Dear Fujii-san, Tom,
>
> Thank you for giving a suggestion! PSA new version.
I have reviewed and revised patches by myself.
* Fix handing of poll() based on the Horiguchi-san's point
* Fix WARNING message that shows user name which is used for connection
* PQconnCheck(), PQconnC
On 16.03.23 14:52, Peter Eisentraut wrote:
On 09.03.23 20:14, Jeff Davis wrote:
Let's come back to that after dealing with the other two.
Leaving 0001 open for now.
I suspect making a change like this now would result in a bloodbath on
the build farm that we could do without. I suggest rev
On 04.04.2023 22:02, David G. Johnston wrote:
On Tue, Apr 4, 2023 at 10:37 AM Tom Lane wrote:
Robert Haas writes:
> On Tue, Apr 4, 2023 at 1:12 PM Tom Lane wrote:
>> I wonder if, while we're here, we should apply the idea of
>> joining-with-newlines-not-commas to the attribute
On Fri, Feb 24, 2023 at 03:16:10PM +0900, Masahiko Sawada wrote:
> Thanks! It looks good to me so I've marked it as Ready for Committer.
+ case 'P': /* Parallel progress reporting */
+ {
+ /* Call the progress reporting callback */
+ Asser
> On 4 Apr 2023, at 20:36, Greg Stark wrote:
>
> On Tue, 4 Apr 2023 at 11:18, Tom Lane wrote:
>>
>>> * clean up permission checks after 599b33b94
>>
>> I believe that the actual bug fixes are in, and what's left is just a test
>> case that people weren't very excited about adding. So maybe th
Hi,
On 4/4/23 7:53 PM, Andres Freund wrote:
Hi,
On 2023-04-04 18:54:33 +0200, Drouvot, Bertrand wrote:
if (check_on_xid)
{
if (terminating)
appendStringInfo(&err_msg, _("terminating process %d to release replication slot
\"%s\" because it conflicts with recover
Hi,
On 4/4/23 8:13 PM, Jeff Davis wrote:
On Tue, 2023-04-04 at 11:42 +0200, Drouvot, Bertrand wrote:
Done in V58 and now this is as simple as:
Minor comments on 0004 (address if you agree):
Thanks for the review!
* Consider static inline for WalSndWakeupProcessRequests()?
Agree and do
Hi,
On 4/5/23 2:33 AM, Jeff Davis wrote:
On Tue, 2023-04-04 at 14:55 -0400, Robert Haas wrote:
Thanks for your continued work on $SUBJECT. I just took a look at
0004,
Thanks Robert for the feedback!
and I think that at the very least the commit message needs
work.
Agree.
Perhaps a commi
On Mon, Apr 03, 2023 at 11:35:14PM +0200, Daniel Gustafsson wrote:
> Yeah. The patch as it stands allow for disabling specific types rather than
> all-or-nothing, which is why the name was "ignore".
FWIW, I agree with Robert's points here:
- disable_event_triggers or ignore_event_triggers = off l
On Wed, Apr 5, 2023 at 4:47 PM Michael Paquier wrote:
>
> On Fri, Feb 24, 2023 at 03:16:10PM +0900, Masahiko Sawada wrote:
> > Thanks! It looks good to me so I've marked it as Ready for Committer.
>
> + case 'P': /* Parallel progress reporting */
> + {
> +
> On 5 Apr 2023, at 10:10, Michael Paquier wrote:
>
> On Mon, Apr 03, 2023 at 11:35:14PM +0200, Daniel Gustafsson wrote:
>> Yeah. The patch as it stands allow for disabling specific types rather than
>> all-or-nothing, which is why the name was "ignore".
>
> FWIW, I agree with Robert's points h
> On 4 Apr 2023, at 18:03, Andres Freund wrote:
> I'm planning to generate the 15->16 differential code coverage, once the
> feature freeze has been reached.
Cool!
> I think for now it'd likely be a small script that'd generate the code
> coverage across versions. Do we want to have that in the
Hi,
On 4/5/23 8:59 AM, Amit Kapila wrote:
On Mon, Apr 3, 2023 at 12:05 PM Amit Kapila wrote:
On further thinking, as such this shouldn't be a problem because all
the WAL records before PARAMETER_CHANGE record will have sufficient
information so that they can get decoded. However, with the cu
On 01.03.23 10:12, Peter Eisentraut wrote:
SQL:2023 should be published within the next 2 months, so I want to
update our SQL conformance information for our PostgreSQL release later
this year.
Attached are patches that update the keywords list and the features list
as usual. (Some of the ne
On 15.03.23 08:14, Peter Eisentraut wrote:
I have identified several open issues with the documentation build under
Meson (approximately in priority order):
Some work has been done on this. Here is my current assessment.
1. Image files are not handled at all, so they don't show up in the
fin
On Wed, Apr 5, 2023 at 2:41 PM Drouvot, Bertrand
wrote:
>
> On 4/5/23 8:59 AM, Amit Kapila wrote:
> > On Mon, Apr 3, 2023 at 12:05 PM Amit Kapila wrote:
>
> > On further thinking, as such this shouldn't be a problem because all
> > the WAL records before PARAMETER_CHANGE record will have sufficie
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 ways?
>
Few minor comments on
Hi,
On 4/5/23 12:28 PM, Amit Kapila wrote:
On Wed, Apr 5, 2023 at 2:41 PM Drouvot, Bertrand
wrote:
Maybe we could change the doc with something among those lines instead?
"
Existing logical slots on standby also get invalidated if wal_level on primary
is reduced to
less than 'logical'. This
On Tue, Apr 4, 2023 at 8:29 PM Peter Smith wrote:
> There seems to be a comment typo in the recent commit "Perform logical
> replication actions as the table owner" [1].
>
> /*
> * Switch back to the original user ID.
> *
> * If we created a new GUC nest level, also role back any changes that w
> On 4 Apr 2023, at 22:04, Melanie Plageman wrote:
>
> On Tue, Apr 4, 2023 at 4:27 AM Masahiko Sawada wrote:
>> Also, I don't think there is any reason why we want to exclude only
>> the autovacuum launcher.
>
> My rationale is that the launcher is the only other process type which
> might rea
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 need to repeat
> From: Masahiko Sawada
> > >
> > > 3. The apply worker launches the tablesync workers for tables that
> > > need to be synchronized.
> > >
> > > There might be DDLs executed on the publisher for tables before the
> > > tablesync worker starts. But the apply worker needs to apply DDLs
> > > for pr
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 with that. I think we need some method for optionally
reporting values, so that stuff like thi
On Tue, Apr 4, 2023 at 7:29 PM Andres Freund wrote:
> > I'm skeptical that pg_buffercache_summary() is a good idea at all
>
> Why? It's about two orders of magnitude faster than querying the equivalent
> data by aggregating in SQL. And knowing how many free and dirty buffers are
> over time is som
Hi hackers,
Parallelism has been in core since 9.6, it's a great feature that got
several
upgrades since then. However, it lacks metrics to determine if and how
parallelism is used and help tune parameters related to it.
Currently, the only information available are pg_stat_activity.backend_ty
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 with that. I think we need some method for optionally
> reporting
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, nothing will change.
> Those, who need details will use the
Not sure if this is the right place to ask but I've tried to build using
this source rpm
https://ftp.postgresql.org/pub/repos/yum/srpms/13/redhat/rhel-9-x86_64/postgresql13-13.9-1PGDG.rhel9.src.rpm
on a RHEL 9 system and gotten the follow error:
rpmbuild -bb SPECS/postgresql-13.spec
warning: line 8
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 of marking the "role" GUC
> >> as GUC_REPORT.
>
> > I agree with
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 test
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 dif
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 until
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, no
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
> > 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
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
"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 w
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.
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 "m
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 w
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.
> > > https://cirrus-ci.com/github/postgresql-cfbot/postgresql/c
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
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 what
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
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 often,
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 when
> 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 t
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 w
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 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
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 shoul
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.
> > I
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 tha
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 fails
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
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 e
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 yo
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 iss
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 va
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(&xlrec, XLogRecGetData(record),
> sizeof(xl_parameter_change));
>
> + /*
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
> 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
Hi,
I just saw the following failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mylodon&dt=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 pg_re
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, w
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.
>
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 add
> 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 the
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 ap
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 would
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 fragme
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
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 summi
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
se
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
> progr
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 lim
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 reli
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 j
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 th
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 ent
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. A
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
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 d
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))
> + ret
> 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
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
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, b
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 allocati
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,
> 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 tes
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 tha
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 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 b
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 me
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
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 s
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 b
1 - 100 of 138 matches
Mail list logo
