5.2.8. Tips and Examples
25.2.9. Caveats
25.3. File System Level Backup
I slightly modified section 25.2.1 and 25.3 as proposed.
--
Benoit Lobréau
Consultant
http://dalibo.com
From 16813b396a45c4061b5c2d21a9091e3fb372567c Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 15 Apr 2025 15:25:08
On 4/7/25 6:41 PM, Melanie Plageman wrote:
On Mon, Feb 3, 2025 at 12:37 AM Sami Imseih wrote:
I started looking at this, and I like the idea.
Thanks for taking a look!
A few comments: I don't understand what 0002 is. For starters, the
commit message says something about pg_stat_database, and
4 | 7.0171877| 8.43500897435
as Amit pointed out, we will share a new test script soon
that uses the SQL API xxx_get_changes() to test. It would be great if you could
verify the performance using the updated script as well.
Will do.
--
Benoit Lobréau
Consultant
http://dalibo.com
| 3,57678295 | 18,67676928162
2000 | 7,0171877 | 6,4713304| 8,43500897435
I'll try to run test2.pl later (right now it fails).
hope this helps.
--
Benoit Lobréau
Consultant
http://dalibo.com
cache_inval_bug_v1.ods
Description: applic
ities)?
--
Benoit Lobréau
Consultant
http://dalibo.com
file */".
Thank you Michael and David.
I never paid attention to thoses...
--
Benoit Lobréau
Consultant
http://dalibo.com
From 9a12cad29afb86f2277bf76bc53757702715afd5 Mon Sep 17 00:00:00 2001
From: benoit
Date: Fri, 21 Feb 2025 14:09:56 +0100
Subject: [PATCH] Adjust logging for invalid recovery tim
.
Is there a specific way todo this?
--
Benoit Lobréau
Consultant
http://dalibo.com
From 35dd8db22c997e78ba92f63ffca3022b435d7304 Mon Sep 17 00:00:00 2001
From: benoit
Date: Fri, 21 Feb 2025 14:09:56 +0100
Subject: [PATCH] Adjust logging for invalid recovery timeline
The original message
On 2/20/25 4:40 PM, David Steele wrote:
Benoit -- this was your idea. Did you want to submit a patch yourself?
Here is an attempt at that. I kept the wording I used above. Is it fine
to repeat the whole ereport block twice?
--
Benoit Lobréau
Consultant
http://dalibo.com
From
(or me in a few month) it might be useful ?
--
Benoit Lobréau
Consultant
http://dalibo.com
the same way as other
GUCs with an options list. I ended up just making those changes
in v8.
Besides that, I think this is ready for committer.
Thank you for your time and advice on this.
--
Benoit Lobréau
Consultant
http://dalibo.com
I did some additional testing with this command within transactions.
I had the "BEGIN; ALTER INDEX; EXPLAIN; ROLLBACK;" scenario in mind, but
didn't realise we acquire an AccessExclusiveLock on the index. Therefore, it's
not possible to change the visibility within a single transaction
unless
e), collect the logs and generate a report
for the said period to have a broad overview of what is happenning.
I attached patches that implemented both your suggestions (I regrouped
all the utilities together).
Thank you !
--
Benoit Lobréau
Consultant
http://
ey had the same density but one had no fragmentation while the
other had 100%. He got an execution time of ~90ms (0 frag) vs ~340ms
100% frag).
I get similar result with my laptor (except my disk is significantly
worse: ~152ms vs ~833ms).
Here are the scripts.
--
Benoit Lobréau
C
I also noticed that \d on an index doesn't warn about the invisible state
whereas \d on a table does:
[local]:5444 postgres@postgres=# SELECT indexrelid::regclass,
indisvalid, indisvisible FROM pg_index WHERE indexrelid =
'repli_pkey'::regclass \gx
-[ RECORD 1 ]+---
indexrelid | repli_pk
On Fri, Jan 24, 2025 at 11:32 AM Benoit Lobréau
wrote:
> The completion for the INVISIBLE / VISIBLE keyword is missing in psql.
I think this should to the trick ?
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index 81cbf10aa28..43ea8e55fd0 100644
--- a/src/
Hi,
Thank you for the patch! I've had a need for this feature several times,
so I appreciate the work you’ve put into it.
I like the new name VISIBLE/INVISIBLE and the fact that it's a separate flag in
pg_index (it's easy to monitor).
I don’t feel qualified to provide an opinion on the code itse
25.3.8. Tips and Examples
25.3.9. Caveats
Note: As I mentioned to you privately, I made a mistake and broke the
thread. I’ve added the new thread to the commit fest. Here is a link to
the old one to help others follow the conversation:
https://www.postgresql.org/message-id/flat/CAKFQuwaS6DtSde4TWpk133mfaQbgh8d%2BPkk0kDN%3D6jf6qEWbvQ%40mail.gmail.com
--
Benoit Lobréau
Consultant
http://dalibo.com
Here is an updated patch to save you some time.
--
Benoit Lobréau
Consultant
http://dalibo.com
From 5d89ca0a36e98d1e5be858166a8394c09e0fa129 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Yhuel?=
Date: Tue, 5 Nov 2024 17:59:44 +0100
Subject: [PATCH] doc: explain pgstatindex
e Hot Backup
25.3.6. Recovering Using a Continuous Archive Backup
25.3.7. Timelines
25.3.8. Tips and Examples
25.3.9. Caveats
--
Benoit Lobréau
Consultant
http://dalibo.com
corresponds to the logical order we would have
just after
a REINDEX.
--
Benoit Lobréau
Consultant
http://dalibo.com
would want to have the information for only a portion of the
functionality's usage (even if it's the most important).
--
Benoit Lobréau
Consultant
http://dalibo.comFrom b99dc5c1c549921ed2ac054db4e8c5398543dfc4 Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 8 Oct 2024 12:39:41 +0200
If we decide
to strip them, I will revert it to log_parallel_query_workers.
>> I don't think "failure" is a good name for the setting as it's
>> a bit too harsh. What we really have is a "shortage" of
>> workers.
I agree that "failure" is too harsh. The term "shortage" better describes
the situation.
Note: I added Tomas Vondra to the recipients of the email since he advised
me on this topic initially and might have an opinion on this.
--
Benoit Lobréau
Consultant
http://dalibo.com
This is just a rebase.
As stated before, I added some information to the error message for
parallel queries as an experiment. It can be removed, if you re not
convinced.
---
Benoit Lobréau
Consultant
http://dalibo.comFrom 7e63f79226357f2fe84acedb950e64383e582b17 Mon Sep 17 00:00:00 2001
From
amp; brin) and vacuum cleanup is not commited
yet since it's not a common occurence. I implemented it in separate
counters.
--
Benoit Lobréau
Consultant
http://dalibo.com
for coherence sake. I prefer "planned"
but english is clearly not my strong suit and I assumed it meant that
the number of worker planned could change before execution. I just
checked in parallel.c and I don't think it's the case, could it be done
elsewhere ?
--
Benoit Lob
On 11/11/24 02:51, Michael Paquier wrote:
Okidoki, applied. If tweaks are necessary depending on the feedback,
like column names, let's tackle things as required. We still have a
good chunk of time for this release cycle.
--
Michael
Thanks !
--
Benoit Lobréau
Consultant
http://dalibo.com
objections or
comments, feel free.
Found a few more things, but overall it was fine. Here is what I have
staged on my local branch.
--
Michael
Hi,
I just reread the patch.
Thanks for the changes. It looks great.
--
Benoit Lobréau
Consultant
http://dalibo.com
On 10/15/24 09:52, Benoit Lobréau wrote:
Thank you, it's a lot cleaner that way.
I'll add this asap.
This is an updated version with the suggested changes.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom b9bf7c0fa967c72972fd77333a768dfe89d91765 Mon Sep 17 00:00:00 2001
From: be
On 10/14/24 22:42, Alena Rybakina wrote:
Attached is the correct version of the patch.
Thank you, it's a lot cleaner that way.
I'll add this asap.
--
Benoit Lobréau
Consultant
http://dalibo.com
This is a rebased version.
I have split queries, vacuum and index creation in different patches.
I have also split the declartion that are in common with the
pg_stat_database patch.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom cfa426a080ca2d0c484ac8f5201800bd6434 Mon Sep 17 00:00:00
rsion, I modified it to:
* have the same wording in the doc and code (planned => to_launch)
* split de declaration from the rest (and have the same code as the
parallel worker logging patch)
--
Benoit Lobréau
Consultant
http://dalibo.comFrom ab9aa1344f974348638dd3898c944f3d5253374d Mon Sep 17
ded before posting
the result here.
I have hopes to finish it this week.
--
Benoit Lobréau
Consultant
http://dalibo.com
bd_VbUt6K6xn8P7X%2B_dZqKw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/flat/CAECtzeXXuMkw-RVGTWvHGOJsmFdsRY%2BjK0ndQa80sw46y2uvVQ%40mail.gmail.com
[3]
https://www.postgresql.org/message-id/8123423a-f041-4f4c-a771-bfd96ab235b0%40dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.com
Here is a new version that fixes the aforementioned problems.
If this patch is accepted in this form, the counters could be used for
the patch in pg_stat_database. [1]
[1]
https://www.postgresql.org/message-id/flat/783bc7f7-659a-42fa-99dd-ee0565644...@dalibo.com
--
Benoit Lobréau
Consultant
Here is an updated patch fixing the aforementionned problems
with tests and vacuum stats.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom 1b52f5fb4e977599b8925c69193d31148042ca7d Mon Sep 17 00:00:00 2001
From: benoit
Date: Wed, 28 Aug 2024 02:27:13 +0200
Subject: [PATCH] Adds four parallel
-ee0565644...@dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.com
es().
Back to the drawing board...
--
Benoit Lobréau
Consultant
http://dalibo.com
Hi,
This new version avoids updating the stats for non parallel queries.
I noticed that the tests are still not stable. I tried using tenk2
but fail to have stable plans. I'd love to have pointers on that front.
--
Benoit Lobréau
Consultant
http://dalibo.co
check executions.)
On 8/28/24 17:10, Benoit Lobréau wrote:
Hi hackers,
This patch introduces four new columns in pg_stat_database:
* parallel_worker_planned
* parallel_worker_launched
* parallel_maint_worker_planned
* parallel_maint_worker_launched
The intent is to help administrators evaluate
ched | 4
Thanks to: Jehan-Guillaume de Rorthais, Guillaume Lelarge and Franck
Boudehen for the help and motivation boost.
---
Benoit Lobréau
Consultant
http://dalibo.comFrom cabe5e8ed2e88d9cf219161394396ebacb33a5a0 Mon Sep 17 00:00:00 2001
From: benoit
Date: Wed, 28 Aug 2024 02:27:13 +0200
Subject:
help and motivation boost.
(sorry for the spam, I had to resend the mail to the list)
--
Benoit Lobréau
Consultant
http://dalibo.comFrom 940e1d1149f33ea00e7a0a688da67f492f6d Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 26 Aug 2024 13:48:44 +0200
Subject: [PATCH] Add logging for
by next week at wich point I'll have time to go back
to this. sorry for the delay.
--
Benoit Lobréau
Consultant
http://dalibo.com
s.
> Some random thoughts/ideas about how to approach this:
>
> - For parallel workers I think this might be as simple as adding some
> counters into QueryDesc, and update those during query exec (instead of
> just logging stuff directly). I'm not sure if it should be added to
convinced the spelling was correct.
--
Benoit Lobréau
Consultant
http://dalibo.com
t know how difficult would it be to track/collect this information
> for the whole query.
I am a worried this will be a little too much for me, given the time and
the knowledge gap I have (both in C and PostgreSQL internals). I'll try
to look anyway.
--
Benoit Lobréau
Consultant
http://dalibo.com
ion in "Logical Replication > Subscription" with
the text you suggested and links in the CREATE / ALTER SUBSRIPTION commands.
Is it better ?
--
Benoit Lobréau
Consultant
http://dalibo.comFrom f3f1b0ce8617971b173ea901c9735d8357955aa2 Mon Sep 17 00:00:00 2001
From: benoit
Date: Thu
/pgsql_tmp/pgsql_tmp138850.23", size 14
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp138850.22", size
122880 => Second sort
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp138850.21", size 14
--
Benoit Lobréau
Consultant
http://dalibo.com
steps here ].
Warning: if the connection string doesn't contain a password, make sure
to set password_required=false before transferring ownership, otherwise
it will start failing."
Ok, I will do it that way. Would you prefer this section to be in the
ALTER SUBSCRIPTION on the CREATE SUB
On 9/26/23 16:27, Benoit Lobréau wrote:
I will try to come up with a documentation patch.
This is my attempt at a documentation patch.
--
Benoit Lobréau
Consultant
http://dalibo.comFrom a73baa91032fff37ef039168c276508553830f86 Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 26 Sep 2023 18
re refering to earlier ?
[1]
https://www.postgresql.org/message-id/flat/5dff4caf26f45ce224a33a5e18e110b93a351b2f.camel%40j-davis.com#ff4a06505de317b1ad436b8102a69446
--
Benoit Lobréau
Consultant
http://dalibo.com
and form->subpasswordrequired is true
Should there be a test to check if the user executing the query is
superuser? maybe it's handled differently? (I am not very familiar with
the code).
I dont understand (yet?) why I can do ALTER SUBSCRIPTIONs after changing
the ownership to an unpriviledged user (must_use_password should be true
also in that case).
--
Benoit Lobréau
Consultant
http://dalibo.com
RIPTION failure in password_required.log expected for
both superuser and non-superuser?
Is the DROP SUBSCRIPTION success in password_required2.log expected?
(i.e., with password_require=false, the only action a non-superuser can
perform is dropping the subscription. Since they own it, it is
understandable).
--
Benoit Lobréau
Consultant
http://dalibo.com
t works.
Is it normal (given the previous message)?
(see password_required2.sql and password_required2.log)
--
Benoit Lobréau
Consultant
http://dalibo.com
--
\c tests_pg16 postgres
You are now connected to database "tests_pg16" as user &quo
bo.com
[2]
https://www.postgresql.org/message-id/flat/6acbe570-068e-bd8e-95d5-00c737b865e8%40gmail.com
--
Benoit Lobréau
Consultant
http://dalibo.comFrom fc71ef40f33f94b0506a092fb5b3dcde6de6d60a Mon Sep 17 00:00:00 2001
From: benoit
Date: Tue, 2 May 2023 10:08:00 +0200
Subject: [PATCH] Add l
e guc, but I would like to keep it at the
LOG level. When I do audits most client are at that level and setting it
to DEBUG1 whould add too much log for them on the long run.
I'll post the corresponding patch asap.
--
Benoit Lobréau
Consultant
http://dalibo.com
tement execution: workers
spawned 1, requested 2
STATEMENT: EXPLAIN (ANALYZE) SELECT i, avg(j) FROM test_pql GROUP BY i;
```
[1]
https://www.postgresql.org/message-id/d657df20-c4bf-63f6-e74c-cb85a81d0...@dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.comFrom f7d3dae918df2dbbe7fd18cf48f7ca39d57
icular case.
Finally, the per relation statitics could be combined with system and other
PostgreSQL metrics to identify why the storage is stressed.
If you reach this point, thank you for reading me!
Many thanks to Melanie Plageman for the pointers she shared with us
around the
pgsessions in Paris and her time in general.
--
Benoit Lobréau
Consultant
http://dalibo.com
On Tue, Aug 30, 2022 at 12:46 AM Nathan Bossart
wrote:
> I would advise that you create a commitfest entry for your patch so that it
> isn't forgotten.
>
Ok done, https://commitfest.postgresql.org/39/3856/ (is that fine if I
added you as a reviewer ?)
and thanks for the added links in the patch
Our client confirmed that the more he fetches the more memory is consumed.
The segfault was indeed caused by the absence of LDR_CNTRL.
The tests show that:
* without LDR_CNTRL, we reach 256Mb and segfault ;
* with LDR_CNTRL=MAXDATA=0x1000, we reach 256Mo but there is no
segfault, the program
Thanks !
Le mar. 2 mars 2021 à 04:10, Julien Rouhaud a écrit :
> On Tue, Mar 2, 2021 at 9:29 AM Michael Paquier
> wrote:
> >
> > On Mon, Mar 01, 2021 at 05:17:06PM +0800, Julien Rouhaud wrote:
> > > Maybe this can be better addressed than with a link in the
> > > documentation. The final outco
I like the idea !
If it's not too complicated, I'd like to take a stab at it.
Le lun. 1 mars 2021 à 10:16, Julien Rouhaud a écrit :
> On Mon, Mar 1, 2021 at 4:33 PM Benoit Lobréau
> wrote:
> >
> > Le lun. 1 mars 2021 à 08:36, Michael Paquier a
> écrit :
>
Le lun. 1 mars 2021 à 08:36, Michael Paquier a écrit :
> On Fri, Feb 26, 2021 at 10:03:05AM +0100, Benoit Lobréau wrote:
> > Done here : https://commitfest.postgresql.org/32/3012/
>
> Documenting that properly for the archive command, as already done for
> restore_command, sou
Done here : https://commitfest.postgresql.org/32/3012/
Le jeu. 25 févr. 2021 à 15:34, Julien Rouhaud a écrit :
> On Thu, Feb 25, 2021 at 7:25 PM Benoit Lobréau
> wrote:
> >
> > Le mer. 24 févr. 2021 à 14:52, Julien Rouhaud a
> écrit :
> >>
> >> I th
Le mer. 24 févr. 2021 à 14:52, Julien Rouhaud a écrit :
> Hi,
>
> On Wed, Feb 24, 2021 at 8:21 PM talk to ben wrote:
> >
> > The documentation describes how a return code > 125 on the
> restore_command would prevent the server from starting [1] :
> >
> > "
> > It is important that the command re
> Pushed. Thanks!
>
Thank you !
Hi,
It seems like this part of the documentation was not updated after changing
the default value of recovery_target_timeline to latest in v12.
"The default behavior of recovery is to recover along the same timeline
that was current when the base backup was taken. If you wish to recover
into som
Here's a proposal patch.
Le ven. 11 déc. 2020 à 09:58, Benoit Lobréau a
écrit :
> Would "NULL for anonymous allocations, since details related to them are
> not known." be ok ?
>
>
> Le ven. 11 déc. 2020 à 09:29, Kyotaro Horiguchi
> a écrit :
>
>> A
Would "NULL for anonymous allocations, since details related to them are
not known." be ok ?
Le ven. 11 déc. 2020 à 09:29, Kyotaro Horiguchi a
écrit :
> At Fri, 11 Dec 2020 14:42:45 +0900, Michael Paquier
> wrote in
> > On Fri, Dec 11, 2020 at 11:00:58AM +0900, Kyotaro Horiguchi wrote:
> > > A
Hi,
While reading the documentation of pg_shmem_allocations, I noticed that the
off column is described as such :
"The offset at which the allocation starts. NULL for anonymous allocations
and unused memory."
Whereas, the view returns a value for unused memory:
[local]:5433 postgres@postgres=#
69 matches
Mail list logo
