> On 20 Feb 2022, at 02:42, Andres Freund wrote:
>
> On 2022-02-20 10:38:53 +1300, Thomas Munro wrote:
>> Back to this patch: assuming we can settle on a good-enough-for-now
>> replacement algorithm, do we want to add this set of 7 GUCs? Does
>> anyone else want to weigh in on that?
>
> I'm
On Sun, Feb 20, 2022 at 1:03 AM Yugo NAGATA wrote:
> I think we can use this macro also in hash_multirange, hash_range,
> and JsonbHashScalarValue as in the attached patch. How about replacing
> them with the macro, too.
Good find. I also found one more in hashfn.c.
On Sat, Feb 19, 2022 at 11:28
On Wed, Feb 16, 2022 at 03:43:12PM +0700, John Naylor wrote:
> On Wed, Feb 16, 2022 at 6:17 AM Peter Geoghegan wrote:
> > On Tue, Feb 15, 2022 at 9:28 AM Peter Geoghegan wrote:
>
> > > I did notice from my own testing of the failsafe (by artificially
> > > inducing wraparound failure using an XI
On Sat, Feb 19, 2022 at 8:21 PM Andres Freund wrote:
> Why does anything need to happen to it from vacuum's POV? It'll not be a
> problem for freezing etc. Until it's deleted vacuum doesn't need to care.
>
> Probably worth a WARNING, and amcheck definitely needs to detect it, but
> otherwise I
Hi,
On February 19, 2022 7:56:53 PM PST, Peter Geoghegan wrote:
>On Sat, Feb 19, 2022 at 7:47 PM Andres Freund wrote:
>> Non DEAD orphaned versions shouldn't cause a problem in lazy_scan_prune().
>> The
>> problem here is a DEAD orphaned HOT tuples, and those we should be able to
>> delete wit
On Sat, Feb 19, 2022 at 7:47 PM Andres Freund wrote:
> I'm not that sure those are that different... Imagine some corruption leading
> to two hot chains ending in the same tid, which our fancy new secure pruning
> algorithm might detect.
I suppose that's possible, but it doesn't seem all that lik
Hi,
On 2022-02-19 19:31:21 -0800, Peter Geoghegan wrote:
> On Sat, Feb 19, 2022 at 6:16 PM Peter Geoghegan wrote:
> > > Given that heap_surgery's raison d'etre is correcting corruption etc, I
> > > think
> > > it makes sense for it to do as minimal work as possible. Iterating
> > > through a
>
On Sat, Feb 19, 2022 at 7:28 PM Andres Freund wrote:
> If the vacuum can get the cleanup lock due to the adversarial patch, the
> heap_force_kill() doesn't do anything, because the first item is a
> redirect. However if it *can't* get a cleanup lock, heap_force_kill() instead
> targets the root it
On Sat, Feb 19, 2022 at 6:16 PM Peter Geoghegan wrote:
> > Given that heap_surgery's raison d'etre is correcting corruption etc, I
> > think
> > it makes sense for it to do as minimal work as possible. Iterating through a
> > HOT chain would be a problem if you e.g. tried to repair a page with HO
Hi,
On 2022-02-19 19:07:39 -0800, Peter Geoghegan wrote:
> On Sat, Feb 19, 2022 at 7:01 PM Andres Freund wrote:
> > > We can either do that, or we can throw an error concerning corruption
> > > when heap_page_prune notices orphaned tuples. Neither seems
> > > particularly appealing. But it defini
On Sat, Feb 19, 2022 at 7:01 PM Andres Freund wrote:
> It's kind of surprising that this needs this
> 0001-Add-adversarial-ConditionalLockBuff to break. I suspect it's a question
> of hint bits changing due to lazy_scan_noprune(), which then makes
> HeapTupleHeaderIsHotUpdated() have a different r
On Sat, Feb 19, 2022 at 7:01 PM Andres Freund wrote:
> > We can either do that, or we can throw an error concerning corruption
> > when heap_page_prune notices orphaned tuples. Neither seems
> > particularly appealing. But it definitely makes no sense to allow
> > lazy_scan_prune to spin in a futi
Hi,
On 2022-02-19 18:16:54 -0800, Peter Geoghegan wrote:
> On Sat, Feb 19, 2022 at 5:54 PM Andres Freund wrote:
> > How does that cause the endless loop?
>
> Attached is the page image itself, dumped via gdb (and gzip'd). This
> was on recent HEAD (commit 8f388f6f, actually), plus
> 0001-Add-adv
On Sat, Feb 19, 2022 at 5:54 PM Andres Freund wrote:
> How does that cause the endless loop?
Attached is the page image itself, dumped via gdb (and gzip'd). This
was on recent HEAD (commit 8f388f6f, actually), plus
0001-Add-adversarial-ConditionalLockBuff[...]. No other changes. No
defragmenting
Hi,
On 2022-02-19 17:22:33 -0800, Peter Geoghegan wrote:
> Looks like pg_surgery isn't processing HOT chains as whole units,
> which it really should (at least in the context of killing items via
> the heap_force_kill() function). Killing a root item in a HOT chain is
> just hazardous -- disconnec
I wrote:
> However, redirection does sound like a very easy answer ...
I tried it like that (full patch attached) and the results are
intensely disappointing. On my Mac laptop, the time needed for
50 iterations of initdb drops from 16.8 sec to 16.75 sec.
On my RHEL8 workstation, the change is act
On Sat, Feb 19, 2022 at 4:22 PM Peter Geoghegan wrote:
> This very much looks like a bug in pg_surgery itself now -- attached
> is a draft fix.
Wait, that's not it either. I jumped the gun -- this isn't sufficient
(though the patch I posted might not be a bad idea anyway).
Looks like pg_surgery
Hi,
On February 19, 2022 4:39:38 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> A quick way to prototype the moving the handlign to the backend would be to
>> just call postgres with input redirection from postgres.bki...
>
>Hmm. I was thinking of inventing an include-file command in the
>B
Andres Freund writes:
> A quick way to prototype the moving the handlign to the backend would be to
> just call postgres with input redirection from postgres.bki...
Hmm. I was thinking of inventing an include-file command in the
BKI language, and making initdb just send an INCLUDE command.
That'
Hi,
On 2022-02-19 18:35:18 -0500, Tom Lane wrote:
> Here's an initial patch that gets rid of the need for initdb to
> change the contents of postgres.bki before feeding it to the
> bootstrap backend. After this, we could look at having the
> backend read the file directly.
Cool!
> I don't reall
On Sat, Feb 19, 2022 at 3:08 PM Peter Geoghegan wrote:
> It's quite possible that this is nothing more than a bug in my
> adversarial gizmo patch -- since I don't think that
> ConditionalLockBufferForCleanup() can ever fail with a temp buffer
> (though even that's not completely clear right now).
Attached is a patch of my first pass. The to_char method isn't finished
and I need to add a bunch of tests, but everything else is in place. It
ended up being a fairly large change in case anyone wants to take a look
the changes so far.
One thing I noticed is that interval.c has a ton of code copi
Hi,
(On phone, so crappy formatting and no source access)
On February 19, 2022 3:08:41 PM PST, Peter Geoghegan wrote:
>On Fri, Feb 18, 2022 at 5:00 PM Peter Geoghegan wrote:
>> Another testing strategy occurs to me: we could stress-test the
>> implementation by simulating an environment where t
On Sat, Feb 19, 2022 at 05:41:49PM -0600, Justin Pryzby wrote:
> I rebased and fixed the check-guc script to work, made it work with vpath
> builds, and cleaned it up some.
I also meant to also attach it.
> This (and other) patches ran here.
> https://github.com/justinpryzby/postgres/runs/5261323
Forking:
On Tue, Feb 15, 2022 at 10:42:09PM -0800, Andres Freund wrote:
> >> I was thinking that we should make Utils.pm's INIT block responsible for
> >> figuring out both the directory a test should run in and the log location,
> >> instead having that in vcregress.pl and Makefile.global.in. Mo
Here's an initial patch that gets rid of the need for initdb to
change the contents of postgres.bki before feeding it to the
bootstrap backend. After this, we could look at having the
backend read the file directly.
I don't really detect any speed change from getting rid of initdb's
string manipu
On Fri, Feb 18, 2022 at 5:00 PM Peter Geoghegan wrote:
> Another testing strategy occurs to me: we could stress-test the
> implementation by simulating an environment where the no-cleanup-lock
> path is hit an unusually large number of times, possibly a fixed
> percentage of the time (like 1%, 5%)
On 2022-02-19 16:51:18 -0500, Andrew Dunstan wrote:
> I will backpatch it. That'll be a bit of fun given how much the TAP
> tests change, but I think it's worth it.
Agreed. And thanks.
On 2022-02-18 09:52:52 -0500, Robert Haas wrote:
> plus a second patch to change the occurrences above to use AC_CHECK_HEADER()
> and remove all traces of the corresponding preprocessor symbol.
LGTM. I'm not entirely sure the gssapi one is a real improvement, because we
kind of test for that bran
On 2/19/22 16:34, Andres Freund wrote:
> Hi,
>
> On 2022-02-19 13:04:05 -0500, Andrew Dunstan wrote:
>> OK, nothing broke, so here are two more invasive patches.
> Great!
>
>
>> The first
>> removes perl2host completely and adjusts all the places that use it.
>> The second removes almost all the
Hi,
On 2022-02-10 17:31:55 +0530, Bharath Rupireddy wrote:
> Secondly, remove the function ImmediateCheckpointRequested() and read
> the ckpt_flags from the CheckpointerShmem with volatile qualifier.
> This saves some LOC and cost = dirty buffers written to disk * one
> function call cost.
The co
On 2022-02-20 10:38:53 +1300, Thomas Munro wrote:
> Back to this patch: assuming we can settle on a good-enough-for-now
> replacement algorithm, do we want to add this set of 7 GUCs? Does
> anyone else want to weigh in on that?
I'm -0.2 on it, given that we have a better path forward.
On Sat, Feb 19, 2022 at 6:34 PM Andrey Borodin wrote:
> There's feature freeze approaching again. I see that you are working on
> moving SLRUs to buffer pools, but it is not clear to which PG version it will
> land. And there is 100% consensus that first patch is useful and helps to
> prevent b
Hi,
On 2022-02-19 13:04:05 -0500, Andrew Dunstan wrote:
> OK, nothing broke, so here are two more invasive patches.
Great!
> The first
> removes perl2host completely and adjusts all the places that use it.
> The second removes almost all the remaining msys special processing in
> TAP tests.
H
On Sun, Feb 20, 2022 at 6:03 AM Andres Freund wrote:
> On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> > * wal_receiver - 100ms, currently gets woken when WAL arrives
>
> This is a fairly insane one. We should compute a precise timeout based on
> wal_receiver_timeout.
I proposed a patch to do
Copying over a related thread here to have info all in one place.
It's a little fragmented so sorry about that.
On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > When formatting the output of an Interval, we call abs() on the hours
> > field of the Interval. Calli
> On 19 Feb 2022, at 14:20, Zhihong Yu wrote:
> When i was looking at the code for ExecMergeJoin(), I noticed a few places
> where the join state name in the comment doesn't match the actual state.
Given the comments on the other states, I'm bound to agree. Unless there are
objections I'll go
Joseph Koshakow writes:
> On Sat, Feb 19, 2022 at 12:00 PM Tom Lane wrote:
>> I think that messing with struct pg_tm might have too many side-effects.
>> However, pg_tm isn't all that well adapted to intervals in the first
>> place, so it'd make sense to make a new struct specifically for interva
On 2/19/22 13:04, Andrew Dunstan wrote:
> On 2/16/22 15:46, Andrew Dunstan wrote:
>> Largely following a recipe from Andres, I have migrated buildfarm
>> animals fairywren and jacana to a setup that shouldn't need (and in fact
>> won't be able to use) PostgreSQL::Test:Utils::perl2host(). AFAICT t
On Sat, Feb 19, 2022 at 12:00 PM Tom Lane wrote:
> I think that messing with struct pg_tm might have too many side-effects.
> However, pg_tm isn't all that well adapted to intervals in the first
> place, so it'd make sense to make a new struct specifically for interval
> decoding.
Yeah that's a g
Yugo NAGATA writes:
> For avoiding undefined behaviours, maybe it is better to use unsigned
> int and bit mask as a following code in Linux does[1][2], though it
> would be unnecessary if they are used properly as in the current
> PostgreSQL code.
I don't think that's an improvement. It would m
On 2/16/22 15:46, Andrew Dunstan wrote:
> Largely following a recipe from Andres, I have migrated buildfarm
> animals fairywren and jacana to a setup that shouldn't need (and in fact
> won't be able to use) PostgreSQL::Test:Utils::perl2host(). AFAICT these
> two are the only buildfarm animals that
On Sat, 19 Feb 2022 20:07:58 +0700
John Naylor wrote:
> We've accumulated a few bit-twiddling hacks to get the compiler to
> emit a rotate instruction. Since we have a macro for that, let's use
> it, as in the attached. I thought the new call sites would look better
> with a "left" version, so I
On Sat, Feb 19, 2022 at 9:37 AM Andres Freund wrote:
> IMO the type of information you'd want for apply failures is substantially
>
different enough from worker failures that I don't really see the temptation
> to put them in the same table.
>
>
It's an error message and a transaction LSN in both
Hi,
On 2022-02-19 14:10:39 +, Simon Riggs wrote:
> Some years ago we did a pass through the various worker processes to
> add hibernation as a mechanism to reduce power consumption on an idle
> server. Replication never got the memo, so power consumption on an
> idle server is not very effecti
Joseph Koshakow writes:
> On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
>> I wonder if the most reasonable fix would be to start using int64
>> instead of int arithmetic for the values that are potentially large.
>> I doubt that we'd be taking much of a performance hit on modern
>> hardware.
On Fri, Feb 18, 2022 at 11:44 PM Tom Lane wrote:
>
> Joseph Koshakow writes:
> > When formatting the output of an Interval, we call abs() on the hours
> > field of the Interval. Calling abs(INT_MIN) returns back INT_MIN
> > causing the output to contain two '-' characters. The attached patch
> >
Hi,
On 2022-02-19 09:16:40 -0700, David G. Johnston wrote:
> On Sat, Feb 19, 2022 at 9:02 AM Andres Freund wrote:
> > Even leaving everything else aside, a key of (dboid, subid, subrelid),
> > where
> > subrelid can be NULL, but where (dboid, subid) is *not* unique, imo is poor
> > relational des
John Naylor writes:
> We've accumulated a few bit-twiddling hacks to get the compiler to
> emit a rotate instruction. Since we have a macro for that, let's use
> it, as in the attached. I thought the new call sites would look better
> with a "left" version, so I added a new macro for that. That's
Hi,
On 2022-02-19 02:00:28 +, Mark Wong wrote:
> On Fri, Feb 18, 2022 at 02:41:04PM -0800, Andres Freund wrote:
> > There's snapper ("pgbf [ a t ] twiska.com"), and there's Mark Wong's large
> > menagerie. Mark said yesterday that he's working on updating.
>
> I've made one pass. Hopefully I
On Sat, Feb 19, 2022 at 9:02 AM Andres Freund wrote:
>
> Even leaving everything else aside, a key of (dboid, subid, subrelid),
> where
> subrelid can be NULL, but where (dboid, subid) is *not* unique, imo is poor
> relational design. What is the justification for mixing relation specific
> and
v21 rebased with compile errors fixed is attached.
v21-0008-small-comment-correction.patch
Description: Binary data
v21-0007-Remove-superfluous-bgwriter-stats-code.patch
Description: Binary data
v21-0004-Send-IO-operations-to-stats-collector.patch
Description: Binary data
v21-0005-Add-buffe
Hi,
On 2022-02-19 22:38:19 +0900, Masahiko Sawada wrote:
> On Sat, Feb 19, 2022 at 5:32 AM Andres Freund wrote:
> > On 2022-02-18 17:26:04 +0900, Masahiko Sawada wrote:
> > > With this change, pg_stat_subscription_workers will be like:
> > >
> > > * subid
> > > * subname
> > > * subrelid
> > > *
Some years ago we did a pass through the various worker processes to
add hibernation as a mechanism to reduce power consumption on an idle
server. Replication never got the memo, so power consumption on an
idle server is not very effective on standby or logical subscribers.
The code and timing for
On Sat, Feb 19, 2022 at 4:47 AM David G. Johnston
wrote:
>
> On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada wrote:
>>
>>
>> Here is the summary of the discussion, changes, and plan.
>>
>> 1. Move some error information such as the error message to a new
>> system catalog, pg_subscription_error.
On 2/18/22 17:34, Andrew Dunstan wrote:
> On 2/17/22 12:12, Andres Freund wrote:
>> Hi,
>>
>> On 2022-02-17 09:20:56 -0500, Andrew Dunstan wrote:
>>> I don't think we have or have ever had a buildfarm animal targeting
>>> msys. In general I think of msys as a build environment to create native
>>
On Sat, Feb 19, 2022 at 10:37 PM Amit Kapila wrote:
>
> On Sat, Feb 19, 2022 at 6:51 PM David G. Johnston
> wrote:
> >
> > On Saturday, February 19, 2022, Amit Kapila wrote:
> >>
> >> On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston
> >> wrote:
> >> >
> >> > On Fri, Feb 18, 2022 at 1:26 AM Mas
On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston
wrote:
>
> On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada wrote:
>>
>> 5. Record skipped data to the system catalog, say
>> pg_subscription_conflict_history so that there is a chance to analyze
>> and recover.
>
>
>> We can discuss the
>> details
On Sat, Feb 19, 2022 at 5:32 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-02-18 17:26:04 +0900, Masahiko Sawada wrote:
> > With this change, pg_stat_subscription_workers will be like:
> >
> > * subid
> > * subname
> > * subrelid
> > * error_count
> > * last_error_timestamp
>
> > This view will be e
On Sat, Feb 19, 2022 at 6:51 PM David G. Johnston
wrote:
>
> On Saturday, February 19, 2022, Amit Kapila wrote:
>>
>> On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston
>> wrote:
>> >
>> > On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada
>> > wrote:
>> >>
>> >>
>> >> Here is the summary of the d
On Saturday, February 19, 2022, Amit Kapila wrote:
> On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston
> wrote:
> >
> > On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada
> wrote:
> >>
> >>
> >> Here is the summary of the discussion, changes, and plan.
> >>
> >> 1. Move some error information such
Hi,
When i was looking at the code for ExecMergeJoin(), I noticed a few places
where the join state name in the comment doesn't match the actual state.
Here is a small patch with correction.
Cheers
merge-join-state-doc.patch
Description: Binary data
We've accumulated a few bit-twiddling hacks to get the compiler to
emit a rotate instruction. Since we have a macro for that, let's use
it, as in the attached. I thought the new call sites would look better
with a "left" version, so I added a new macro for that. That's not
necessary, however.
Some
On Sat, Feb 19, 2022 at 1:17 AM David G. Johnston
wrote:
>
> On Fri, Feb 18, 2022 at 1:26 AM Masahiko Sawada wrote:
>>
>>
>> Here is the summary of the discussion, changes, and plan.
>>
>> 1. Move some error information such as the error message to a new
>> system catalog, pg_subscription_error.
64 matches
Mail list logo