On Mon, Sep 02, 2024 at 05:08:03PM +0300, Heikki Linnakangas wrote:
> Hmm, I'm a bit disappointed this doesn't address replication. It makes sense
> that scans are counted separately on a standby, but it would be nice if
> stats like last_vacuum were propagated from primary to standbys. I guess
>
It'd not be such an issue if we updated stats during recovery, but I
think think we're doing that. Perhaps we should, which might also help
on replicas - no idea if it's feasible, though.
Stats on replicas are considered an independent thing AFAIU (scans are
counted for example in read-only quer
Hi,
On Mon, Aug 26, 2024 at 01:56:40PM +0900, Michael Paquier wrote:
> On Fri, Aug 02, 2024 at 02:11:34AM +0900, Michael Paquier wrote:
> > Applied 0003 for now to add the redo LSN to the pgstats file, adding
> > the redo LSN to the two DEBUG2 entries when reading and writing while
> > on it, that
ject: [PATCH v7] Flush pgstats file during checkpoints
The flushes are done for non-shutdown checkpoints and restart points, so
as it is possible to keep some statistics around in the event of a
crash. Keeping the before_shmem_exit() callback to flush the pgstats
file in a shutdown sequence is a bit ea
now.)
Attached is the last one.
--
Michael
From 8f1f7a9ca9c19dae88057a5593b0f9c0cd748a88 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 17 Jul 2024 12:42:43 +0900
Subject: [PATCH v6] Flush pgstats file during checkpoints
The flushes are done for non-shutdown checkpoints and restart poi
Hi,
On Tue, Jul 30, 2024 at 03:25:31PM +0900, Michael Paquier wrote:
> On Mon, Jul 29, 2024 at 04:46:17AM +, Bertrand Drouvot wrote:
> > Thanks! 0001 attached is
> > v4-0001-Revert-Test-that-vacuum-removes-tuples-older-than.patch
> > so I guess you did not attached the right one.
>
> I did a
chunk_s(fpin, &file_redo))
+ {
+ elog(WARNING, "could not read redo LSN");
+ goto error;
+ }
+
+ if (file_redo != redo)
+ {
+ elog(WARNING, "found incorrect redo LSN %X/%X (expected %X/%X)",
+ LSN_FORMAT_ARGS(file_redo), LSN_FORMAT_ARGS(redo));
+ goto error;
+ }
+
/*
Hi,
On Tue, Jul 23, 2024 at 12:52:11PM +0900, Michael Paquier wrote:
> On Mon, Jul 22, 2024 at 07:01:41AM +, Bertrand Drouvot wrote:
> > 3 ===
> >
> > + /*
> > +* Read the redo LSN stored in the file.
> > +*/
> > + if (!read_chunk_s(fpin, &file_redo) ||
> > +
d);
+ /* Write the redo LSN, used to cross check the file read */
+ write_chunk_s(fpout, &redo);
+
/* Write various stats structs for fixed number of objects */
for (int kind = PGSTAT_KIND_FIRST_VALID; kind <= PGSTAT_KIND_LAST; kind++)
{
@@ -1501,13 +1505,14 @@ read_chunk(FILE *fpin, voi
Hi,
On Wed, Jul 17, 2024 at 12:52:12PM +0900, Michael Paquier wrote:
> On Tue, Jul 16, 2024 at 10:37:39AM +0900, Michael Paquier wrote:
> > On Fri, Jul 12, 2024 at 01:01:19PM +, Bertrand Drouvot wrote:
> >> Instead of removing the stat file, should we keep it around until the
> >> first call
%s\" with redo %X/%X", statfile,
+ LSN_FORMAT_ARGS(redo));
/*
* Try to open the stats file. If it doesn't exist, the backends simply
--
2.45.2
From 52c6b52a5b795f25f7f638fabaa67875f0b08e04 Mon Sep 17 00:00:00 2001
From: Michael Paquier
Date: Wed, 17 Jul 2024 12:42:43 +09
On Fri, Jul 12, 2024 at 12:10:26PM +, Bertrand Drouvot wrote:
> Looking at 0001:
>
> + /* error logged already */
>
> Maybe mention it's already logged by durable_rename() (like it's done in
> InstallXLogFileSegment(), BaseBackup() for example).
>
> Except this nit, 0001 LGTM.
On Fri, Jul 12, 2024 at 01:01:19PM +, Bertrand Drouvot wrote:
> Instead of removing the stat file, should we keep it around until the first
> call
> to pgstat_write_statsfile()?
Oops. You are right, I have somewhat missed the unlink() once we are
done reading the stats file with a correct re
Hi,
On Fri, Jul 12, 2024 at 12:10:26PM +, Bertrand Drouvot wrote:
> Need to spend more time and thoughts on 0002+.
I think there is a corner case, say:
1. shutdown checkpoint at LSN1
2. startup->reads the stat file (contains LSN1)->all good->read stat file and
remove it
3. crash (no checkpoi
Hi,
On Fri, Jul 12, 2024 at 03:42:21PM +0900, Michael Paquier wrote:
> On Fri, Jul 05, 2024 at 01:52:31PM +0900, Michael Paquier wrote:
> > On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote:
> >> I think those are two independent issues - knowing that the snapshot is
> >> from the last
Hi,
On Fri, Jul 05, 2024 at 01:52:31PM +0900, Michael Paquier wrote:
> On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote:
> > I think those are two independent issues - knowing that the snapshot is
> > from the last checkpoint, and knowing that it's correct (not corrupted).
> > And yeah
;", statfile);
+ elog(DEBUG2, "reading stats file \"%s\" with redo %X/%X", statfile,
+ LSN_FORMAT_ARGS(redo));
/*
* Try to open the stats file. If it doesn't exist, the backends simply
--
2.45.2
From beda72b0ee48dd62ed60205a9cb4ca1496b45da5 Mon Sep 17 00:00:00 2
On Sat, Jun 29, 2024 at 11:13:04PM +0200, Tomas Vondra wrote:
> I think those are two independent issues - knowing that the snapshot is
> from the last checkpoint, and knowing that it's correct (not corrupted).
> And yeah, we should be careful about fsync/durable_rename.
Yeah, that's bugging me as
On 6/28/24 09:32, Konstantin Knizhnik wrote:
>
> On 18/06/2024 9:01 am, Michael Paquier wrote:
>> Hi all,
>>
>> On HEAD, xlog.c has the following comment, which has been on my own
>> TODO list for a couple of weeks now:
>>
>> * TODO: With a bit of extra work we could just start with a
>>
On 18/06/2024 9:01 am, Michael Paquier wrote:
Hi all,
On HEAD, xlog.c has the following comment, which has been on my own
TODO list for a couple of weeks now:
* TODO: With a bit of extra work we could just start with a pgstat file
* associated with the checkpoint redo location we'
Assert(IsUnderPostmaster || !IsPostmasterEnvironment);
- elog(DEBUG2, "reading stats file \"%s\"", statfile);
+ elog(DEBUG2, "reading stats file \"%s\" with redo %X/%X", statfile,
+ LSN_FORMAT_ARGS(redo));
/*
* Try to open the stats file. If it doesn
21 matches
Mail list logo
