From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org, eg(at)cybertec(dot)at |
Subject: | Re: Constant WAL replay |
Date: | 2005-04-24 06:28:16 |
Message-ID: | 25855.1114324096@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres(at)cybertec(dot)at> writes:
> We have toyed around with PostgreSQL's WAL structure and we are
> wondering whether it is (theoretically) possible to replay WAL records
> coming from a remote host while a system is working in read only mode.
There's been some idle speculation about that, and offhand I don't know
of any showstopper reasons why it couldn't be done ... but no one's
actually looked into making it happen. Feel free ;-)
> Which kind of modifications are necessary to
> replay and answer at the same time? (assuming that locks and
> transactional information are available on the slave).
I think you should definitely assume that locks are *not* available, and
probably not any live transaction info. The discussions before included
the idea of being able to do queries against a known-broken,
non-recoverable database without making it any worse than it was before.
In the current code there is no such thing as a hard read-only behavior
--- for example we will try to update commit-status hint bits no matter
what. Allowing that to be turned off would be interesting for a number
of purposes, such as burning a database onto CD.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-04-24 06:40:09 | Re: Constant WAL replay |
Previous Message | Hans-Jürgen Schönig | 2005-04-24 06:10:34 | Constant WAL replay |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-04-24 06:40:09 | Re: Constant WAL replay |
Previous Message | Hans-Jürgen Schönig | 2005-04-24 06:10:34 | Constant WAL replay |