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-søgning:
http://toolbar.msn.dk


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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@postgresql.org so that your
> message can get through to the mailing list cleanly

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

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
>


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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/s...-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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org