Re: Add error-checking to timestamp_recv
От | Stephen Frost |
---|---|
Тема | Re: Add error-checking to timestamp_recv |
Дата | |
Msg-id | 20040520160705.GX11196@ns.snowman.net обсуждение исходный текст |
Ответ на | Re: Add error-checking to timestamp_recv (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-patches |
* Bruce Momjian (pgman@candle.pha.pa.us) wrote: > Considering all the other things the database is doing, I can't imagine > that would be a measurable improvement. It makes it easier on my client program too which is listening to an ethernet interface and trying to process all of the packets coming in off of it and putting timestamps and header information into the database. The table in the database doesn't have any constraints or primary keys on it or anything, pretty much as simple as I could make it. :) > > The one complaint I do have is that I don't see a way to pass a > > timestamp w/ an explicit timezone in binary format into a table which > > has a 'timestamp with timezone' field. I can pass a binary timestamp > > into a 'timestamp with timezone' field, but it's interpreted as UTC or > > the local timezone (can't remember which atm). > > I still do not understand how this is working. It must be using our > fast path as part of prepare. What language is you client code? It's just plain ol' C. It's a pretty short/simple program, really. It uses libpcap to listen to the interface, checks the type of packet (ethernet, IP, UDP/TCP, etc), copies the binary header values into the structure which it then passes to PQexecPrepared. It's kind of amazing under 2.6, you can actually calculate the delay and bandwidth pretty accurately through a network (7 'backbone' nodes, each with a backbone router, an edge router, and an access router, all in a lab) by listening on two interfaces, one on each side to calculate one-way propagation time. Stephen
Вложения
В списке pgsql-patches по дате отправления: