Обсуждение: Re: [BUGS] Fails to work on live images due to fsync() onpg_commit_ts before doing any write there

On Wed, Nov 8, 2017 at 1:23 AM, Raphael Hertzog <hertzog@debian.org> wrote:
> Well, it's the case by default with no persistence. But some users enable
> persistence and then it's no longer a tmpfs which is used.
>
> The problem also exists when you enable persistence but start with an
> empty upper layer so disabling fsyncs is not really an option.

Raphaël, don't you have problems with pg_twophase as well? Wouldn't
the new fsync call in CheckPointTwoPhase() fail equally if no 2PC
transactions have happened in a checkpoint cycle? That would not be an
issue with pg_commit_ts and pg_xact normally, but we are talking about
checkpoints skipped or not depending on WAL activity, tracking which
is more properly done in v10.
--
Michael


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi Michael,

On Wed, 08 Nov 2017, Michael Paquier wrote:
> Raphaël, don't you have problems with pg_twophase as well? Wouldn't
> the new fsync call in CheckPointTwoPhase() fail equally if no 2PC
> transactions have happened in a checkpoint cycle? That would not be an
> issue with pg_commit_ts and pg_xact normally, but we are talking about
> checkpoints skipped or not depending on WAL activity, tracking which
> is more properly done in v10.

I don't know. It's quite possible, I have not used PostgreSQL 10
extensively in Kali... I rely on Kali users for this.

I just checked and the usual database initialization code does not trigger
any write to pg_twophase so if there's a new fsync() on that directory
without any prior write, it's quite possible that this could fail later
on during PostgreSQL's use.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Wed, Nov 8, 2017 at 4:42 PM, Raphael Hertzog <hertzog@debian.org> wrote:
> On Wed, 08 Nov 2017, Michael Paquier wrote:
>> Raphaël, don't you have problems with pg_twophase as well? Wouldn't
>> the new fsync call in CheckPointTwoPhase() fail equally if no 2PC
>> transactions have happened in a checkpoint cycle? That would not be an
>> issue with pg_commit_ts and pg_xact normally, but we are talking about
>> checkpoints skipped or not depending on WAL activity, tracking which
>> is more properly done in v10.
>
> I don't know. It's quite possible, I have not used PostgreSQL 10
> extensively in Kali... I rely on Kali users for this.
>
> I just checked and the usual database initialization code does not trigger
> any write to pg_twophase so if there's a new fsync() on that directory
> without any prior write, it's quite possible that this could fail later
> on during PostgreSQL's use.

You can check that by using a manual CHECKPOINT query for example.
Based on what I see on this thread, my guess is that a failure would
show up.
--
Michael


--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 2017-11-08 16:53:49 +0900, Michael Paquier wrote:
> You can check that by using a manual CHECKPOINT query for example.
> Based on what I see on this thread, my guess is that a failure would
> show up.

Not in the the default config, no?  Note the default config escape
hatch:
void
CheckPointTwoPhase(XLogRecPtr redo_horizon)
{int            i;int            serialized_xacts = 0;
if (max_prepared_xacts <= 0)    return;                    /* nothing to do */

- Andres


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs