On Sat, 11 May 2024 at 15:36, AJ ONeal wrote:
> Having postgres TLS/SNI/ALPN routable by default will just be more intuitive
> (it's what I assumed would have been the default anyway), and help increase
> adoption in cloud, enterprise, and other settings.
Routing is primarily a feature for
When I was CFM for a couple cycles I started with the idea that I was going
to try being a hardass and rejecting or RWF all the patches that had gotten
negative reviews and been bounced forward.
Except when I actually went through them I didn't find many. Mostly like
Robert I found perfectly
On Fri, 26 May 2023 at 19:22, Jeff Davis wrote:
>
> Maintenance commands (ANALYZE, CLUSTER, REFRESH MATERIALIZED VIEW,
> REINDEX, and VACUUM) currently run as the table owner, and as a
> SECURITY_RESTRICTED_OPERATION.
>
> I propose that we also fix the search_path to "pg_catalog, pg_temp"
> when
On Wed, 7 Jun 2023 at 18:09, Andres Freund wrote:
> Having the same memory mapping between threads makes allows the
> hardware to share the TLB (on x86 via process context identifiers), which
> isn't realistically possible with different processes.
As a matter of historical interest Solaris
On Mon, 5 Jun 2023 at 10:52, Heikki Linnakangas wrote:
>
> I spoke with some folks at PGCon about making PostgreSQL multi-threaded,
> so that the whole server runs in a single process, with multiple
> threads. It has been discussed many times in the past, last thread on
> pgsql-hackers was back
On Mon, May 22, 2023, 12:31 Peter Geoghegan wrote:
> On Sun, May 21, 2023 at 11:51 PM Heikki Linnakangas
> wrote:
> > Any idea what might cause this corruption?
>
> Not really, no. As far as I know the specific case that was brought to
> my attention (that put me on the path to writing this
On Sat, 13 May 2023 at 09:46, Tom Lane wrote:
>
> Andrew Dunstan writes:
> > I could see an argument for a STRICT mode which would disallow partially
> > quoted fields, although I'd like some evidence that we're dealing with a
> > real problem here. Is there really a CSV producer that produces
On Thu, 11 May 2023 at 16:41, Peter Geoghegan wrote:
>
> > I say "exhaustion" or "overload" are meaningless because their meaning
> > is entirely dependent on context. It's not like memory exhaustion or
> > i/o overload where it's a finite resource and it's just the sheer
> > amount in use that
On Thu, 11 May 2023 at 10:04, Joel Jacobson wrote:
>
> The parser currently accepts quoting within an unquoted field. This can lead
> to
> data misinterpretation when the quote is part of the field data (e.g.,
> for inches, like in the example).
I think you're thinking about it differently than
On Thu, 11 May 2023 at 05:37, Peter Eisentraut
wrote:
>
> Maybe it was never meant that way and only works accidentally? Maybe
> hash indexes are broken?
It's explicitly documented to be this way. And I think it has to work
this way for recovery to work.
I think the reason you and Bharath and
On Wed, 3 May 2023 at 18:50, Peter Geoghegan wrote:
>
> What about "XID allocation overload"? The implication that I'm going
> for here is that the system was misconfigured, or there was otherwise
> some kind of imbalance between XID supply and demand.
Fwiw while "wraparound" has pitfalls I
Including the pre-truncation length in the wal record is the obviously
solid approach and I none of the below is a good substitution for it.
But
On Tue, 25 Apr 2023 at 13:30, Andres Freund wrote:
>
> It isn't - but the alternatives aren't great either. It's not that easy to hit
> this
On Mon, 17 Apr 2023 at 16:22, Tom Lane wrote:
>
> I tend to agree with the proposition that we aren't going to add new
> message types very often, as long as we're careful to make them general
> purpose. Don't forget that adding a new message type isn't just a matter
> of writing some spec text
On Mon, 17 Apr 2023 at 17:45, Thomas Munro wrote:
>
> Reasons: (1) There will always be a
> few file systems that refuse O_DIRECT (Linux tmpfs is one such, as we
> learned in this thread; if fails with EINVAL at open() time), and
So why wouldn't we just automatically turn it off (globally or for
Hm, in an optimized build using kernel perf I see this. But I don't
know how to find what the call sites are for LWLockAcquire/Release. If
it's the locks on pgproc that would be kind of bad.
I wonder if I should be gathering horizons once in the
PrecommitActions and then just using those for
r change actually does what it
> intends to. Possibly the test needs to be relaxed some, but I do think we want
> tests for the change.
>
> Greetings,
>
> Andres Freund
--
greg
From 8dc1dc9d50e08c63d25a9c4c3e860453fbd9e531 Mon Sep 17 00:00:00 2001
From: Greg Stark
Da
On Fri, 14 Apr 2023 at 13:15, Laurenz Albe wrote:
>
> On Fri, 2023-04-14 at 18:43 +0200, Alvaro Herrera wrote:
> > On 2023-Apr-14, Greg Stark wrote:
> > > I assume people would use hot_standby_feedback if they have streaming
> > > replication.
> >
> &
On Wed, 11 May 2022 at 06:19, Peter Eisentraut
wrote:
>
> After that, these configure options don't have an equivalent yet:
>
> --enable-profiling
Afaics this still doesn't exist? Is there a common idiom to enable
this? Like, if I add in something to cflags is that enough? I seem to
recall we
On Fri, 14 Apr 2023 at 09:47, Jonathan S. Katz wrote:
>
> Let me restate [1] in a different way.
>
> Using a large enough dataset, I did qualitatively look at overall usage
> of both "vacuum_defer_cleanup_age" and compared to
> "hot_standby_feedback", given you can use both to accomplish similar
On Thu, 13 Apr 2023 at 13:01, Peter Geoghegan wrote:
>
> On Thu, Apr 13, 2023 at 9:45 AM Robert Haas wrote:
> >
> > On Wed, Apr 12, 2023 at 4:23 PM Greg Stark wrote:
> > > Am I crazy or is the parenthetical comment there exactly backwards? If
> > > the horizo
On Wed, Apr 12, 2023, 19:30 Daniel Gustafsson wrote:
>
> The issue we have is that we cannot get PGconn in
> verify_cb so logging an error is tricky.
Hm, the man page talks about a "ex_data mechanism" which seems to be
referring to this Rube Goldberg device
On Wed, 5 Apr 2023 at 13:42, Andres Freund wrote:
>
> ISTM that the problem here really is that you're relying on RecentXmin, rather
> than computing something more accurate. Why not use
> GetOldestNonRemovableTransactionId(rel) - It's a bit more expensive, but I
> don't think it'll matter
On Wed, 12 Apr 2023 at 11:02, Robert Haas wrote:
>
> I mostly just wanted to say that I disagreed with Tom about the
> particular point on postmaster.pid, without really expressing an
> opinion about anything else.
I don't object to using the pid file as the mechanism -- but it is a
bit of an
On Fri, 17 Feb 2023 at 15:38, Tom Lane wrote:
>
> Hmm, so Stephen was opining that the extension's objects shouldn't
> have gotten these privs attached in the first place. I'm not
> quite convinced about that one way or the other, but if you buy it
> then maybe this situation is unreachable once
So here's the list of CF entries that I thought *might* still get
committed either because they're an Open Issue or they're one of those
other categories. I had intended to go through and add them all to the
Open Issues but it turns out I only feel confident in a couple of them
qualifying for
On Wed, 22 Feb 2023 at 13:38, Kirk Wolak wrote:
>
> I already requested ONLY the HH24 format. 8 characters of output. no
> options. It's a waste of time.
> After all these years, sqlplus still has only one setting (show it, or not).
> I am asking the same here.
> And I will gladly defend
So here we are at the end of the CF:
Status summary: March 15March 22March 28April 4 April 8
Needs review: 152 128 116 96 74
Waiting on Author: 42 36 30 21 14
Ready for Committer: 39 32
As announced on this list feature freeze is at 00:00 April 8 AoE.
That's less than 24 hours away. If you need to set your watches to AoE
timezone it's currently:
$ TZ=AOE+12 date
Fri 07 Apr 2023 02:05:50 AM AOE
As we stand we have:
Status summary:
Needs review: 82
Waiting on
On Wed, 5 Apr 2023 at 13:42, Andres Freund wrote:
>
> Not if you determine a relation specific xmin, and the relation is not a
> shared relation.
>
> ISTM that the problem here really is that you're relying on RecentXmin, rather
> than computing something more accurate. Why not use
>
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
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
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
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
So on the one hand, I don't think the plan is to actually commit the
tests. They're very specific to
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 this should
> get closed out as committed.
I'm not super
On Mon, 30 Jan 2023 at 18:31, Nathan Bossart wrote:
>
> My colleague Jeremy Schneider (CC'd) was recently looking into usage count
> distributions for various workloads, and he mentioned that it would be nice
> to have an easy way to do $SUBJECT. I've attached a patch that adds a
>
On Sun, 2 Apr 2023 at 11:38, Tom Lane wrote:
>
> Even if all that infrastructure sprang into existence, is this really any
> more useful than basing your switching on the host's resolved IP address?
> I'm doubtful that there's enough win there to justify pushing this rock
> to the top of the
And the cfbot wants a small tweak
From 3d0a502c25504da32b7a362831c700b4e891f79b Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Fri, 31 Mar 2023 02:31:31 -0400
Subject: [PATCH v6 5/6] Allow pipelining data after ssl request
---
src/backend/postmaster/postmaster.c | 54
On Mon, 20 Mar 2023 at 16:31, Greg Stark wrote:
>
> Here's a first cut at ALPN support.
>
> Currently it's using a hard coded "Postgres/3.0" protocol
Apparently that is explicitly disrecommended by the IETF folk. They
want something like "TBD" so people don't star
On Thu, 23 Mar 2023 at 23:30, Bharath Rupireddy
wrote:
>
> > + ereport(log_replication_commands ? LOG : DEBUG3,
> > + (errmsg("acquired physical replication slot \"%s\"",
> > + slotname)));
So this is just a bit of bike-shedding but I don't feel like these log
messages really meet the standard
So of the patches with no emails since August-December 2022:
* New hooks in the connection path
* Add log messages when replication slots become active and inactive
- Peter Smith and Alvaro Herrera have picked up this one
* Remove dead macro exec_subplan_get_plan
- Minor cleanup
* Consider
On Thu, 27 Oct 2022 at 07:10, Simon Riggs wrote:
>
> In the past, developers have wondered how we can provide "--dry-run"
> functionality
That would be an awesome functionality, indeed. I have concerns of how
feasible it is in general but I think providing features to allow
developers to build
So a week later
Status summary: March 15March 22
Needs review: 152 128
Waiting on Author: 42 36
Ready for Committer: 39 32
Committed: 61 82
Moved to next CF: 4 15
Withdrawn: 17
The CFBot says there's a function be_gssapi_get_proxy() which is
undefined. Presumably this is a missing #ifdef or a definition that
should be outside an #ifdef.
[14:05:21.532] dblink.c: In function ‘dblink_security_check’:
[14:05:21.532] dblink.c:2606:38: error: implicit declaration of
function
On Tue, 21 Mar 2023 at 05:59, Alvaro Herrera wrote:
>
> On 2023-Mar-20, Thomas Munro wrote:
>
> This led me to suggesting that perhaps we need to be more lenient when
> it comes to new contributors. As I said, for seasoned contributors,
> it's not a problem to keep up with our requirements,
So back in 2002 in 7.3 there was a commit 2c6b34d9598 which added a
GUC db_user_namespace which is stored in a variable Db_user_namespace.
All that seems fine except...
The variable this GUC is stored in is Db_user_namespace which... is
actually declared in pqcomm.h which is intended to be
Sorry, checking the cfbot apparently I had a typo in the #ifndef USE_SSL case.
From 4b6e01c7f569a919d660cd80ce64cb913bc9f220 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023 14:09:30 -0400
Subject: [PATCH v4 4/4] alpn support
---
src/backend/libpq/be-secure-openssl.c| 65
free() that I missed in the
client before). They still have the semi-open issues I mentioned in
the previous email.
--
greg
From 32185020927824c4b57af900100a37f92ae6a040 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023 14:09:30 -0400
Subject: [PATCH v3 4/4] alpn support
---
src/bac
On Mon, 20 Mar 2023 at 16:08, Thomas Munro wrote:
>
> On Tue, Mar 21, 2023 at 3:15 AM Greg Stark wrote:
> > The next level of this would be something like notifying the committer
> > with a list of patches in the CF that a commit broke. I don't
> > immediately see how to
ON_ERROR_STOP_SHELL which
stops only on shell errors, rather than, say, ON_ERROR_STOP_SQL to do
the converse which would at least match the historical behaviour?
From 1f0feb9daf106721cb7fcba39ef7d663178f8ed1 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Mon, 20 Mar 2023 14:25:22 -0400
Subject: [PATCH
The next level of this would be something like notifying the committer
with a list of patches in the CF that a commit broke. I don't
immediately see how to integrate that with our workflow but I have
seen something like this work well in a previous job. When committing
code you often went and
On Fri, 17 Mar 2023 at 10:39, Tom Lane wrote:
>
> You've listed a lot of small features here that still have time to
> get some love --- it's not like we're hard up against the end of the CF.
> If they'd been in Waiting on Author state for awhile, I'd agree with
> booting them, but not when
On Wed, 15 Mar 2023 at 14:29, Gregory Stark (as CFM)
wrote:
>
> These patches that are "Needs Review" and have received no comments at
> all since before March 1st are these. If your patch is amongst this
> list I would suggest any of:
>
> 1) Move it yourself to the next CF (or withdraw it)
> 2)
gssencmode and sslmode results in a
counter-intuitive behaviour. But I don't see a better option that
doesn't mean making the defaults less useful.
From b07e19223bee52b7bb9b50afea39e4baaa0a46f3 Mon Sep 17 00:00:00 2001
From: Greg Stark
Date: Thu, 16 Mar 2023 15:10:15 -0400
Subject: [PATCH v2 3/3
I notice a number of places in fe-connect.c have copied this idiom
where if an option is present they validate the legal options and
otherwise they strdup a default value. This strdup of the default
option I think is being copied from sslmode's validation which is a
bit special but afaics the
On Tue, 17 Jan 2023 at 14:52, Tomas Vondra
wrote:
>
> On 1/17/23 19:46, Andres Freund wrote:
>
> > I think a "hybrid" explain mode might be worth thinking about. Use the
> > "current" sampling method for the first execution of a node, and for the
> > first
> > few milliseconds of a query (or
On Tue, 14 Mar 2023 at 13:59, Tom Lane wrote:
>
> "Gregory Stark (as CFM)" writes:
> > It looks like this needs a big rebase in fea-uth.c fe-auth-scram.c and
> > fe-connect.c. Every hunk is failing which perhaps means the code
> > you're patching has been moved or refactored?
>
> The cfbot is
On Tue, 28 Feb 2023 at 05:13, Kartyshov Ivan wrote:
>
> Below I provide the implementation of patches for the first three types.
> I propose to discuss this feature again/
Oof, that doesn't really work with the cfbot. It tries to apply all
three patches and of course the second and third fail to
So I'm not sure if I'll be CFM this month but I'm assuming I will be
at this point
Regardless, Commitfest 2023-03 starts tomorrow!
So this is a good time to check your submitted patches and ensure
they're actually in building and don't need a rebase. Take a look at
http://cfbot.cputube.org/
On Wed, 22 Feb 2023 at 07:27, Heikki Linnakangas wrote:
>
> On 20/01/2023 03:28, Jacob Champion wrote:
> > On Wed, Jan 18, 2023 at 7:16 PM Greg Stark wrote:
> >> * "Service Mesh" type tools that hide multiple services behind a
> >> single host/por
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 that the m
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
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 layering
> &
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
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
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
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
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
HA384 | 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: [PATCH v1] Direct SSL Connections
---
src/backend/libpq/be-secure.c | 13 +++
src/backen
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
I had a conversation a while back with Heikki where he expressed that
it was annoying that we negotiate SSL/TLS the way we do since it
introduces an extra round trip. Aside from the performance
optimization I think accepting standard TLS connections would open the
door to a number of other
> You do have to lock a table in order to update its pg_class row,
> though, whether the table is temporary or not. Otherwise, another
> session could drop it while you're doing something with it, after
> which bad things would happen.
I was responding to this from Andres:
> Is that actually
On Sat, 5 Nov 2022 at 15: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_fetch_stat_tab
On Wed, 7 Dec 2022 at 22:02, Greg Stark wrote:
> > Seems like this should just be in
> > heapam_relation_nontransactional_truncate()?
So here I've done it that way. It is a bit of an unfortunate layering
since it means the heapam_handler is doing the catalog change but it
does seem
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
>
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
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
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's
> &g
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_fetch_stat_tab
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
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 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
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
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.
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
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
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
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
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
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
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
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 "Ready for
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
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
On Fri, 16 Sept 2022 at 10:27, Tom Lane wrote:
>
> Simon Riggs writes:
> > A user asked me whether we prune never visible changes, such as
> > BEGIN;
> > INSERT...
> > UPDATE.. (same row)
> > COMMIT;
>
> Didn't we just have this discussion in another thread?
Well. not "just" :)
commit
On Tue, 23 Aug 2022 at 11:00, Dave Page wrote:
>
> Often it is beneficial to review one's schema with a view to removing indexes
> (and sometimes tables) that are no longer required. It's very difficult to
> understand when that is the case by looking at the number of scans of a
> relation as,
Having this function would be great (I admit I never responded because
I never figured out if your suggestion was right or not:). But should
it also be added to the pg_stat_activity view? Perhaps even just in
the SQL view using the function.
Alternately should pg_stat_activity show the actual
On Thu, 18 Aug 2022 at 02:27, Drouvot, Bertrand wrote:
>
> What I had in mind is to provide an API to retrieve stats for those that
> would need to connect to each database individually otherwise.
>
> That's why I focused on PGSTAT_KIND_RELATION that has
>
On Tue, 16 Aug 2022 at 08:49, Drouvot, Bertrand wrote:
>
>
> + if (p->key.kind != PGSTAT_KIND_RELATION)
> + continue;
Hm. So presumably this needs to be extended. Either to let the caller
decide which types of stats to return or to somehow return all the
stats
On Thu, 11 Aug 2022 at 02:11, Drouvot, Bertrand wrote:
>
> As Andres was not -1 about that idea (as it should be low cost to add
> and maintain) as long as somebody cares enough to write something: then
> I'll give it a try and submit a patch for it.
I agree it would be a useful feature. I think
1 - 100 of 350 matches
Mail list logo
