Hi Michael Paquier
Thank you for the information you provided，
Thanks
On Tue, 24 Dec 2024 at 13:13, Michael Paquier wrote:
> On Tue, Dec 24, 2024 at 09:55:09AM +0800, wenhui qiu wrote:
> > However, on the other hand, oracle has many solutions to open the
> database
> > after the data fil
On Tue, Dec 24, 2024 at 09:55:09AM +0800, wenhui qiu wrote:
> However, on the other hand, oracle has many solutions to open the database
> after the data files are damaged, and his intention should be to start the
> database even if some critical files are damaged to salvage the data
> inside.Becau
HI Jan Wieck
> Why would you trust the other 99.999 TB if something corrupted the clog
> file?
However, on the other hand, oracle has many solutions to open the database
after the data files are damaged, and his intention should be to start the
database even if some critical files are damaged to s
>Why would you trust the other 99.999 TB if >something corrupted the clog
>file?
+1
On Tue, 24 Dec 2024 at 02:06, Jan Wieck wrote:
> On 12/23/24 06:01, 章晨曦@易景科技 wrote:
> > Yes, of course we can solve this by restoring from backup.
> > But if the database volumn is large, say, 100TB or more, the
On 12/23/24 06:01, 章晨曦@易景科技 wrote:
Yes, of course we can solve this by restoring from backup.
But if the database volumn is large, say, 100TB or more, the cost
is really too expensive just because the tiny clog file corrupt.
Why would you trust the other 99.999 TB if something corrupted the clo
> On 23 Dec 2024, at 16:01, 章晨曦@易景科技 wrote:
>
> Yes, of course we can solve this by restoring from backup.
> But if the database volumn is large, say, 100TB or more, the cost
> is really too expensive just because the tiny clog file corrupt.
There are corresponding commitfest entries [0,1],
Yes, of course we can solve this by restoring from backup.
But if the database volumn is large, say, 100TB or more, the cost
is really too expensive just because the tiny clog file corrupt.
Regards,
Jet
Daniel Gustafsson
> On 23 Dec 2024, at 15:36, 章晨曦@易景科技 wrote:
>
> disk errors, or even cosmic rays ...
It is file system responsibility to protect directory structure.
> Human errors,
We cannot protect database from this with technical measures. I concur with Tom
about firing DBA who removed xact log file.
> On 23 Dec 2024, at 11:36, 章晨曦@易景科技 wrote:
> Human errors, disk errors, or even cosmic rays ...
That sounds exactly like the scenario which backups are made for. In all these
error cases there is no way of being sure that no other part of the system has
been compromised, so you restore from ba
Human errors, disk errors, or even cosmic rays ...
Regards,
Jet
Andrey Borodin
> On 23 Dec 2024, at 15:03, 章晨曦@易景科技 wrote:
>
> S1:
> When database normal shutdown, and clog file missing, the database cannot
> restart. And if make a zero clog file, database started but may cause
> transactions lost.
>
> S2:
> When database crashed, and clog file missing, when database
S1:
When database normal shutdown, and clog file missing, the database cannot
restart. And if make a zero clog file, database started but may cause
transactions lost.
S2:
When database crashed, and clog file missing, when database restart,
it will try to recover. And everything is ok
So I t
> On 23 Dec 2024, at 14:12, 章晨曦@易景科技 wrote:
>
> we simulate crash and clog file corrupt (delete the clog file)
Clog file cannot disappear as a result of a crash. What makes you think
otherwise?
Best regards, Andrey Borodin.
Thanks tom.
But what I think is we may provide a better experience. Consider the
below example:
[jet@halodev-jet-01 data]$ psqlpsql (16.6)
Type "help" for help.
postgres=# CREATE TABLE a_test (n INT);
CREATE TABLE
postgres=# INSERT INTO a_test VALUES (1);
INSERT 0 1
postgres=# 2024-12-23 16
"=?utf-8?B?56ug5pmo5pumQOaYk+aZr+enkeaKgA==?="
writes:
> And after a while, a system error occurred and unfortunately, just
> caused clog file corrupted.
> So we need to restore the database from backup just because of the tiny clog
> file corrupted.
I'm not seeing a large difference between
But think about such a scenario, after INSERT some tuples, and COMMIT also
succeed.
And after a while, a system error occurred and unfortunately, just caused
clog file corrupted.
So we need to restore the database from backup just because of the tiny clog
file corrupted.
Is there any chance t
Yes, i think you're right. The tuple will be set to HEAP_XMIN_COMMITTED
when doing the visibility checking, but don't you think it's a little weird? Or
may cause some confusion?
Thanks,
Jet
Junwang Zhao
17 matches
Mail list logo
