Sigh. And now there's a patch conflict in a regression test expected
output: sysviews.out
Please rebase. Incidentally, make sure to check the expected output is
actually correct. It's easy to "fix" an expected output to
accidentally just memorialize an incorrect output.
Btw, it's the last week be
FYI this has a compiler warning showing up on the cfbot:
[13:19:51.544] pg_stat_statements.c: In function ‘entry_reset’:
[13:19:51.544] pg_stat_statements.c:2598:32: error:
‘minmax_stats_reset’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
[13:19:51.544] 2598 | entry->m
So far I've been moving patches with failing tests to Waiting on
Author but there are a number with "minor" failures or failures which
look unrelated to the patch. There are 20 patches with at least one
failing test in Ready for Comitter (2) and Needs Review (18).
Here's a summary of the reasons f
On Thu, 31 Mar 2022 at 16:05, Greg Stark wrote:
>
> I haven't wrapped my head around multixacts yet. It's complicated by
> this same codepath being used for truncates of regular tables that
> were created in the same transaction.
So my best idea so far is to actually speci
The tests for this seem to need adjustments.
[12:41:09.403] test pg_stat_statements ... FAILED 180 ms
diff -U3
/tmp/cirrus-ci-build/contrib/pg_stat_statements/expected/pg_stat_statements.out
/tmp/cirrus-ci-build/contrib/pg_stat_statements/results/pg_stat_statements.out
---
/tmp/cirrus-ci-build/
This patch was broken by d16773cdc86210493a2874cb0cf93f3883fcda73 "Add
macros in hash and btree AMs to get the special area of their pages"
If it's really just a few macros it should be easy enough to merge but
it would be good to do a rebase given the number of other commits
since February anyway
One patch is failing with what looks like a generic Cirrus issue:
https://cirrus-ci.com/task/5389918250729472
Failed to start an instance: INVALID_ARGUMENT: Operation with name
"operation-1648936682461-5dbb2fd37177b-5095285b-b153ee83" failed with
status = HttpJsonStatusCode{statusCode=INVALID_ARG
Hm. It compiles but it's failing regression tests:
diff -U3 /tmp/cirrus-ci-build/contrib/dummy_toaster/expected/dummy_toaster.out
/tmp/cirrus-ci-build/contrib/dummy_toaster/results/dummy_toaster.out
--- /tmp/cirrus-ci-build/contrib/dummy_toaster/expected/dummy_toaster.out
2022-04-02 16:02:47.87436
Is this a problem with the patch or its tests?
[18:14:20.798] # poll_query_until timed out executing this query:
[18:14:20.798] # SELECT count(1) = 0 FROM pg_subscription_rel WHERE
srsubstate NOT IN ('r', 's');
[18:14:20.798] # expecting this output:
[18:14:20.798] # t
[18:14:20.798] # last actual
The cfbot is failing testing this patch. It seems... unlikely given
the nature of the patch modifying an admin function that doesn't even
modify the database that it should be breaking a streaming test.
Perhaps the streaming test is using this function in the testing
scaffolding?
[03:19:29.564] #
Just reposting the previous patches to straighten out the cfbot.
--- /usr/lib/python3/dist-packages/patroni/postgresql/__init__.py 2022-02-18 13:16:15.0 +
+++ __init__.py 2022-04-03 19:17:29.952665383 +
@@ -798,7 +798,8 @@
return True
def get_guc_value(self, name):
-
Are we missing regression tests using these functions as window functions?
Hm. I suppose it's possible to write a general purpose regression test
that loops over all aggregate functions and runs them as window
functions and aggregates over the same data sets and compares results.
At least for the
Thanks for the review Robert. I think that gives some pretty
actionable advice on how to improve the patch and it doesn't seem
likely to get much more in this cycle.
I'll mark the patch Returned with Feedback. Hope to see it come back
with improvements in the next release.
handler somewhere? I don't think
so but it does feel weird to be touching it and also doing the same
thing elsewhere.
I think this has addressed all the questions now.
From 2e5d2c47288d27a620af09214c82fd66f61fb605 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Thu, 31 Mar 2022 15:48:38 -0
This is failing regression tests. I don't understand how this patch
could be affecting this test though. Perhaps it's a problem with the
json patches that were committed recently -- but they don't seem to be
causing other patches to fail.
diff -U3 /tmp/cirrus-ci-build/src/test/regress/expected/js
This is not passing regression tests due to some details of the plan
output - marking Waiting on Author:
diff -w -U3 c:/cirrus/src/test/regress/expected/partition_prune.out
c:/cirrus/src/test/recovery/tmp_check/results/partition_prune.out
--- c:/cirrus/src/test/regress/expected/partition_prune.out
I've never tried to review a 24-patch series before. It's kind of
intimidating Is there a good place to start to get a good idea of
the most important changes?
On Wed, 6 Apr 2022 at 10:29, Robert Haas wrote:
>
> I think that the paper shows that, under the right set of
> circumstances, a timing-based attack is possible here.
Generally any argument that an attack is infeasible is risky and
usually leads to security professionals showing that surprisingly
The commitfest ends with the feature freeze in less than 48 hours.
I'm going to start moving patches that are Waiting On Author and
haven't received comment in more than a few days out of the
commitfset. If the patch has received a review or good feedback then
I'll mark it Returned With Feedback.
On Wed, 6 Apr 2022 at 13:50, Tom Lane wrote:
>
> when I want to see some related parameters, or when I'm a bit
> fuzzy on the exact name of the parameter. Not only is this
> a lot of typing, but unless I'm willing to type even more to
> avoid using "*", I'll get a wall of mostly unreadable text,
I won't touch the Ready for Committer stuff until after the end of the
commitfest anyways. I did put those two in that state already.
Right now I'm trying to get a bit ahead of the game by going through
the "Waiting on Author" patches. The documented process[*] is that
they get Returned with Feedb
On Wed, 6 Apr 2022 at 21:59, Julien Rouhaud wrote:
>
>
> FWIW I think that this 5 days threshold before closing a patch with RwF is way
> too short. As far as I know we usually use something like 2/3 weeks.
Yeah, I haven't been enforcing a timeout like that during the
commitfest. But now that we
It looks like this patch got feedback from Andres and Robert with some
significant design change recommendations. I'm marking the patch
Returned with Feedback. Feel free to add it back to a future
commitfest when a new version is ready.
On Thu, 7 Apr 2022 at 22:32, Robert Haas wrote:
>
> On Thu, Apr 7, 2022 at 7:41 PM Tom Lane wrote:
>
> > Possibly a better idea is to add an enum argument telling the function
> > what to do (parse the whole thing as one name regardless of dots,
> > parse as two names if there's a dot, throw erro
It has reached 2022-03-08 Anywhere on Earth[*] so I believe that means
Postgres 15 Feature Freeze is in effect (modulo a couple patches that
were held until the end of the commitfest to make merging easier).
I've marked the commitfest closed and will be moving any patches that
didn't receive feedb
On Sun, 27 Feb 2022 at 07:09, Jille Timmermans wrote:
>
> Hi,
>
> First time PostgreSQL contributor here :)
I wish I had noticed this patch during the CF. It seems like a nice
self-contained feature that could have been easily reviewed and
committed and it's always good to see first-time contribu
On Thu, 9 Dec 2021 at 23:36, Tom Lane wrote:
>
> I'm not for dropping support for some platform just because it's old.
I guess I'll have to spin up the Vax again :)
I moved to next CF almost all the Needs Review and Waiting on Author patches.
The remaining ones are either:
1) Bug fixes, Documentation, or testing patches that we may want to
make Open Issues
2) Patches that look like we may want to mark Rejected or Returned
with Feedback and start a new discu
On Fri, 8 Apr 2022 at 11:30, Robert Haas wrote:
>
> On Fri, Apr 8, 2022 at 10:12 AM Greg Stark wrote:
> > On Thu, 9 Dec 2021 at 23:36, Tom Lane wrote:
> > > I'm not for dropping support for some platform just because it's old.
> >
> > I guess I'l
These remaining CF entries look like they're bugs that are maybe Open
Issues for release?
* fix spinlock contention in LogwrtResult
* Avoid erroring out when unable to remove or parse logical rewrite
files to save checkpoint work
* Add checkpoint and redo LSN to LogCheckpointEnd log message
* s
On Sat, 9 Apr 2022 at 06:44, Alvaro Herrera wrote:
>
> > * Simplify some RI checks to reduce SPI overhead
>
> Move to next; a lot more work is required.
If it's going to be part of a much larger patch set I wonder if it
shouldn't just be marked Rejected and start a new thread and new CF
entry for
On Sat, 9 Apr 2022 at 10:51, Tom Lane wrote:
>
> > Sound like bugfixes to be backpatched.
>
> Yeah. I'm not sure why these have received so little love.
Since bug fixes are important enough that they'll definitely get done
(and can happen after feature freeze) there's a bit of a perverse
incenti
The readdir interface allows processes to be in the middle of reading
a directory and unless a kernel was happy to either materialize the
entire directory list when the readdir starts, or lock the entire
directory against modification for the entire time the a process has a
readdir fd open it's alw
> >
> > On Fri, 1 Apr 2022 11:09:16 -0400
> > Greg Stark wrote:
> >
> > > This patch has bitrotted due to some other patch affecting trigger.c.
> > >
> > > Could you post a rebase?
> > >
> > > This is the last week of the CF before
On Thu, 20 Jan 2022 at 17:01, Peter Geoghegan wrote:
>
> Then there's the fact that you
> really cannot think about the rate of XID consumption intuitively --
> it has at best a weak, unpredictable relationship with anything that
> users can understand, such as data stored or wall clock time.
Thi
On Thu, 6 Jan 2022 at 14:56, Tomas Vondra wrote:
>
>
> Not sure I understand. I wasn't suggesting any user-defined filtering,
> but something done by default, similarly to what we do for regular MCV
> lists, based on frequency. We'd include frequent paths while excluding
> rare ones.
>
> So no nee
On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
>
> In my view, previous efforts in this area have been too simplistic.
>
One thing I've been wanting to do something about is I think
autovacuum needs to be a little cleverer about when *not* to vacuum a
table because it won't do any good.
I've s
On Wed, 26 Jan 2022 at 18:46, Greg Stark wrote:
>
> On Thu, 20 Jan 2022 at 14:31, Robert Haas wrote:
> >
> > In my view, previous efforts in this area have been too simplistic.
> >
>
> One thing I've been wanting to do something about is I think
> autovacu
So I looked at this patch and I have the same basic question as Bruce.
Do we really want to expose every binary tool associated with Postgres
as an extension? Obviously this is tempting for cloud provider users
which is not an unreasonable argument. But it does have consequences.
1) Some things li
1) I would like an interface which more or less guarantees that
*every* parameter of the log message is included in the structured
data. Ideally there should be no actual need to generate the formatted
messages for destinations like elastic search, just record the message
id and the parameters.
To
Additionally I've looked at the tests and I'm not sure but I don't
think this arrangement is going to work. I don't have the time to run
CLOBBER_CACHE and CLOBBER_CACHE_ALWAYS tests but I know they run
*really* slowly. So the test can't just do a CHECKPOINT and then trust
that the next few transact
I gave two reviews and received one review but the patches have been
"Moved to next CF". Should I update them to "Returned with Feedback"
given they all did get feedback? I was under the impression "Moved to
next CF" was only for patches that didn't get feedback in a CF and
were still waiting for f
On Thu, 3 Feb 2022 at 12:21, Robert Haas wrote:
>
> VACUUM's first pass over the heap is implemented by a function called
> lazy_scan_heap(), while the second pass is implemented by a function
> called lazy_vacuum_heap_rel(). This seems to imply that the first pass
> is primarily an examination of
On Wed, 15 Dec 2021 at 15:30, Peter Geoghegan wrote:
>
> My emphasis here has been on making non-aggressive VACUUMs *always*
> advance relfrozenxid, outside of certain obvious edge cases. And so
> with all the patches applied, up to and including the opportunistic
> freezing patch, every autovacuu
Unless I'm misreading this code I think the nevents in
WaitLatchOrSocket should really be 4 not 3. At least there are 4 calls
to AddWaitEventToSet in it and I think it's possible to trigger all 4.
I guess it's based on knowing that nobody would actually set
WL_EXIT_ON_PM_DEATH and WL_POSTMASTER_DE
So I've been dealing a lot with building and maintaining dashboards
for (fleets of) Postgres servers. And it's a pain. I have a few
strongly held ideas about where the pain points are and what the right
ways to tackle them are. Some of which are going to be controversial I
think...
The state of th
On Tue, 15 Feb 2022 at 16:43, Magnus Hagander wrote:
>
> On Tue, Feb 15, 2022 at 1:30 PM Dave Page wrote:
> >
> > - Does it really matter if metrics are exposed on a separate port from the
> > postmaster? I actually think doing that is a good thing as it allows use of
> > alternative listen add
On Tue, 15 Feb 2022 at 22:48, Stephan Doliov wrote:
>
> I am curious what you mean by standard metrics format? I am all for
> standards-based but what are those in the case of DBs. For environments where
> O11y matters a lot, I think the challenge lies in mapping specific query
> executions bac
On Tue, 15 Feb 2022 at 17:37, Magnus Hagander wrote:
>
> On Tue, Feb 15, 2022 at 11:24 PM Greg Stark wrote:
> >
> > On Tue, 15 Feb 2022 at 16:43, Magnus Hagander wrote:
>
> I really don't see the problem with having the monitoring on a different port.
>
> I
So I think it's kind of cute that you've implemented these as agnostic
wrappers that work with any allocator ... but why?
I would have expected the functionality to just be added directly to
the allocator to explicitly request whole aligned pages which IIRC
it's already capable of doing but just d
So I guess I don't have much to add since I don't really understand
the Param infrastructure, certainly not any better than you seem to.
I do note that the code in question was added in this commit in 2010.
That predates the addition of LATERAL in 2013. I suppose those
comments may be talking abou
Fwiw tuplesort does do something like what you want for the top-k
case. At least it used to last I looked -- not sure if it went out
with the tapesort ...
For top-k it inserts new tuples into the heap data structure and then
pops the top element out of the hash. That keeps a fixed number of
elemen
I think the idea of being able to request an autovacuum worker for a
specific table is actually very good. I think it's what most users
actually want when they are running vacuum. In fact in previous jobs
people have built infrastructure that basically duplicates autovacuum
just so they could do th
On Sat, 19 Nov 2022 at 14:10, Tom Lane wrote:
> Under what circumstances would it be appropriate for a script to take
> it on itself to decide that? It has no way of knowing what the next -f
> option is or what the user intended.
Presumably when they're written by the same person so the script d
On Thu, 17 Nov 2022 at 14:56, Robert Haas wrote:
>
> Having a switch for one particular kind of error (out of many that
> could possibly occur) that triggers one particular coping strategy
> (out of many that could possibly be used) seems far too specific a
> thing to add as a core feature. And ev
On Mon, 21 Nov 2022 at 15:01, Andres Freund wrote:
>
> It's somewhat sad to add this restriction - I've used get_raw_page() (+
> other functions) to scan a whole database for a bug. IIRC that actually
> did end up using parallelism, albeit likely not very efficiently.
>
> Don't really have a bette
On Tue, 22 Nov 2022 at 08:17, Ashutosh Bapat
wrote:
>
> AFAIU, binary compatibility of two postgresql servers depends upon the
> binary compatibility of the platforms on which they run.
No, libpq binary mode is not architecture-specific. I think you're
thinking of on-disk binary compatibility. Bu
On Mon, 28 Nov 2022 at 13:00, Robert Haas wrote:
>
> On Tue, Nov 22, 2022 at 3:53 PM Andres Freund wrote:
> I vote to just remove them. I think that most people won't update
> their queries until they are forced to do so. I don't think it
> matters very much when we force them to do that.
I wo
On Fri, 25 Nov 2022 at 20:03, David Zhang wrote:
>
> Hi Bruce,
>
> Thank you for helping review the patches in such detail.
>
> On 2022-11-25 9:48 a.m., Bruce Momjian wrote:
>
> Looking at the patch, I am unclear how the the patch prevents concurrent
> duplicate value insertion during the partitio
On Mon, 28 Nov 2022 at 16:53, Peter Geoghegan wrote:
>
> Imagine if we actually had 64-bit XIDs -- let's assume for a moment
> that it's a done deal. This raises a somewhat awkward question: do you
> just let the system get further and further behind on freezing,
> forever? We can all agree that
On Tue, 29 Nov 2022 at 21:16, Tom Lane wrote:
>
> I actually think that that problem should be soluble with a
> slightly different approach. The thing that feels insoluble
> is that you can't do this without acquiring sufficient locks
> to prevent addition of new partitions while the insertion is
On Sat, 5 Nov 2022 at 11:34, Tom Lane wrote:
>
> Greg Stark writes:
> > Simple Rebase
>
> I took a little bit of a look through these.
>
> * I find 0001 a bit scary, specifically that it's decided it's
> okay to apply extract_autovac_opts, pgstat_fetc
On Thu, 1 Dec 2022 at 14:18, Andres Freund wrote:
>
> Hi,
>
> On 2022-12-01 11:13:01 -0500, Greg Stark wrote:
> > On Sat, 5 Nov 2022 at 11:34, Tom Lane wrote:
> >
> > > * I find 0001 a bit scary, specifically that it's decided it'
So I talked about this patch with Ronan Dunklau and he had a good
question Why are we maintaining relfrozenxid and relminmxid in
pg_class for temporary tables at all? Autovacuum can't use them and
other sessions won't care about them. The only session that might care
about them is the one a
On Tue, 6 Dec 2022 at 13:59, Andres Freund wrote:
>
> Hi,
>
> On 2022-12-06 13:47:39 -0500, Greg Stark wrote:
> > So I talked about this patch with Ronan Dunklau and he had a good
> > question Why are we maintaining relfrozenxid and relminmxid in
> > pg_cla
On Thu, 1 Dec 2022 at 14:18, Andres Freund wrote:
>
> I find it problematic that ResetVacStats() bypasses tableam. Normal vacuums
> etc go through tableam but you put a ResetVacStats() besides each call to
> table_relation_nontransactional_truncate(). Seems like this should just be in
> heapam_re
> On Tue, Apr 27, 2021 at 7:08 PM Bharath Rupireddy
> Make sense, we would lose the ability to differentiate temporary
> tables from the auto_explain logs.
There's no useful differentiation that can be done with the temp
schema name. They're assigned on connection start randomly from the
pool of
On Mon, 3 May 2021 at 15:44, Tom Lane wrote:
>
> Alvaro Herrera writes:
> > I also heard a story where things ran into trouble (I didn't get the
> > whole story of *what* was the problem with that) because the datadir is /.
>
> BTW, as far as that goes, I think the general recommendation is that
On Fri, 9 Apr 2021 at 16:58, Tomas Vondra wrote:
>
>
>
> On 4/9/21 7:33 PM, James Coleman wrote:
> > A specific area where this is particularly painful is btree index reads.
> > Walking the tree to leaf pages isn't naturally prefetchable, and so for
> > each level you pay the random page cost. Of
On Thu, 19 Jan 2023 at 00:45, Andrey Borodin wrote:
> But..do we have to treat any unknown start sequence of bytes as a TLS
> connection? Or is there some definite subset of possible first bytes
> that clearly indicates that this is a TLS connection or not?
Absolutely not, there's only one Messa
-+--+---+---+---
48797 | t | TLSv1.3 | TLS_AES_256_GCM_SHA384 | 256 | |
|
(1 row)
--
greg
From 4508f872720a0977cf00041a865d76a4d5f77028 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Wed, 18 Jan 2023 15:34:34 -0500
Subject: [P
This is how we've always documented it. Postgres treats code points as
"characters" not graphemes.
You don't need to go to anything as esoteric as emojis to see this either.
Accented characters like é have no canonical forms that are multiple code
points and in some character sets some accented ch
On Fri, 20 Jan 2023 at 01:41, Vladimir Sitnikov
wrote:
>
> Do you think the server can de-support the old code path soon?
I don't have any intention to de-support anything. I really only
picture it being an option in environments where the client and server
are all part of a stack controlled by a
On Fri, 20 Jan 2023 at 00:07, Pavel Stehule wrote:
>
> I partially watch an progres in VTE - one of the widely used terminal libs,
> and I am very sceptical so there will be support in the next two years.
>
> Maybe the new microsoft terminal will give this area a new dynamic, but
> currently onl
On Sat, 21 Jan 2023 at 13:17, Tom Lane wrote:
>
> Probably our long-term answer is to avoid depending on wcwidth
> and use wcswidth instead. But it's hard to get excited about
> doing the legwork for that until popular libc implementations
> get it right.
Here's an interesting blog post about tr
I actually find it kind of annoying that we use hex strings for a lot
of things where they don't add any value. Namely Transaction ID and
LSNs. As a result it's always a bit of a pain to ingest these in other
tools or do arithmetic on them. Neither is referring to memory or
anything where powers of
that's a pre-existing possibility just more likely (if it's possible at
all) by frequent truncates.
On Thu, Feb 2, 2023, 15:47 Alvaro Herrera wrote:
> On 2022-Dec-13, Greg Stark wrote:
>
> > So here I've done it that way. It is a bit of an unfortunate laye
Is anyone else itching to be CF manager for March? If anyone new wants
to try it out that would be good.
Assuming otherwise I'll volunteer.
--
greg
On Tue, 21 Feb 2023 at 12:29, Tom Lane wrote:
>
> Greg Stark writes:
> > Is anyone else itching to be CF manager for March? If anyone new wants
> > to try it out that would be good.
>
> > Assuming otherwise I'll volunteer.
>
> We've generally thought
Fwiw I'm going through some patches looking for patches to review And
I'm finding that the patches I'm seeing actually did get reviews, some of
them months ago.
If there was any substantial feedback since the last patch was posted I
would say you should change the status to Waiting on Author w
On Tue, 1 Nov 2022 at 06:56, Michael Paquier wrote:
> Two people showing up to help is really great, thanks! I'll be around
> as well this month, so I'll do my share of patches, as usual.
Fwiw I can help as well -- starting next week. I can't do much this week though.
I would suggest starting
On Sun, 8 Nov 2020 at 18:19, Greg Stark wrote:
>
> We had an outage caused by transaction wraparound. And yes, one of the
> first things I did on this site was check that we didn't have any
> databases that were in danger of wraparound.
Fwiw this patch has been in "Read
> 3. It's probably cheaper perform the HAS_ZERO check just once on (half1
| half2). We have to compute (half1 | half2) anyway.
Wouldn't you have to check (half1 & half2) ?
I haven't looked at the surrounding code. Are we processing all the
COPY data in one long stream or processing each field individually? If
we're processing much more than 128 bits and happy to detect NUL
errors only at the end after wasting some work then you could hoist
that has_zero check entirel
I think Andres's point earlier is the one that stands out the most for me:
> I still think that's the most reasonable course. I actually like the
> feature, but I don't think a better implementation of it would share
> much if any of the current infrastructure.
That makes me wonder whether rippin
On Thu, 17 Jun 2021 at 23:49, Noah Misch wrote:
>
> On Wed, Jun 16, 2021 at 12:00:57PM -0400, Tom Lane wrote:
> > I agree that's a great use-case. I don't like this implementation though.
> > I think if you want to set things up like that, you should draw a line
> > between the tables it's okay f
Fwiw, yes it could be a cosmic ray.
It could also just be marginally bad ram. Bad ram is notoriously hard
to reliably test for. It can be very sensitive to the exact bit
pattern stored in it, the timing of reads and writes, and other
factors. The whole point of the rowhammer attacks is to push som
On Tue, 31 May 2022 at 12:00, Vladimir Sitnikov
wrote:
>
> Please, do not suggest me avoid 65535 parameters. What I wanted was just to
> test that the driver was able to handle 65535 parameters.
I don't think we have regression tests to cover things at these
limits, that might be worth adding if
Recently I had someone complaining about a pg_restore failure and I
believe we semi-regularly get complaints that are similar -- though
I'm having trouble searching for them because the keywords "dump
restore failure" are pretty generic.
The root cause here -- and I believe for a lot of users -- a
On Wed, 8 Jun 2022 at 19:39, Mark Dilger wrote:
>
>
> I like the general idea, but I'm confused why you are limiting the analysis
> to search path resolution. The following is clearly wrong, but not for that
> reason:
>
> create function public.identity () returns double precision as $$
> sel
to think about how to reduce the pain for
users upgrading...
Perhaps we should automatically fix up the current search patch and
attach it to functions where necessary for users instead of just
whingeing at them
From 5cfccb714e7d9fd8f623700701e960abd54af25c Mon Sep 17 00:00:00 2001
From: Greg S
On Mon, 13 Jun 2022 at 16:50, Greg Stark wrote:
>
> For that matter the gotchas are a bit convoluted
>
> Perhaps we should automatically fix up the current search patch and
> attach it to functions where necessary for users instead of just
> whingeing at them
On Wed, 15 Jun 2022 at 11:54, Tom Lane wrote:
>
> Yeah, that is sort of the inverse problem. I think those are there
> to ensure that the text appears on a fresh line even if the current
> line has transient status on it. We could get rid of those perhaps
> if we teach pg_log_v to remember wheth
On Thu, 16 Jun 2022 at 12:04, Greg Stark wrote:
>
> Providing a fixed up search_path for users would give them a smoother
> upgrade process where we can give a warning only if the search_path is
> changed substantively which is much less likely.
>
> I'm still quite concerne
Simple Rebase
From 8dfed1a64308a84cc15679e09af69ca6989b608b Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Thu, 31 Mar 2022 15:50:02 -0400
Subject: [PATCH v7 3/3] Add test for truncating temp tables advancing
relfrozenxid
This test depends on other transactions not running at the same time
so
Please add this to the commitfest at
https://commitfest.postgresql.org/38/ so it doesn't get missed. The
commitfest starts imminently so best add it today.
> - -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50)
> + -> Parallel Seq Scan on tenk1 (actual rows=1960.00
At the not inconsiderable risk of bike-shedding
I'm wondering if printing something like 0.00 will be somewhat
deceptive when the real value is no
On Thu, 7 Jul 2022 at 22:36, Thomas Munro wrote:
>
> * Since Greg Stark's magnificent Vax talk[1], we became even more
> dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone
> produces a software IEEE math implementation for GCC/VAX... if I had
> a pick one to bump off that list,
On Sat, 9 Jul 2022 at 21:46, Thomas Munro wrote:
>
> Hello,
>
> I wonder how much dead code for ancient operating systems we could now
> drop.
> 0002-Remove-dead-getrusage-replacement-code.patch
I thought the getrusage replacement code was for Windows. Does
getrusage on Windows actually do anyth
(Reading the patch it seems both those points are already addressed)
201 - 300 of 356 matches
Mail list logo
