| From: | Erik Jones <ejones(at)engineyard(dot)com> |
|---|---|
| To: | Ozgun Erdogan <ozgune(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: XLOG's implementation details |
| Date: | 2009-11-14 18:51:37 |
| Message-ID: | BADBF1ED-E2CE-4258-AB0A-FD156967C3D2@engineyard.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Erik Jones | 2009-11-14 18:53:00 | Re: XLOG's implementation details |
| Previous Message | Greg Stark | 2009-11-14 18:48:29 | Re: Upgrading databases |