On Thu, Jun 30, 2011 at 6:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think the time problems are more complex than said. The patch relies
>> upon transaction completion times, but not all WAL records have a time
>> attached to them. Plus you only used commits anyway, not sure why.
>
> For the same reason we do that with the recovery_target_* code -
> replaying something like a heap insert or heap update doesn't change
> the user-visible state of the database, because the records aren't
> visible anyway until the commit record is replayed.
>
>> Some actions aren't even transactional, such as DROP DATABASE, amongst
>
> Good point. We'd probably need to add a timestamp to the drop
> database record, as that's a case that people would likely want to
> defend against with this feature.
>
>> others. Consecutive records can be hours apart, so it would be
>> possible to delay on some WAL records but then replay records that
>> happened minutes ago, then wait hours for the next apply. So this
>> patch doesn't do what it claims in all cases.
You misread my words above, neglecting the "amongst others" part.
I don't believe you'll be able to do this just by relying on
timestamps on WAL records because not all records carry timestamps and
we're not going to add them just for this.
It's easier to make this work usefully using pg_standby.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services