MVCC & visibilitysenior🔒 Pro concept

ctid and line pointers: why a row's physical address isn't a stable id

Simple terms

A row's address is two numbers: which page, and which slot on that page. Not a byte offset, a slot. That one layer of indirection is the whole trick. Indexes point at the slot, so Postgres can shuffle a row's bytes around inside its page to tidy up and every index entry still lands correctly. The catch is that slots get recycled as rows come and go. A ctid tells you where a row lives right now, not which row it is. Never store one as a permanent id.

You might be asked

What does a row's ctid actually point at, is the second number a byte offset into the page? Walk me through what happens to a row's ctid when you UPDATE it, how an index entry still finds the row afterward, and explain why ctid is a dangerous thing to store as a permanent row identifier.

TopicWhat a ctid really is: block + line-pointer (ItemId) index, the 4 line-pointer states, and why ctid is not a stable row id
PostgreSQL8.3-17 (HOT/LP_REDIRECT since 8.3; measured on 17.10)
Tools usedDocker pgi17 (PostgreSQL 17.10), pageinspect (heap_page_items), source @REL_17_10
Last reviewed2026-06-19

Pro concept

Full answer and evidence depth sit behind Pro

You have the question and a plain-English lead. Pro unlocks the short answer, what the docs say, what the code does, the labeled lab evidence or reproduction protocol, how to use it under pressure, and the references.

ProFull answer + evidence depth

Unlock the full breakdown for ctid and line pointers: why a row's physical address isn't a stable id

You have the interview question and a plain-English lead. Pro opens the short answer, the manual walkthrough, the source decode, and a 1-line evidence section that states whether it is raw output, a captured run summary, or a protocol to run yourself, plus how to use it under pressure.
  • How you'd answer it, the full senior-level short answer
  • What the docs say, the manual's actual wording, with the citations
  • What the code does, the mechanism decoded from PostgreSQL's own source at a pinned tag
  • Proof from a real run, labeled as raw output, a captured run summary, or a run-it-yourself protocol
  • Using it under pressure, the situation, the call you'd make, what goes wrong, and what people get wrong
  • Version notes, what changed across PostgreSQL releases

Card required. Cancel before day 7 and you are not charged.

Compare plans

How this was verified

The open teaser is the question and a plain-English lead. The short answer, the manual walkthrough, the source decode, the lab evidence, and how to use it under pressure unlock with Pro. Evidence is labeled as raw output, a captured run summary, or a run-it-yourself protocol.

Connected

Where this concept connects

How this concept links across the library, the interview questions that test it, its plain-English glossary definition, and the guided pathways it belongs to. Open the full map to explore further.

Open in the interactive map →