On Wed, Nov 10, 2010 at 12:57 PM, Robert Haas wrote:
> On Tue, Nov 9, 2010 at 8:55 PM, Fujii Masao wrote:
>> On Wed, Nov 10, 2010 at 3:28 AM, Josh Berkus wrote:
>>> On 11/9/10 5:44 AM, Fujii Masao wrote:
But, pg_last_xact_replay_timestamp is more intuitive for many people?
If so, let's
On Tue, Nov 9, 2010 at 8:55 PM, Fujii Masao wrote:
> On Wed, Nov 10, 2010 at 3:28 AM, Josh Berkus wrote:
>> On 11/9/10 5:44 AM, Fujii Masao wrote:
>>> But, pg_last_xact_replay_timestamp is more intuitive for many people?
>>> If so, let's change
>>> the name.
>>
>> *None* of these names are intuit
On Wed, Nov 10, 2010 at 3:28 AM, Josh Berkus wrote:
> On 11/9/10 5:44 AM, Fujii Masao wrote:
>> But, pg_last_xact_replay_timestamp is more intuitive for many people?
>> If so, let's change
>> the name.
>
> *None* of these names are intuitive. So let's just go for consistency.
OK. I changed the n
On 11/9/10 5:44 AM, Fujii Masao wrote:
> But, pg_last_xact_replay_timestamp is more intuitive for many people?
> If so, let's change
> the name.
*None* of these names are intuitive. So let's just go for consistency.
If you want an intuitive name, it would be:
pg_replication_log_timestamp()
--
On Tue, Nov 9, 2010 at 1:05 AM, Robert Haas wrote:
> On Mon, Nov 8, 2010 at 6:00 AM, Fujii Masao wrote:
>> On Sat, Nov 6, 2010 at 9:58 AM, Robert Haas wrote:
>>> This looks good, but how about adding:
>>>
>>> if (!RecoveryInProgress())
>>> PG_RETURN_NULL();
>>>
>>> Otherwise, if we're in Hot
On Mon, Nov 8, 2010 at 6:00 AM, Fujii Masao wrote:
> On Sat, Nov 6, 2010 at 9:58 AM, Robert Haas wrote:
>> This looks good, but how about adding:
>>
>> if (!RecoveryInProgress())
>> PG_RETURN_NULL();
>>
>> Otherwise, if we're in Hot Standby mode for a while and then enter
>> normal running, wo
On Sat, Nov 6, 2010 at 9:58 AM, Robert Haas wrote:
> This looks good, but how about adding:
>
> if (!RecoveryInProgress())
> PG_RETURN_NULL();
>
> Otherwise, if we're in Hot Standby mode for a while and then enter
> normal running, wouldn't this still return a (stale) value?
Yes, but isn't tha
On Thu, Nov 4, 2010 at 9:00 PM, Fujii Masao wrote:
> On Thu, Nov 4, 2010 at 10:27 AM, Fujii Masao wrote:
>> On Tue, Nov 2, 2010 at 10:38 PM, Dimitri Fontaine
>> wrote:
>>> Fujii Masao writes:
After 9.0 release, I've often heard that some people want to know
how far transactions have b
On Thu, Nov 4, 2010 at 10:27 AM, Fujii Masao wrote:
> On Tue, Nov 2, 2010 at 10:38 PM, Dimitri Fontaine
> wrote:
>> Fujii Masao writes:
>>> After 9.0 release, I've often heard that some people want to know
>>> how far transactions have been replayed in the standby in timestamp
>>> rather than LS
On Tue, Nov 2, 2010 at 10:38 PM, Dimitri Fontaine
wrote:
> Fujii Masao writes:
>> After 9.0 release, I've often heard that some people want to know
>> how far transactions have been replayed in the standby in timestamp
>> rather than LSN. So I'm thinking to include the function which returns
>> t
Fujii Masao writes:
> After 9.0 release, I've often heard that some people want to know
> how far transactions have been replayed in the standby in timestamp
> rather than LSN. So I'm thinking to include the function which returns
> the timestamp of the last applied transaction (i.e., commit/abort
Hi,
After 9.0 release, I've often heard that some people want to know
how far transactions have been replayed in the standby in timestamp
rather than LSN. So I'm thinking to include the function which returns
the timestamp of the last applied transaction (i.e., commit/abort WAL
record) in the core
12 matches
Mail list logo
