Andres Freund writes:
> On October 8, 2018 10:14:34 AM PDT, Tom Lane wrote:
>> Surely there is some way that we can directly test whether we're inside
>> a procedure or not? I think the logic should be basically
>> ...
> Seems more reasonable from here.
We are rapidly running out of time to ge
Hi,
On October 8, 2018 10:14:34 AM PDT, Tom Lane wrote:
>Peter Eisentraut writes:
>> On 02/10/2018 16:58, Andres Freund wrote:
>>> It's a bit weird to make this decision based on these two timestamps
>>> differing. For one, it only indirectly seems to be guaranteed that
>>> xactStartTimestamp i
Peter Eisentraut writes:
> On 02/10/2018 16:58, Andres Freund wrote:
>> It's a bit weird to make this decision based on these two timestamps
>> differing. For one, it only indirectly seems to be guaranteed that
>> xactStartTimestamp is even set to anything here (to 0 by virtue of being
>> a globa
On 02/10/2018 16:58, Andres Freund wrote:
> It's a bit weird to make this decision based on these two timestamps
> differing. For one, it only indirectly seems to be guaranteed that
> xactStartTimestamp is even set to anything here (to 0 by virtue of being
> a global var).
Maybe but it seems to b
On Wed, Sep 26, 2018 at 10:55 AM Alvaro Herrera
wrote:
>
> On 2018-Sep-26, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > On 2018-Sep-26, Tom Lane wrote:
> > >> I agree that it would be surprising for transaction timestamp to be newer
> > >> than statement timestamp. So for now at least, I'd
On 2018-09-28 09:35:48 +0200, Peter Eisentraut wrote:
> On 26/09/2018 23:48, Peter Eisentraut wrote:
> > That's certainly a good argument. Note that if we implemented that the
> > transaction timestamp is advanced inside procedures, that would also
> > mean that the transaction timestamp as observ
Hi,
On 2018-10-02 10:55:56 +0200, Peter Eisentraut wrote:
> On 28/09/2018 09:35, Peter Eisentraut wrote:
> >> That's certainly a good argument. Note that if we implemented that the
> >> transaction timestamp is advanced inside procedures, that would also
> >> mean that the transaction timestamp a
On Tue, Oct 2, 2018 at 10:55:56AM +0200, Peter Eisentraut wrote:
> On 28/09/2018 09:35, Peter Eisentraut wrote:
> >> That's certainly a good argument. Note that if we implemented that the
> >> transaction timestamp is advanced inside procedures, that would also
> >> mean that the transaction time
On 28/09/2018 09:35, Peter Eisentraut wrote:
>> That's certainly a good argument. Note that if we implemented that the
>> transaction timestamp is advanced inside procedures, that would also
>> mean that the transaction timestamp as observed in pg_stat_activity
>> would move during VACUUM, for exa
On Wed, Sep 26, 2018 at 09:23:58PM +0200, Daniel Verite wrote:
> Tom Lane wrote:
>
> > I agree that it would be surprising for transaction timestamp to be newer
> > than statement timestamp.
>
> To me it's more surprising to start a new transaction and having
> transaction_timestamp() stil
On 26/09/2018 23:48, Peter Eisentraut wrote:
> On 26/09/2018 17:54, Alvaro Herrera wrote:
>> What could be the use for the transaction timestamp? I think one of the
>> most important uses (at least in pg_stat_activity) is to verify that
>> transactions are not taking excessively long time to compl
On 26/09/2018 17:54, Alvaro Herrera wrote:
> What could be the use for the transaction timestamp? I think one of the
> most important uses (at least in pg_stat_activity) is to verify that
> transactions are not taking excessively long time to complete; that's
> known to cause all sorts of trouble
Tom Lane wrote:
> I agree that it would be surprising for transaction timestamp to be newer
> than statement timestamp.
To me it's more surprising to start a new transaction and having
transaction_timestamp() still pointing at the start of a previous
transaction.
This feels like a side-
On 2018-09-26 12:54:43 -0300, Alvaro Herrera wrote:
> On 2018-Sep-26, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > On 2018-Sep-26, Tom Lane wrote:
> > >> I agree that it would be surprising for transaction timestamp to be newer
> > >> than statement timestamp. So for now at least, I'd be s
On 2018-Sep-26, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2018-Sep-26, Tom Lane wrote:
> >> I agree that it would be surprising for transaction timestamp to be newer
> >> than statement timestamp. So for now at least, I'd be satisfied with
> >> documenting the behavior.
>
> > Really? I t
Alvaro Herrera writes:
> On 2018-Sep-26, Tom Lane wrote:
>> I agree that it would be surprising for transaction timestamp to be newer
>> than statement timestamp. So for now at least, I'd be satisfied with
>> documenting the behavior.
> Really? I thought it was practically obvious that for tran
On 2018-Sep-26, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Sep 26, 2018 at 02:38:25PM +0200, Peter Eisentraut wrote:
> >> We could certainly address this by adding three or four or five new
> >> timestamps that cover all these varieties. But perhaps it's worth
> >> asking what these tim
On 2018-Sep-25, Bruce Momjian wrote:
> Well, it is an entire paragraph, so it might be too much. If you
> download the zip file here:
>
> http://www.wiscorp.com/sql200n.zip
>
> and open 5CD2-02-Foundation-2006-01.pdf, at the top of page 289 under
> General Rules, paragraph label 3 has the
Bruce Momjian writes:
> On Wed, Sep 26, 2018 at 02:38:25PM +0200, Peter Eisentraut wrote:
>> We could certainly address this by adding three or four or five new
>> timestamps that cover all these varieties. But perhaps it's worth
>> asking what these timestamps are useful for and which ones we re
On Wed, Sep 26, 2018 at 02:38:25PM +0200, Peter Eisentraut wrote:
> On 22/09/2018 00:35, Bruce Momjian wrote:
> > I have always thought of clock/statement/transation as decreasing levels
> > of time precision, and it might be odd to change that. I don't think we
> > want to change the behavior of
On 22/09/2018 00:35, Bruce Momjian wrote:
> I have always thought of clock/statement/transation as decreasing levels
> of time precision, and it might be odd to change that. I don't think we
> want to change the behavior of statement_timestamp() in procedures, so
> that kind of requires us not to
On Tue, Sep 25, 2018 at 03:01:31PM -0700, David G. Johnston wrote:
> On Sat, Sep 22, 2018 at 5:27 PM, Bruce Momjian wrote:
>
> On Fri, Sep 21, 2018 at 06:35:02PM -0400, Bruce Momjian wrote:
> > Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
> > procedures? Do w
On 2018-09-25 14:50:02 -0700, Andres Freund wrote:
> ISTM this is an issue that belongs on the open items list. Peter, could
> you comment?
Done so, per discussion with the rest of the RMT.
On Sat, Sep 22, 2018 at 5:27 PM, Bruce Momjian wrote:
> On Fri, Sep 21, 2018 at 06:35:02PM -0400, Bruce Momjian wrote:
> > Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
> > procedures? Do we need another function that does advance on procedure
> > commit?
>
> I found a se
Hi,
On 2018-09-20 19:40:40 -0400, Bruce Momjian wrote:
> This function shows that only clock_timestamp() advances inside a
> procedure, not statement_timestamp() or transaction_timestamp():
>
> CREATE OR REPLACE PROCEDURE test_timestamp () AS $$
> DECLARE
> str TEXT;
>
On Fri, Sep 21, 2018 at 06:35:02PM -0400, Bruce Momjian wrote:
> Does the SQL standard have anything to say about CURRENT_TIMESTAMP in
> procedures? Do we need another function that does advance on procedure
> commit?
I found a section in the SQL standards that talks about it, but I don't
underst
On Fri, Sep 21, 2018 at 06:28:22AM -0400, Bruce Momjian wrote:
> On Fri, Sep 21, 2018 at 02:34:25PM +0900, Michael Paquier wrote:
> > On Thu, Sep 20, 2018 at 10:12:06PM -0700, Andres Freund wrote:
> > > Isn't the point that transaction_timestamp() does *not* currently change
> > > its value, even t
On Fri, Sep 21, 2018 at 02:34:25PM +0900, Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 10:12:06PM -0700, Andres Freund wrote:
> > Isn't the point that transaction_timestamp() does *not* currently change
> > its value, even though the transaction (although not the outermost
> > statement) has fi
On Thu, Sep 20, 2018 at 10:12:06PM -0700, Andres Freund wrote:
> Isn't the point that transaction_timestamp() does *not* currently change
> its value, even though the transaction (although not the outermost
> statement) has finished?
Ouch, yes. I see the point now. Indeed that's strange to not h
Hi,
On 2018-09-21 13:55:36 +0900, Michael Paquier wrote:
> On Thu, Sep 20, 2018 at 07:40:40PM -0400, Bruce Momjian wrote:
> > This surprised me since I expected a new timestamp after commit. Is
> > this something we want to change or document? Are there other
> > per-transaction behaviors we sho
On Thu, Sep 20, 2018 at 07:40:40PM -0400, Bruce Momjian wrote:
> This surprised me since I expected a new timestamp after commit. Is
> this something we want to change or document? Are there other
> per-transaction behaviors we should adjust?
I don't quite follow your argument here. clock_times
This function shows that only clock_timestamp() advances inside a
procedure, not statement_timestamp() or transaction_timestamp():
CREATE OR REPLACE PROCEDURE test_timestamp () AS $$
DECLARE
str TEXT;
BEGIN
WHILE TRUE LOOP
32 matches
Mail list logo
