Kirk, I'm sorry about the long pause in my reply.
>We need some kind of semaphore flag that tells us something awkward
>happened. When it happened, and a little bit of extra information.
I agree that we do not have this kind of information.
Additionally, legal events like start of pg_rewind,
On Thu, Mar 2, 2023 at 4:09 PM Dmitry Koval wrote:
> I'll try to expand my explanation.
> I fully understand and accept the arguments about "limited sense to go
> into the control file" and "about recording *anything* in the control
> file". This is totally correct for vanilla.
> But vendors
I'll try to expand my explanation.
I fully understand and accept the arguments about "limited sense to go
into the control file" and "about recording *anything* in the control
file". This is totally correct for vanilla.
But vendors have forks of PostgreSQL with custom features and extensions.
Justin Pryzby writes:
> On Thu, Mar 02, 2023 at 08:57:43PM +0300, Dmitry Koval wrote:
>> These changes did not interest the community. It was expected (topic is very
>> specifiс: vendor's technical support). So no sense to distract developers
> Actually, I think there is interest, but it has to
On Thu, Mar 02, 2023 at 08:57:43PM +0300, Dmitry Koval wrote:
> These changes did not interest the community. It was expected (topic is very
> specifiс: vendor's technical support). So no sense to distract developers
Actually, I think there is interest, but it has to be phrased in a
limited sense
Hi!
These changes did not interest the community. It was expected (topic is
very specifiс: vendor's technical support). So no sense to distract
developers ...
I'll move patch to Withdrawn.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.com
On Thu, 19 Jan 2023 at 16:12, Dmitry Koval wrote:
>
> >The patch does not apply on top of HEAD ...
>
> Thanks!
> Here is a fixed version.
Sorry to say, but this needs a rebase again... Setting to Waiting on Author...
Are there specific feedback needed to make progress? Once it's rebased
if you
Hi!
Maybe another discussion thread can be created for the consolidation of
XX_file_exists functions.
Usually XX_file_exists functions are simple. They contain single call
stat() or open() and specific error processing after this call.
Likely the unified function will be too complex to
On Fri, Jan 20, 2023 at 1:19 AM Dmitry Koval wrote:
> Thanks, Ted Yu!
>
> > Please update year for the license in pg_controllog.c
>
> License updated for files pg_controllog.c, controllog_utils.c,
> pg_controllog.h, controllog_utils.h.
>
> > +check_file_exists(const char *datadir, const char
Thanks, Ted Yu!
> Please update year for the license in pg_controllog.c
License updated for files pg_controllog.c, controllog_utils.c,
pg_controllog.h, controllog_utils.h.
> +check_file_exists(const char *datadir, const char *path)
> There is existing helper function such as:
>
On Thu, Jan 19, 2023 at 1:12 PM Dmitry Koval wrote:
> >The patch does not apply on top of HEAD ...
>
> Thanks!
> Here is a fixed version.
>
> Additional changes:
> 1) get_operation_log() function doesn't create empty operation log file;
> 2) removed extra unlink() call.
>
> --
> With best
>The patch does not apply on top of HEAD ...
Thanks!
Here is a fixed version.
Additional changes:
1) get_operation_log() function doesn't create empty operation log file;
2) removed extra unlink() call.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.comFrom
On Sat, 14 Jan 2023 at 15:47, Dmitry Koval wrote:
>
> Hi!
>
> >The patch does not apply on top of HEAD ...
>
> Here is a fixed version.
> Small additional fixes:
> 1) added CRC calculation for empty 'pg_control_log' file;
> 2) added saving 'errno' before calling LWLockRelease and restoring after
Hi!
>The patch does not apply on top of HEAD ...
Here is a fixed version.
Small additional fixes:
1) added CRC calculation for empty 'pg_control_log' file;
2) added saving 'errno' before calling LWLockRelease and restoring after
that;
3) corrected pg_upgrade for case old cluster does not have
On Mon, 5 Dec 2022 at 13:42, Dmitry Koval wrote:
>
> Hi!
>
> >I think storing this in pg_control is a bad idea. That file is
> >extremely critical and if you break it, you're pretty much SOL on
> >recovering your data. I suggest that this should use a separate file.
>
> Thanks. Operation log
Hi!
>I think storing this in pg_control is a bad idea. That file is
>extremely critical and if you break it, you're pretty much SOL on
>recovering your data. I suggest that this should use a separate file.
Thanks. Operation log location changed to 'global/pg_control_log' (if
the name is not
On 2022-Nov-21, Dmitry Koval wrote:
> Concepts.
> -
> * operation log is placed in the file 'global/pg_control', starting from
> position 4097 (log size is 4kB);
I think storing this in pg_control is a bad idea. That file is
extremely critical and if you break it, you're pretty much SOL
Thanks for references, Justin!
Couple comments about these references.
1) "Make unlogged table resets detectable".
https://www.postgresql.org/message-id/flat/62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel%40j-davis.com
This conversation is about specific problem (unlogged table repairing).
See also prior discussions:
https://www.postgresql.org/message-id/flat/62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel%40j-davis.com
https://www.postgresql.org/message-id/flat/20180228214311.jclah37cwh572t2c%40alap3.anarazel.de
--
Justin
Hi, hackers!
It is important for customer support to know what system operations
(pg_resetwal, pg_rewind, pg_upgrade, ...) have been executed on the
database. A variant of implementation of the log for system operations
(operation log) is attached to this email.
Introduction.
-
20 matches
Mail list logo
