Re: Unexpected Statement Caching with CURRENT_TIMESTAMP

Sorry it doesn't work. I connect to 192.168.0.8 but Wireshark doesn't
caputre anything on the database port.

I'll try to reproduced the problem on linux.

Dave Cramer wrote:
>James,
>
>Change the connection so that it connects to the ethernet device on
>the box, then Wireshark can listen to it.
>
>--dc--
>On 10-Aug-06, at 6:45 AM, James Im wrote:
>
>>I've done some more tests and I think that I can say that a same
>>connection is not used by several thread at the same time.
>>However different connections are being used by several threads at the
>>same time.
>>
>>>Can you capture the network traffic between the server and JDBC driver?
>>I don't know how to do that on Windows. Wireshark cannot listen to the
>>windows loopback interface.
>>
>>Have you seen the thread dump? Does it helps you at all?
>>
>>_________________________________________________________________
>>Ta' p udsalg ret rundt p MSN Shopping: http://shopping.msn.dk -
>>her finder du altid de bedste priser
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/docs/faq
>>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>

_________________________________________________________________
Find dine dokumenter lettere med MSN Toolbar med Windows-pc-sgning:
http://toolbar.msn.dk

Yeah, Windows special-cases even non-loopback local network traffic and
bypasses the packet sniffer. I once had to do some iptables magic with
a Linux box to bounce local traffic off a remote server and back in so I
could sniff it.

-- Mark

On Thu, 2006-08-10 at 14:55 +0000, James Im wrote:
> Sorry it doesn't work. I connect to 192.168.0.8 but Wireshark doesn't
> caputre anything on the database port.
>
> I'll try to reproduced the problem on linux.
>
> Dave Cramer wrote:
> >James,
> >
> >Change the connection so that it connects to the ethernet device on
> >the box, then Wireshark can listen to it.
> >
> >--dc--
> >On 10-Aug-06, at 6:45 AM, James Im wrote:
> >
> >>I've done some more tests and I think that I can say that a same
> >>connection is not used by several thread at the same time.
> >>However different connections are being used by several threads at the
> >>same time.
> >>
> >>>Can you capture the network traffic between the server and JDBC driver?
> >>I don't know how to do that on Windows. Wireshark cannot listen to the
> >>windows loopback interface.
> >>
> >>Have you seen the thread dump? Does it helps you at all?
> >>
> >>_________________________________________________________________
> >>Ta' p udsalg ret rundt p MSN Shopping: http://shopping.msn.dk -
> >>her finder du altid de bedste priser
> >>
> >>
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 3: Have you checked our extensive FAQ?
> >>
> >> http://www.postgresql.org/docs/faq
> >>
> >
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
>
> _________________________________________________________________
> Find dine dokumenter lettere med MSN Toolbar med Windows-pc-sgning:
> http://toolbar.msn.dk
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

I'm executing 'SELECT CURRENT_TIMESTAMP' from a statement object with
auto commit off and prepare threshold set to 1. I'm finding that the
result comes back the same for after multiple calls and instantiations
of the statement object(The same happens for a prepared statement).
However this does not occur when I perform a commit before or after
every call.

Is this expected behaviour?

Nicholas,

Yes this is expected behaviour. The time is the time when you started
the transaction. It has nothing to do with JDBC.

Dave
On 10-Aug-06, at 8:37 PM, Nicholas E. Wakefield wrote:

> I'm executing 'SELECT CURRENT_TIMESTAMP' from a statement object with
> auto commit off and prepare threshold set to 1. I'm finding that the
> result comes back the same for after multiple calls and instantiations
> of the statement object(The same happens for a prepared statement).
> However this does not occur when I perform a commit before or after
> every call.
>
> Is this expected behaviour?
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

Hi, Nicolas,

Nicholas E. Wakefield wrote:
> I'm executing 'SELECT CURRENT_TIMESTAMP' from a statement object with
> auto commit off and prepare threshold set to 1. I'm finding that the
> result comes back the same for after multiple calls and instantiations
> of the statement object(The same happens for a prepared statement).
> However this does not occur when I perform a commit before or after
> every call.
>
> Is this expected behaviour?

Yes, it's expected, intended and documented in the PostgreSQL docs:
http://www.postgresql.org/docs/8.1/static/functions-datetime.html

SELECT timeofday(); returns a clock that advances even during
transactions. As it returns a textual representation, you may need to
cast it to a timestamp in some query contexts, though:

select timeofday(); -- returns text
select timeofday()::timestamp; -- returns timestamp - postgresql variant
select CAST(timeofday() AS timestamp) ; -- returns timestamp in sql99

HTH,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org