Thread: not finding rows using ctid

not finding rows using ctid

From
AI Rumman
Date:

Hi,

I am getting the logs as follows:

LOG:  process 32145 acquired ExclusiveLock on tuple (153420,5) of relation 663326 of database 475999 after 1123.028 ms


But, when I am executing sqls to find the row on that table using the ctid = '(153420,5)', I get no rows.


Any idea, why?


Thanks.

Re: not finding rows using ctid

From
Adrian Klaver
Date:
On 08/07/2014 12:40 PM, AI Rumman wrote:
>
> Hi,
>
> I am getting the logs as follows:
>
> LOG:  process 32145 acquired ExclusiveLock on tuple (153420,5) of
> relation 663326 of database 475999 after 1123.028 ms
>
>
> But, when I am executing sqls to find the row on that table using the
> ctid = '(153420,5)', I get no rows.
>
>
> Any idea, why?

http://www.postgresql.org/docs/9.3/static/ddl-system-columns.html
"ctid

     The physical location of the row version within its table. Note
that although the ctid can be used to locate the row version very
quickly, a row's ctid will change if it is updated or moved by VACUUM
FULL. Therefore ctid is useless as a long-term row identifier. The OID,
or even better a user-defined serial number, should be used to identify
logical rows."

Something changed the row between the time you saw it in the log and the
time you did the query.

>
>
> Thanks.
>


--
Adrian Klaver
adrian.klaver@aklaver.com


Re: not finding rows using ctid

From
AI Rumman
Date:
I didn't execute any Vacuum Full and I tried to get the row after 3 hours of the issue.

Thanks.


On Thu, Aug 7, 2014 at 1:51 PM, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
On 08/07/2014 12:40 PM, AI Rumman wrote:

Hi,

I am getting the logs as follows:

LOG:  process 32145 acquired ExclusiveLock on tuple (153420,5) of
relation 663326 of database 475999 after 1123.028 ms


But, when I am executing sqls to find the row on that table using the
ctid = '(153420,5)', I get no rows.


Any idea, why?

http://www.postgresql.org/docs/9.3/static/ddl-system-columns.html
"ctid

    The physical location of the row version within its table. Note that although the ctid can be used to locate the row version very quickly, a row's ctid will change if it is updated or moved by VACUUM FULL. Therefore ctid is useless as a long-term row identifier. The OID, or even better a user-defined serial number, should be used to identify logical rows."

Something changed the row between the time you saw it in the log and the time you did the query.



Thanks.



--
Adrian Klaver
adrian.klaver@aklaver.com

Re: not finding rows using ctid

From
Adrian Klaver
Date:
On 08/07/2014 02:14 PM, AI Rumman wrote:
> I didn't execute any Vacuum Full and I tried to get the row after 3
> hours of the issue.

Also, "...a row's ctid will change if it is updated..."

>
> Thanks.
>




--
Adrian Klaver
adrian.klaver@aklaver.com