From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, Brian Hirt <bhirt(at)mobygames(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org>, Brian A Hirt <bhirt(at)berkhirt(dot)com> |
Subject: | Re: problems with table corruption continued |
Date: | 2001-12-19 00:19:54 |
Message-ID: | 3C1FDD2A.EC4A8B51@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
> > Should the change be TransactionIdIsInProgress(tuple->t_cmin) ?
>
> I'd be willing to do
> if (tuple->t_cmin is my XID)
> do something;
> Assert(!TransactionIdIsInProgress(tuple->t_cmin));
> if that makes you feel better.
It's useless in hard to reproduce cases.
I've thought but given up many times to propose this
change and my decision seems to have been right because
I see only *Assert* even after this issue.
> But anything that's scanning
> a table exclusive-locked by another transaction is broken.
> (BTW: contrib/pgstattuple is thus broken. Will fix.)
It seems dangerous to me to rely only on developers'
carefulness. There are some places where relations
are opened with NoLock. We had better change them.
I once examined them but AFAIR there are few cases
when they are really opened with NoLock. In most
cases they are already opened previously with other
lock modes. I don't remember well if there was a
really dangerous(scan an relation opened with NoLock)
place.
regards,
Hiroshi Inoue
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-19 00:22:06 | Possible bug in vacuum redo |
Previous Message | Thomas Swan | 2001-12-19 00:04:49 | Re: Thoughts on the location of configuration files |