On Mon, Jun 21, 2021 at 12:06 PM Nitin Jadhav
wrote:
> That was by mistake and I have corrected it in the attached patch.
Thanks for the patch. Here are some comments. Please ignore if I
repeat any of the comments given previously, as I didn't look at the
entire thread.
1) A new line between
Hi,
I'd really like to see this enabled by default, say with a default
interval of 10 seconds. If it has to be enabled explicitly, most
people won't, but I think a lot of people would benefit from knowing
why their system is slow to start up when that sort of thing happens.
I don't see much
Few comments for v4 patch:
@@ -7351,6 +7363,8 @@ StartupXLOG(void)
(errmsg("redo starts at %X/%X",
LSN_FORMAT_ARGS(ReadRecPtr;
+ InitStartupProgress();
+
/*
* main redo apply loop
*/
@@ -7358,6
> What is DUMMY about ? If you just want to separate the "start" from "end",
> you could write:
>
> /* codes for start of operations */
> FSYNC_IN_PROGRESS
> SYNCFS_IN_PROGRESS
> ...
> /* codes for end of operations */
> FSYNC_END
> SYNCFS_END
> ...
That was by mistake and I have corrected it in
+ * Codes of the operations performed during startup process
+ */
+typedef enum StartupProcessOp
+{
+ SYNCFS_IN_PROGRESS,
+ FSYNC_IN_PROGRESS,
+ RECOVERY_IN_PROGRESS,
+ RESET_UNLOGGED_REL_IN_PROGRESS,
+ DUMMY,
+ SYNCFS_END,
+ FSYNC_END,
+
> Since you agreed that SUSET was wrong, and PGC_POSTMASTER doesn't allow
> changing the value without restart, doesn't it follow that SIGHUP is what's
> wanted ?
Yes. I have done the changes in the attached patch.
Apart from this, I have done a few other changes to the patch. The
changes
On Thu, Jun 10, 2021 at 03:19:20PM +0530, Nitin Jadhav wrote:
> > > > + {"log_min_duration_startup_process", PGC_SUSET,
> > > > LOGGING_WHEN,
> > > >
> > > > I think it should be PGC_SIGHUP, to allow changing it during runtime.
> > > > Obviously it has no effect except during
> > > + {"log_min_duration_startup_process", PGC_SUSET,
> > > LOGGING_WHEN,
> > >
> > > I think it should be PGC_SIGHUP, to allow changing it during runtime.
> > > Obviously it has no effect except during startup, but the change will be
> > > effective if the current process
On Wed, Jun 09, 2021 at 05:09:54PM +0530, Nitin Jadhav wrote:
> > + {"log_min_duration_startup_process", PGC_SUSET,
> > LOGGING_WHEN,
> >
> > I think it should be PGC_SIGHUP, to allow changing it during runtime.
> > Obviously it has no effect except during startup, but the change
> Should it show the rusage ? It's shown at startup completion since 10a5b35a0,
> so it seems strange not to show it here.
> I don't know, that seems like it's going to make the messages awfully
> long, and I'm not sure of what use it is to see that for every report.
I have not changed anything
Robert Haas writes:
> ... I doubt that we can get away
> with a GetCurrentTimestamp() after applying every WAL record ... that
> seems like it will be slow.
Yeah, that's going to be pretty awful even on machines with fast
gettimeofday, never mind ones where it isn't.
It should be possible to
On Sun, Jun 6, 2021 at 6:23 PM Justin Pryzby wrote:
> Should it show the rusage ? It's shown at startup completion since 10a5b35a0,
> so it seems strange not to show it here.
I don't know, that seems like it's going to make the messages awfully
long, and I'm not sure of what use it is to see
On Fri, Jun 04, 2021 at 07:49:21PM +0530, Nitin Jadhav wrote:
> I have added the proper logs in all of the above scenarios.
>
> Following is the sample log displayed during server startup when the
> time period is set to 10ms.
>
> 2021-06-04 19:40:06.390 IST [51116] LOG: Syncing data directory,
Hi,
As nobody opposed the log based approach, I thought of creating a
patch using this approach. Please find the patch attached.
Introduced the new GUC variable 'log_min_duration_startup_process'
which indicates the time period after every time period it logs the
progress of the process startup
On Wed, 21 Apr 2021 12:36:05 -0700
Andres Freund wrote:
> [...]
>
> I don't think that concern equally applies for what I am proposing
> here. For one, we already have minRecoveryPoint in ControlData, and we
> already use it for the purpose of determining where we need to recover
> to,
Greetings,
On Wed, Apr 21, 2021 at 17:01 Andres Freund wrote:
> On 2021-04-21 16:55:28 -0400, Tom Lane wrote:
> > My concern about it was not at all about performance, but that every time
> > you write it is a new opportunity for the filesystem to lose or corrupt
> > the data.
>
> We already
Hi,
On 2021-04-21 16:55:28 -0400, Tom Lane wrote:
> My concern about it was not at all about performance, but that every time
> you write it is a new opportunity for the filesystem to lose or corrupt
> the data.
We already do, sometimes very frequent, control file updates on standbys
to update
Hi,
On 2021-04-21 16:28:26 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2021-04-21 15:51:38 -0400, Stephen Frost wrote:
> > > It does seem like we have some trade-offs here to weigh, but
> > > pg_control is indeed quite small..
> >
> > What do you mean by
Stephen Frost writes:
> * Andres Freund (and...@anarazel.de) wrote:
>> What do you mean by that? That the overhead of writing it out more
>> frequently wouldn't be too bad? Or that we shouldn't "unnecessarily" add
>> more fields to it?
> Mostly just that the added overhead in writing it out more
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-04-21 15:51:38 -0400, Stephen Frost wrote:
> > It does seem like we have some trade-offs here to weigh, but
> > pg_control is indeed quite small..
>
> What do you mean by that? That the overhead of writing it out more
> frequently
Hi,
On 2021-04-21 15:51:38 -0400, Stephen Frost wrote:
> It does seem like we have some trade-offs here to weigh, but
> pg_control is indeed quite small..
What do you mean by that? That the overhead of writing it out more
frequently wouldn't be too bad? Or that we shouldn't "unnecessarily" add
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-04-21 14:36:24 -0400, Stephen Frost wrote:
> > * Andres Freund (and...@anarazel.de) wrote:
> > > Unfortunately I think something like a percentage is hard to calculate
> > > right now. Even just looking at crash recovery (vs
Hi,
On 2021-04-21 14:36:24 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > Unfortunately I think something like a percentage is hard to calculate
> > right now. Even just looking at crash recovery (vs replication or
> > PITR), we don't currently know where the WAL
Stephen Frost writes:
> * Andres Freund (and...@anarazel.de) wrote:
>> On 2021-04-20 14:56:58 -0400, Tom Lane wrote:
>>> I wonder though whether we really need authentication here. pg_ping
>>> already exposes whether the database is up, to anyone who can reach the
>>> postmaster port at all.
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2021-04-20 14:56:58 -0400, Tom Lane wrote:
> > I wonder though whether we really need authentication here. pg_ping
> > already exposes whether the database is up, to anyone who can reach the
> > postmaster port at all. Would it be so
+1 for both log messages and allowing connections. I believe these two
complement each other.
In the cloud world, we oftentimes want to monitor the progress of the
recovery without connecting to the server as the operators don't
necessarily have the required permissions to connect and query.
On 2021-Apr-20, Andres Freund wrote:
> On 2021-04-19 13:55:13 -0400, Robert Haas wrote:
> > Another possible approach would be to accept connections for
> > monitoring purposes even during crash recovery. We can't allow access
> > to any database at that point, since the system might not be
> >
Hi,
On 2021-04-20 14:56:58 -0400, Tom Lane wrote:
> I wonder though whether we really need authentication here. pg_ping
> already exposes whether the database is up, to anyone who can reach the
> postmaster port at all. Would it be so horrible if the "can't accept
> connections" error message
Hi,
On 2021-04-19 13:55:13 -0400, Robert Haas wrote:
> Another possible approach would be to accept connections for
> monitoring purposes even during crash recovery. We can't allow access
> to any database at that point, since the system might not be
> consistent, but we could allow something
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Yeah, being able to pick up on this remotely seems like it'd be quite
> > nice. I'm not really thrilled with the idea, but the best I've got
> > offhand for this would be a new role that's "pg_recovery_login" where an
Stephen Frost writes:
> Yeah, being able to pick up on this remotely seems like it'd be quite
> nice. I'm not really thrilled with the idea, but the best I've got
> offhand for this would be a new role that's "pg_recovery_login" where an
> admin can GRANT that role to the roles they'd like to be
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > On Tue, Apr 20, 2021 at 5:17 PM Jehan-Guillaume de Rorthais
> > wrote:
> >> Two another options:
> >> 1. if this is limited to local access only, outside of the log entries, the
> >> status of the startup could be
Magnus Hagander writes:
> On Tue, Apr 20, 2021 at 5:17 PM Jehan-Guillaume de Rorthais
> wrote:
>> Two another options:
>> 1. if this is limited to local access only, outside of the log entries, the
>> status of the startup could be updated in the controldata file as well. This
>> would allows to
On Tue, Apr 20, 2021 at 5:17 PM Jehan-Guillaume de Rorthais
wrote:
>
> On Tue, 20 Apr 2021 15:04:28 +0200
> Magnus Hagander wrote:
> [...]
> > Yeah, I think we should definitely limit this to local access, one way
> > or another. Realistically using pg_hba is going to require catalog
> > access,
On Tue, 20 Apr 2021 15:04:28 +0200
Magnus Hagander wrote:
[...]
> Yeah, I think we should definitely limit this to local access, one way
> or another. Realistically using pg_hba is going to require catalog
> access, isn't it? And we can't just go ignore those rows in pg_hba
> that for example
On Tue, Apr 20, 2021 at 2:43 PM Robert Haas wrote:
>
> On Mon, Apr 19, 2021 at 8:44 PM Tom Lane wrote:
> > Hmm ... +1 for progress messages in the log, but I'm suspicious about
> > the complexity-and-fragility-versus-value tradeoff for the other thing.
>
> All right, so it's nice to hear that
On Mon, Apr 19, 2021 at 8:44 PM Tom Lane wrote:
> Hmm ... +1 for progress messages in the log, but I'm suspicious about
> the complexity-and-fragility-versus-value tradeoff for the other thing.
All right, so it's nice to hear that nobody so far is opposed to the
log-based solution, and I think
On Mon, Apr 19, 2021 at 7:55 PM Robert Haas wrote:
>
> Hi,
>
> I've noticed that customers not infrequently complain that they start
> postgres and then the system doesn't come up for a while and they have
> no idea what's going on and are (understandably) worried. There are
> probably a number
Thomas Munro writes:
> On Tue, Apr 20, 2021 at 5:55 AM Robert Haas wrote:
>> If I had to pick one of these two ideas, I'd pick the one the
>> log-based solution, since it seems easier to access and simplifies
>> retrospective analysis, but I suspect SQL access would be quite useful
>> for some
On Tue, Apr 20, 2021 at 5:55 AM Robert Haas wrote:
> If I had to pick one of these two ideas, I'd pick the one the
> log-based solution, since it seems easier to access and simplifies
> retrospective analysis, but I suspect SQL access would be quite useful
> for some users too, especially in
On Mon, Apr 19, 2021 at 01:55:13PM -0400, Robert Haas wrote:
> I've noticed that customers not infrequently complain that they start
> postgres and then the system doesn't come up for a while and they have
> no idea what's going on and are (understandably) worried. There are
> probably a number of
On 2021-Apr-19, Robert Haas wrote:
> Another possible approach would be to accept connections for
> monitoring purposes even during crash recovery. We can't allow access
> to any database at that point, since the system might not be
> consistent, but we could allow something like a replication
Hi,
I've noticed that customers not infrequently complain that they start
postgres and then the system doesn't come up for a while and they have
no idea what's going on and are (understandably) worried. There are
probably a number of reasons why this can happen, but the ones that
seem to come up
101 - 143 of 143 matches
Mail list logo
