Re: [GENERAL] How to test SSL cert from CA?

;s protocol, but it should be straight forward to do so.-JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] How to test SSL cert from CA?

trusts the issuer's root? Some require explicit configurastion of that. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] localtime ?

es? It is 9.3 vs 9.4 on the same box. OE> You can reconfigure the timezone for the machine: OE> sudo dpkg-reconfigure tzdata And /etc/localtime is a copy of /usr/share/zoneinfo/Zulu. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql

Re: [GENERAL] localtime ?

>>>>> "AK" == Adrian Klaver writes: AK> So from the command line on the non-UTC machine what does the below show: AK> ~>date It is the same machine, just the old 9.3 cluster vs the new 9.4 cluster. date returns: Mon Jun 15 19:37:14 UTC 2015 -Jim

Re: [GENERAL] localtime ?

files. As I wrote the diff between the not working /etc/postgresql/9.3/ snd the working /etc/postgresql/9.4/ is only things like 9.3 vs 9.4 in path names, the port number and the addition in 9.4 of dynamic_shared_memory_type = mmap. Whatever caused this is not in the config files. -JimC -- James

Re: [GENERAL] localtime ?

sourceline | 508 The 9.3 vs 9.4 in sourcefile is the only difference between the two clusters on that box. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.post

Re: [GENERAL] localtime ?

directories doesn't show any relevant differences. Just directory names and the port number. I'll leave the old cluster stopped but around for a while in case there are any other queries which might explain the differences. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 --

[GENERAL] localtime ?

# share/timezonesets/. ` So how do I convince it always to use utc? (I did that test w/ ~/.psqlrc moved out of the way, but it does nothing related to tz.) Thanks. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgs

Re: [GENERAL] now() vs 'epoch'::timestamp

o, I guess that is another nail in reltime's coffin. now() - to_timestamp(1427999266) worked correctly, but that is not unexpected given to_timestamp's definition. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql

Re: [GENERAL] now() vs 'epoch'::timestamp

>>>>> "DGJ" == David G Johnston writes: DGJ> ​What timezone is your server set to - and/or the client requesting the DGJ> calculation? Everything is in UTC. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (p

Re: [GENERAL] now() vs 'epoch'::timestamp

SC> side of the calculation. It wasn't the microsecond difference I asked about, it was the 6 hour difference. The original, ancient code I used needed to return integer seconds. And it always gave answers consistant with date +%s. What I haven't determined is why conver

Re: [GENERAL] now() vs 'epoch'::timestamp

Thanks. Back when I first needed it (years ago), that long line was the only recomendation I could find. SF> The only thing I'd say about this is that you *really* want to use SF> timestamptz in PG for storing timestamps. I normally do, but this table hasn't changed in ye

[GENERAL] now() vs 'epoch'::timestamp

all have localtime == UTC. Am I missing something obvious? Also, is there any way to get the equiv of date +%s%N as a numeric or a double precision? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To

Re: [GENERAL] Replacing Ordinal Suffixes

t GW> (1 row) The E'' syntax eats your backslashes. For that version, try just: SELECT REGEXP_REPLACE(LOWER('300 North 126th Street'),'(\d)(st|nd|rd|th)', '\1', 'g'); -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] [GENERAL] Floating point error

hexidecimal notation for floats exists. The printf format flag is %a for miniscule and %A for majuscule. The result of 1./3. is 0xa.aabp-5. This site has some info and a conversion demo: http://gregstoll.dyndns.org/~gregstoll/floattohex/ -JimC -- James Cloos OpenPGP: 1024D/E

Re: [GENERAL] Floating point error

ared to match when running queries in psql. Incidently, this is a prime example of where the hexidecimal format for floats would benefit pg, as it makes the text format for floats just as suitable for round-tripping as the binary format. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 --

Re: [GENERAL] Floating point error

sql(1) uses something like printf("%.4f",...) whereas your java app calls a routing which works more like "%.7f". (The wire format for floats is the same as they are stored, not a text representation thereof.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- Sent v

Re: [GENERAL] Anyone using "POSIX" time zone offset capability?

tamps are technically ambiguous as to whether the specify real UTC-based time or POSIX time (Currently there is a 23-second difference between the two.) -- James Cloos <[EMAIL PROTECTED]> OpenPGP: 0xED7DAEA6 ---(end of broadcast)--

[GENERAL] rh7.3 binaries

Does anyone provide binary rpms for rh-7.3 for recent version of pgsql? (My (aging) rh73 box is too small to compile it.) I need to change the setup on that box to mirror a db from another via slony. The master is at 8.0.x. In case an rh73 compatable rpm is not available, will slony work ok giv