Обсуждение: XLOG's implementation details

Поиск
Список
Период
Сортировка

XLOG's implementation details

От
Ozgun Erdogan
Дата:
Hi all,

I am new to Postgres and am interested in XLOG's implementation
details. I browsed around the source code, and saw that the particular
function that appends XLOG entries is called from multiple places
(heap, indexes, transaction subsystem, and so forth). Seeing this, I
became particularly interested in the following:

How strong is the coupling between XLOG entries and database pages?
That is, assume that I am inserting one row to a database table. Is
there anyway for me to construct the related XLOG entry before calling
the heap insert function? Or, are XLOG files conceptually binary diffs
for database pages, moving forward in time?

Another question that I had relates to XLOG files and tables. If I
have two databases and one is set up as a slave to the other, is it
possible for the slave to have fewer tables than the master? If it is
possible, is that because tables don't share pages?

Again I'm new to Postgres, and am curious about how stuff works
underneath the covers. I figured asking this list would be the
simplest way to figure things out.

Thanks,

Ozgun.

Re: XLOG's implementation details

От
Erik Jones
Дата:
On Nov 13, 2009, at 3:46 AM, Ozgun Erdogan wrote:

> How strong is the coupling between XLOG entries and database pages?
> That is, assume that I am inserting one row to a database table. Is
> there anyway for me to construct the related XLOG entry before calling
> the heap insert function? Or, are XLOG files conceptually binary diffs
> for database pages, moving forward in time?

The latter.  The converse of your question is much more common, "How
can I reconstruct the statements that changed my database from the
xlog contents", with the same answer.

> Another question that I had relates to XLOG files and tables. If I
> have two databases and one is set up as a slave to the other, is it
> possible for the slave to have fewer tables than the master? If it is
> possible, is that because tables don't share pages?

That depends on how you implement replication.  Since you ask in the
context of xlogs I'll assume you mean a warm standby slave via WAL
shipping and there the answer is no.  Well, you might be able to work
something out by using record-based log shipping but even if that
could work it would take a lot of, well, work.

> Again I'm new to Postgres, and am curious about how stuff works
> underneath the covers. I figured asking this list would be the
> simplest way to figure things out.

Yep :)

Erik Jones, Database Administrator
Engine Yard
Support, Scalability, Reliability
866.518.9273 x 260
Location: US/Pacific
IRC: mage2k






Re: XLOG's implementation details

От
Erik Jones
Дата:
On Nov 13, 2009, at 3:46 AM, Ozgun Erdogan wrote:

> How strong is the coupling between XLOG entries and database pages?
> That is, assume that I am inserting one row to a database table. Is
> there anyway for me to construct the related XLOG entry before calling
> the heap insert function? Or, are XLOG files conceptually binary diffs
> for database pages, moving forward in time?

The latter.  The converse of your question is much more common, "How
can I reconstruct the statements that changed my database from the
xlog contents", with the same answer.

> Another question that I had relates to XLOG files and tables. If I
> have two databases and one is set up as a slave to the other, is it
> possible for the slave to have fewer tables than the master? If it is
> possible, is that because tables don't share pages?

That depends on how you implement replication.  Since you ask in the
context of xlogs I'll assume you mean a warm standby slave via WAL
shipping and there the answer is no.  Well, you might be able to work
something out by using record-based log shipping but even if that
could work it would take a lot of, well, work.

> Again I'm new to Postgres, and am curious about how stuff works
> underneath the covers. I figured asking this list would be the
> simplest way to figure things out.

Yep :)

Erik Jones, Database Administrator
Engine Yard
Support, Scalability, Reliability
866.518.9273 x 260
Location: US/Pacific
IRC: mage2k