- it is called a Hot Standby server. See for
+ it is called a hot standby server. See for
more information.
A standby server can also be used for read-only queries, in which case
- it is called a Hot Standby server. See for
+ it is called a hot standby server. See
for
more information.
Robert Treat
https://xzilla.net
o be changed and I think I mentioned that in an >>earlier
> >>Email. Are you suggesting to change all at once? I wanted to start with the
> >>documentation and then continue with the other >>places.
>
> >Attached a new version which also modifies am
idn't fail if the specified schema didn't exist. That's arguably
> preferable, but that's the pre-existing behavior for tables. So I think the
> behavior of my patch is more consistent.
>
> +1
>
+1 for consistency.
Robert Treat
https://xzilla.net
nce would be more grammatically correct
if the word "which" was replaced with "that", ie. PostgreSQL provides
a set of default roles /that/ provide access to certain, commonly
needed, privileged capabilities and information.
Robert Treat
https://xzilla.net
stment to existing worker delay adjust
> mechanisms in autovac_balance_cost() and signalling the autovacuum
> backend to run the adjustment every few seconds once we are in the danger
> zone.
>
That patch certainly looks interesting; many many times I've had to
have people kick off manual vacuums to use more i/o and kill the
wrap-around vacuum. Reading the discussion there, I wonder if we
should think about weighting the most urgent vacuum at the expense of
other potential autovacuums, although I feel like they often come in
bunches in these scenarios.
Robert Treat
https://xzilla.net
ntly
> across code comments.
>
Heh, that's interesting, as I would have said that CreateCheckpoint is
the right casing vs CreateCheckPoint, but it looks like it has always
been the other way (according to
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f0e37a85319e6c113ecd33
behavior modifying changes
such as the recent WITH ... MATERIALIZED change. Thoughts?
Robert Treat
https://xzilla.net
ond paragraph, an argument they are non-existent, which doesn't
seem right either; so how do we explain to people how to measure the
overhead for them?
Robert Treat
https://xzilla.net
subscriber. Attached is a patch that attempts to clarify this, and
provides some additional wordsmithing of that section. Patch is
against head but the nature of the patch would apply to the docs for
11 and 10, which both have the incorrect information as well, even if
the patch itself does not.
Robert T
On Mon, Apr 8, 2019 at 7:19 PM Euler Taveira wrote:
>
> Em seg, 8 de abr de 2019 às 19:38, Robert Treat escreveu:
> >
> > I noticed that the docs currently state "A different order of columns
> > in the target table is allowed, but the column types have to match.&qu
got me looking at this was the idea of returning -1
(or maybe null) for checksum failures for cases when checksums are not
enabled. This seems a little more complicated to set up, but seems
like it might ward off people thinking they are safe due to no
checksum error reports when they actually aren't.
Robert Treat
https://xzilla.net
On Mon, Apr 15, 2019 at 3:32 PM Julien Rouhaud wrote:
>
> Sorry for late reply,
>
> On Sun, Apr 14, 2019 at 7:12 PM Magnus Hagander wrote:
> >
> > On Sat, Apr 13, 2019 at 8:46 PM Robert Treat wrote:
> >>
> >> On Fri, Apr 12, 2019 at 8:18 AM Magnus Hag
On Wed, Apr 17, 2019 at 9:07 AM Julien Rouhaud wrote:
>
> On Wed, Apr 17, 2019 at 1:55 PM Magnus Hagander wrote:
> >
> > On Tue, Apr 16, 2019 at 5:39 PM Robert Treat wrote:
> >>
> >> On Mon, Apr 15, 2019 at 3:32 PM Julien Rouhaud wrote:
> >> >
&g
On Thu, Mar 14, 2024 at 8:21 AM Daniel Gustafsson wrote:
>
> > On 14 Mar 2024, at 02:47, Robert Treat wrote:
>
> > I was taking a look at the login event triggers work (nice work btw)
>
> Thanks for reviewing committed code, that's something which doesn't
On Thu, Mar 14, 2024 at 7:23 PM Daniel Gustafsson wrote:
>
> > On 14 Mar 2024, at 14:21, Robert Treat wrote:
> > On Thu, Mar 14, 2024 at 8:21 AM Daniel Gustafsson wrote:
>
> >> - canceling connection in psql wouldn't
> >> cancel
> >
On Thu, Mar 14, 2024 at 12:15 PM Ashutosh Bapat
wrote:
>
> Hi Robert,
>
> On Thu, Mar 7, 2024 at 10:49 PM Robert Treat wrote:
>>
>> This patch adds a link to the "attach partition" command section
>> (similar to the detach partition link above it) as wel
safe wrt not breaking existing tooling (like
5/6 might do)
Looking at it, you could make the argument that #4 is actually the
best of the solutions proposed, except it has the one drawback that it
requires folks to double down on the fiction that we think extensions
are a good way to build solutions when really everyone just wants to
have everything in core.
Robert Treat
https://xzilla.net
On Tue, Mar 19, 2024 at 3:08 AM Ashutosh Bapat
wrote:
>
> Hi Robert,
>
>
> On Mon, Mar 18, 2024 at 10:52 PM Robert Treat wrote:
>>
>> On Thu, Mar 14, 2024 at 12:15 PM Ashutosh Bapat
>> wrote:
>> >
>> > Hi Robert,
>> >
>> >
; way".
>
>
>>
>> zero_damaged_pages=on in postgresql.conf and silently remove vast
>> quantities of data without knowing that they're doing anything. We
>> don't even question that stuff ... although we probably should be
>
>
> I like how you got this far and didn't even mention fsync=off :)
>
And yet somehow query hints are more scary than ALL of these things. Go figure!
Robert Treat
https://xzilla.net
On Thu, Mar 21, 2024 at 7:27 AM Ashutosh Bapat
wrote:
> On Wed, Mar 20, 2024 at 5:22 PM Ashutosh Bapat
> wrote:
>> On Tue, Mar 19, 2024 at 6:38 PM Robert Treat wrote:
>>>
>>>
>>> I've put it in the next commitfest with target version
On Mon, Mar 25, 2024 at 6:43 AM Ashutosh Bapat
wrote:
> On Fri, Mar 22, 2024 at 10:58 PM Robert Treat wrote:
>> v5 patch attached which I think further improves clarity/brevity of
>> this section. I've left the patch name the same for simplicity, but
>> I'd agr
eone interested in moving this
> forward?
>
> Thanks!
>
Hey Andrey,
I spoke with Karl briefly on this and he is working on getting an
updated patch together. The work now involves incorporating feedback
and some rebasing, but hopefully we will see something in the next few
days.
Robert Treat
https://xzilla.net
ok. But it makes sense to
> not have a separate paragraph in the source code too. Thanks for fixing it. I
> think the intention of the current code as well as the patch is to have a
> single paragraph in HTML output, same as "no-extra-para" output.
>
It does seem like the source and the html output ought to match, so +1 from me.
Robert Treat
https://xzilla.net
we had that process), so ISTM that it's not completely
avoidable...
That said, are you suggesting that the feature freeze deadline be
random, and also held in secret by the RMT, only to be announced after
the freeze time has passed? This feels weird, but might apply enough
deadline related pressure while avoiding last minute shenanigans.
Robert Treat
https://xzilla.net
e's also a couple of wordsmiths in nearby areas to improve
readability.
Robert Treat
https://xzilla.net
improve-partition-links.patch
Description: Binary data
27;t really find a spot to add in your additional info, but
maybe you can find a spot that fits? Or maybe a well written
walk-through of this would make for a good wiki page in case people
really want to dig in.
In any case, I think Roberto's original language is an improvement
over what we have now, so I'd probably recommend just going with that,
along with a similar note to max_prepared_xacts, and optionally a
pointer to the shared mem section of the docs.
Robert Treat
https://xzilla.net
it is hard to imagine we'd always have access to
the log files to figure this out on any actively running systems.
Robert Treat
https://xzilla.net
e
12.4-2 for postgres 12.4 patchlevel 2).
BTW, as a reminder, we do have this statement, in bold, in the
"upgrading" section of the versioning page:
"We always recommend that all users run the latest available minor
release for whatever major version is in use." Ther
I was taking a look at the login event triggers work (nice work btw)
and saw a couple of minor items that I thought would be worth cleaning
up. This is mostly just clarifying the exiting docs and code comments.
Robert Treat
https://xzilla.net
login_event_trigger_small_cleanups.patch
Description
On Mon, Sep 5, 2022 at 2:04 PM Justin Pryzby wrote:
>
> On Thu, Aug 04, 2022 at 01:45:49AM -0400, Robert Treat wrote:
> > After reading this again, it isn't clear to me that this advice would
> > be more appropriately placed into Section 5.11, aka
> > https://www.po
'd be nice for users to have an easy way to
guesstimate % of frozen tables (like live vs dead tuples in
pg_stat_all_tables), but this seems difficult to maintain accurately.
Had a similar thing with tracking clock time of vacuums; just keeping
the duration of the last vacuum ended up being insufficient for some
cases, so we ended up tracking it historically... we haven't quite yet
designed a pg_stat_vacuums a la pg_stat_statements, but it has crossed
our minds.
Robert Treat
https://xzilla.net
it on another thread.
>
While I agree on the above points, IMHO I don't believe it should be a
show-stopper for adding this functionality to v15, but we have a few
more commitments before we get to that point.
Robert Treat
https://xzilla.net
irectly in *the* locked rows"
>
> I think the mention of multixacts should link to
> . Again, I would not
> specifically mention the directory, since it is already described in
> "storage.sgml", but I have no strong optinion there.
>
> > +
> > +
> > + Subtransactions
>
> > +The word subtransaction is often abbreviated as
> > +subxact.
>
> I'd use , not .
>
> > +If a subtransaction is assigned a non-virtual transaction ID,
> > +its transaction ID is referred to as a subxid.
>
> Again, I would use , since we don't "subxid"
> elsewhere.
>
> + Up to
> +64 open subxids are cached in shared memory for each backend; after
> +that point, the overhead increases significantly since we must look
> +up subxid entries in pg_subtrans.
>
> Comma before "since". Perhaps you should mention that this means disk I/O.
>
ISTR that you only use a comma before since in cases where the
preceding thought contains a negative.
In any case, are you thinking something like this:
" 64 open subxids are cached in shared memory for each backend; after
that point the overhead increases significantly due to additional disk I/O
from looking up subxid entries in pg_subtrans."
Robert Treat
https://xzilla.net
itional info about the network at
https://www.oftc.net
Robert Treat
PostgreSQL Project SPI Liaison
https://xzilla.net
On Wed, Jan 11, 2023 at 4:13 PM Robert Haas wrote:
> On Wed, Jan 11, 2023 at 10:48 AM Robert Treat wrote:
> > > @Robert: I wonder why shouldn't CREATE..PARTITION OF *also* be patched
> > > to first create a table, and then attach the partition, transparently
> >
;This means that any changes within subtransactions of the named
savepoint will be subcommitted and those subtransactions will be
destroyed."
Robert Treat
https://xzilla.net
scan is
now populated with a special value :-(
I think the simplest fix which should correspond to existing versions
behavior would be to just ensure that we replace any "special value"
timestamps with a real transaction timestamp, and then maybe note that
these fields may be advanced by operations which don't strictly show
up as a sequential or index scan.
Robert Treat
https://xzilla.net
getting
started hacking Postgres:
http://blog.cleverelephant.ca/2022/10/postgresql-links.html
* I suspect you may have seen these, but in case not, the wiki has
several key pages to be aware of, which are linked to from
https://wiki.postgresql.org/wiki/Development_information
Robert Treat
https://xzilla.net
On Mon, Oct 24, 2022 at 11:02 AM Simon Riggs
wrote:
>
> On Sun, 16 Oct 2022 at 02:08, Bruce Momjian wrote:
> >
> > On Fri, Oct 14, 2022 at 05:46:55PM -0400, Robert Treat wrote:
> > > On Fri, Oct 14, 2022 at 3:51 PM Bruce Momjian wrote:
> > > > Attached
efer to this piece of software which is
> kept in the Postgres repository but can be optionally installed. pageinspect
> (possibly with the URL) is clear enough. However, if you don't like the
> shorthand, 'pageinspect extension' or 'pageinspect module' are good options.
>
+1 on this line of thinking from my pov.
Robert Treat
https://xzilla.net
Howdy folks,
The attached patch tweaks the wording around finding the psqlrc file
on windows, with the primary goal of removing the generally incorrect
statement that windows has no concept of a home directory.
Robert Treat
https://xzilla.net
windows-psqlrc.patch
Description: Binary data
e.
> > I don't necessarily object to rewriting these sentences more broadly,
> > but I don't think "have issued" is the correct phrasing.
> >
> > Possibly "The user issued ..." would work.
> >
Is there a reason that the first case says "just" issued vs the other
two cases? It seems to me that it should be removed.
Robert Treat
https://xzilla.net
well.
After reading this again, it isn't clear to me that this advice would
be more appropriately placed into Section 5.11, aka
https://www.postgresql.org/docs/current/ddl-partitioning.html, but in
lieu of a specific suggestion for where to place it there (I haven't
settled on one yet), IMHO, I think the first sentence of the suggested
change should be rewritten as:
Note that creating a partition using PARTITION OF
requires taking an ACCESS EXCLUSIVE lock on the parent table.
It may be preferable to first CREATE a separate table...
Robert Treat
https://xzilla.net
On Thu, Aug 4, 2022 at 10:32 AM Daniel Gustafsson wrote:
> > On 4 Aug 2022, at 00:44, Junwang Zhao wrote:
>
> > Attachment is a patch with the "just" removed.
>
> I think this is a change for better, so I've pushed it. Thanks for the
> contribution!
>
>
Thanks!
Robert Treat
https://xzilla.net
column
name change as well, so maybe that's enough for folks to figure things
out? At least I couldn't find anywhere in the docs where we have
described the relationship between these columns before. Thoughts?
Robert Treat
https://xzilla.net
ar gear) would be near
trivial though, just a matter of figuring out where/how to host it
(but I think infra can chime in on that if that's what get's decided).
The other likely option would be to seek out cloud credits from one of
the big three (or others); Amazon has continually said they would be
happy to donate more credits to us if we had a use, and I think some
of the other hosting providers have said similarly at times; so we'd
need to ask and hope it's not too bureaucratic.
Robert Treat
https://xzilla.net
ons for details."
Use of 'for' twice is grammatically incorrect; I am partial to "please
see the release notes from earlier versions for details." but could
also see "please see the release notes for earlier versions to get
details."
Robert Treat
https://xzilla.net
tion in my mind was if we should add a
similar note to the original patch to max_prepared_xacts as well; do
you intend to do that?
Robert Treat
https://xzilla.net
On Wed, May 15, 2024 at 4:05 PM Robert Haas wrote:
>
> On Wed, May 15, 2024 at 4:00 PM Robert Treat wrote:
> > I think the only unresolved question in my mind was if we should add a
> > similar note to the original patch to max_prepared_xacts as well; do
> > you intend
nch or beta release there's a non-numeric "minor release".
> > I'm inclined to go ahead and do it like that.
>
> I decided that what I found jarring about that was the use of "release
> number" with a non-numeric version, so I changed it to "release
> identifier" and pushed.
>
Looks good. Thanks Tom / Julien.
Robert Treat
https://xzilla.net
d_xacts view.
+
Transactions that are currently prepared can be inspected using the
pg_prepated_xacts view.
* I thought the hyphenated wording looked odd, though I understand why
you used it. We don't use it elsewhere though (just `currently
prepared` san hyphen) so re-worded to match the other wording.
Robert Treat
https://xzilla.net
eir configs. Also, presumaing I'm unerstanding
it's purpose correctly, ISTM it would fit along side other trace_*
gucs in
https://www.postgresql.org/docs/current/runtime-config-developer.html#RUNTIME-CONFIG-DEVELOPER.
Robert Treat
https://xzilla.net
On Sun, Aug 4, 2024 at 4:45 AM Heikki Linnakangas wrote:
> On 04/08/2024 06:29, Robert Treat wrote:
> > I was looking at trace_connection_negotiation and ran across this
> > commit removing it's mention from the release notes because it is
> > undocumented:
> > h
On Sun, Jun 23, 2019 at 1:25 PM Peter Eisentraut
wrote:
>
> On 2019-04-12 19:52, Robert Treat wrote:
> > It is clear to me that the docs are wrong, but I don't see anything
> > inherently incorrect about the code itself. Do you have suggestions
> > for how you would
; with \d+ we list various "Partition
X:" sections, perhaps adding one for "Partition triggers:" would be
enough, although I am inclined to think it needs exposure at the \d
level. One other thing to consider is firing order of said triggers...
if all parent level triggers fire before child level triggers then the
above separation is straightforward, but if the execution order is, as
I suspect, mixed, then it becomes more complicated.
Robert Treat
http://xzilla.net
idity of just manually updating indisvalid as a
means for determining if an index could be safely removed (for the
record, I did not recommend it ;-)
DBA's are often willing to weedwhacker at things in SQL when the
alternative is to learn C.
Robert Treat
http://xzilla.net
On Mon, Jan 6, 2025 at 3:18 AM Masahiro Ikeda wrote:
>
> On 2025-01-03 01:25, Robert Treat wrote:
> > On Tue, Dec 3, 2024 at 3:13 AM Masahiro Ikeda
> > wrote:
> >>
> >> Hi,
> >>
> >> The documentation seems to overlook the rewrit
patch is at this point and if you are still thinking of
committing it for v18?
Robert Treat
https://xzilla.net
day of raw data" and say one year of data aggregated by day (average,
> maximum,
> minimum , standard deviation and maybe some percentiles) could be fine too.
>
While I'm sure some people are ok with it, I would say that most of
the observability/metrics community has moved away from aggregated
data storage towards raw time series data in tools like prometheus,
tsdb, and timescale in order to avoid the problems that misleading /
lossy / low-resolution data can create.
Robert Treat
https://xzilla.net
the
> counters are simply in LVRelState, mixed with all kinds of other info,
> and it seems "not great" to pass it to a "log" hook, and (b) there are
> some calculated values, so I guess the hook would need to do that
> calculation on it's own, and it'd be ea
27;t really need a year's history) but that seems like plenty
for a default.
> But maybe it'd be possible to just write the entries to a file. We don't
> need random access to past entries (unlike e.g. pg_stat_statements), and
> people won't query that very often either.
>
Yeah, workloads will vary, but it doesn't seem like they would more
than query workloads do.
Robert Treat
https://xzilla.net
t the cleanup lock?
>
I feel like if we are making the trade-off in resources to attempt
eager scanning, and we weren't making progress for whatever reason
(and in the lock failure cases, wouldn't some of those be things that
would prevent us from freezing?) then it would generally be ok to bias
towards bailing sooner rather than later.
Robert Treat
https://xzilla.net
put will be less
> informative than IO to most...
>
> I still wonder if we instead ought to create a top-level "IO" section instead
> of leaving it under "Resource Usage". How many IOs we combine, how
> aggressively we flush unflushed data, etc only kinda fits into the resource
> usage category.
>
+1 from me, though I did pause on whether it should be called
"background workers" rather than "worker processes", but I think this
is the right direction.
Robert Treat
https://xzilla.net
else
> - ereport(INFO,
> - (errmsg("vacuuming \"%s.%s.%s\"",
> - vacrel->dbname,
> vacrel->relnamespace,
> - vacrel->relname)));
> - }
> + ereport(INFO,
> + (errmsg("%s of \"%s.%s.%s\"",
> +
> vac_eagerness_description(vacrel->eagerness),
> + vacrel->dbname,
> vacrel->relnamespace,
> + vacrel->relname)));
>
> /*
>* Allocate dead_items memory using dead_items_alloc. This handles
One thing I am wondering about is that since we actually modify
vacrel->eagerness during the "success downgrade" cycle, a single
vacuum run could potentially produce messages with both eager vacuum
and normal vacuum language. I don't think that'd be a problem in the
above spot, but wondering if it might be elsewhere (maybe in
pg_stat_activity?).
Robert Treat
https://xzilla.net
eans that up a bit and
tweaks the link to alter table replica status.
Robert Treat
https://xzilla.net
v3-0001-Expand-and-clarify-Replica-Identity-information.patch
Description: Binary data
er map than 100million rows in
a n number of tables of unknown (but presumably greater than
500million?) numbers of rows of unknown sizes. And again, we have a
means to tackle these bloat cases already; lowering
vacuum_scale_factor.
This isn't to say the system is perfect; I do think there are some
fundamental issues that need addressing, but adding this guc just
feels a little less baked than usual.
Robert Treat
https://xzilla.net
On Thu, Jan 9, 2025 at 2:46 AM Peter Smith wrote:
>
> On Sat, Jan 4, 2025 at 4:23 AM Robert Treat wrote:
> >
> > On Wed, Dec 18, 2024 at 5:56 AM Amit Kapila wrote:
> > >
> > > On Thu, Feb 8, 2024 at 9:57 AM Laurenz Albe
> > > wrote:
> > &
On Tue, Jan 21, 2025 at 6:36 PM Jim Jones wrote:
> On 21.01.25 23:45, Robert Treat wrote:
> > Is there some concrete use case you have seen that this would help
> > with? Not objecting to adding it, but you've mentioned this migration
> > idea twice but it seems to me
On Wed, Jan 22, 2025 at 8:02 AM Shinya Kato
wrote:
>
> Hi, thank you for the reviews.
>
> On 2025-01-18 00:45, Robert Treat wrote:
> > This looks pretty good to me. I think there are a couple of minor
> > grammar changes that could be made, and I think the pg_dumpall
o eager scan, but I wondered about the "region_size +1"
scenario; essentially cases where we are not very much larger in total
than a single region, where it also feels like there isn't much gain
from eager scanning. Perhaps we should wait until 2x region size, in
which case we'd at least start in a scenario where the bucketing is
more equal?
Robert Treat
https://xzilla.net
ful information to have if you are trying to
discern changes in i/o rate during a vacuum, or trying to tune the
failure rate setting, or several other related fields (including
automated capture by tools like pganalyze), so I believe INFO is the
right choice for this.
Robert Treat
https://xzilla.net
her than what the intentions of the code are. For example, I
like the "freeze horizon" language vs explicit FreezeLimit since the
code could change even if the goal doesn't. But in lue of going back
to that wording (modulo your 1 line explanation in your email), if I
were to attempt to split the difference:
We only want to
enable eager scanning if we are likely to be able to freeze some of
the pages in the relation, which is unlikely if FreezeLimit has not
advanced past
relfrozenxid or if MultiXactCutoff has not advanced passed
relminmxid. Granted, there may be pages we didn't try to freeze
before, or some previously blocking XID greater than FreezeLimit may
have now ended (allowing for freezing), but as a heuristic we wait
until the
FreezeLimit advances to increase our chances of successful freezing.
Robert Treat
https://xzilla.net
case (no
pun intended), SQL folks probably don't care much about that
discrepancy, but given xml is case sensitive, maybe xml people do?
Robert Treat
https://xzilla.net
pretty useful information to have if you are trying to
> > discern changes in i/o rate during a vacuum, or trying to tune the
> > failure rate setting, or several other related fields (including
> > automated capture by tools like pganalyze), so I believe INFO is the
> > right choice for this.
>
> I'm happy to go either way. I don't want users mad about verbosity, but if
> they
> think it's helpful, then that seems good.
>
If there is a configurable, people will want to tune it, and DEBUG
level messages aren't a usable solution.
Robert Treat
https://xzilla.net
on
idea twice but it seems to me this doesn't conform with existing
implementations, and I don't see much benefit in migration use cases
specifically, so I'm just curious if I am overlooking something?
Robert Treat
https://xzilla.net
On Mon, Jan 13, 2025 at 3:55 AM Amit Kapila wrote:
> On Mon, Jan 13, 2025 at 10:22 AM Robert Treat wrote:
> > On Sun, Jan 12, 2025 at 11:00 PM Amit Kapila
> > wrote:
> > > On Sat, Jan 11, 2025 at 7:28 PM Robert Treat wrote:
> > > +If a table wit
On Sun, Jan 12, 2025 at 11:00 PM Amit Kapila wrote:
>
> On Sat, Jan 11, 2025 at 7:28 PM Robert Treat wrote:
> >
> > Definitely couldn't hurt; Updated patch cleans that up a bit and
> > tweaks the link to alter table replica status.
> >
>
> IIUC, we have
On Tue, Jan 14, 2025 at 1:24 AM Peter Smith wrote:
> On Tue, Jan 14, 2025 at 4:46 PM Robert Treat wrote:
> > On Mon, Jan 13, 2025 at 8:07 PM Peter Smith wrote:
> > > On Tue, Jan 14, 2025 at 8:22 AM Robert Treat wrote:
> > > > On Mon, Jan 13, 2025 at 3:55
at that point will be dependent
on the structure of the table (PK or no PK), not whether it is being
replicated/published. To that end, I've taken the above suggestions
and re-worked them to remove that language, as well as add some
additional clarity.
Patch attached for this, I am going to update the commitfest with
myself as author and will work this further if needed. Thanks all.
Robert Treat
https://xzilla.net
0001-Replica-Identity-clarifications.patch
Description: Binary data
;
>> > I was not able to find you, please, register a community account and set
>> > yourself as an author for the patch.
>>
>> Done.
>
>
> I've marked this patch as Rejected, per discussion.
>
+1
> Still, I find this functionality nice to have, I'd b
On Tue, Dec 17, 2024 at 5:51 PM Melanie Plageman
wrote:
>
> Thanks for taking a look!
>
> I've rebased and attached an updated v3 which also addresses review feedback.
>
> On Sun, Dec 15, 2024 at 1:05 AM Robert Treat wrote:
> > On Fri, Dec 13, 2024 at 5:53 PM Melanie
around incompatibility, and 2) I think adding an explicit -f
for the database name in the pg_dumpall is clearer, and mirrors the
pg_dump example.
suggested diffs attached, let me know if you would like a consolidated patch
Robert Treat
https://xzilla.net
xzilla-pg_dump-no-psqlrc.diff
Description: Binary data
adding columns, so I think the initial tip should
remain, though I think it can be cleaned up a little.
In the second section (alter_table.sgml) I liked the idea of adding
these additional examples, though I tweaked the wording a bit to
(hopefully) make it a little easier to read.
Modified patch attac
k dropped
columns or new column defaults). Is ALTER TABLE REWRITE an
option? Current needed options would be for clustering or running
concurrently, but even without those options sometimes you just want
to rewrite the table, and this is probably the most straightforward
than making something up.
Robert Treat
https://xzilla.net
is quite high (not for pg_upgrade, but for $futureDBA), so
ISTM an explicit flag for BOTH is the right way to go. In that
scenario, pg_upgrade would check to make sure the clusters match and
then make the appropriate suggestion. In the case someone did
something like --enable-checksums and --link, a
nded use case for updating the catalog manually that
you had in mind and so the comments were warranted (and indeed, it's
part of why I thought the warning would be useful for users). But upon
reading the thread more and another pass through your updated patches,
this doesn't seem to be the case, and I wonder if this language might
be more encouraging of people updating catalogs than we would
typically be.
Robert Treat
https://xzilla.net
that don't make sense. If they
aren't mucking with the system, then it's valuable feedback that they
may have an underlying system problem that could be about to get
worse.
Robert Treat
https://xzilla.net
ue and lower-case the ones that aren't.
>
I kind of wondered about this, because I felt pretty used to seeing
the term "TOAST table", so I did some quick searches, and it looks
like we have about 20 cases where we use TOAST table vs about 10 where
we use toast table, specifically focusing on cases where we don't add
any markup to the word "toast", and about 20 more where we use
"TOAST table". So ISTM that folks are probably used
to seeing the term with upper case, but not universally so... so I
could probably get onboard with David's suggestion, although tbh I
probably would lean the other way.
Robert Treat
https://xzilla.net
on Miller's
law, but might be mis-remembering); we are already at 9 for this use case.
So really it is quite the opposite, we'd be reducing the burden on
customers by simplifying the interface rather than just throwing out every
possible combination and saying "you figure it out".
Robert Treat
https://xzilla.net
rtcuts, if the logic is simpler and more extensible for
future options...
Robert Treat
https://xzilla.net
On Fri, Mar 7, 2025 at 1:41 PM Jeff Davis wrote:
>
> On Fri, 2025-03-07 at 12:41 -0500, Robert Treat wrote:
> > Ugh... this feels like a bit of the combinatorial explosion,
> > especially if we ever need to add another option.
>
> Not quite that bad, because ideally the y
to be clear, there is also the decision on whether the
VACUUM commands default should default to truncate=on (like the
existing behavior) or truncate == vacuum_truncate guc, unless
explicitly set. I think the latter is probably the right way to go.
As an aside, thinking through a bunch of diffe
ot;. That's reducing their
> > choice, and then blaming them for their choice.
>
> Can we reach a decision here and move forward?
>
>
AFAIK the issue has been settled, or at the least we've agreed to move on.
Robert Treat
https://xzilla.net
93 matches
Mail list logo
