On Sat, Aug 26, 2017 at 6:28 PM, Gabriel Furstenheim Milerud
wrote:
> Not sure I follow. Do you have an example that I could check?
> I have the impression that my problem is that no .gcda files are created. If
> I just run the lcov part:
> lcov -d . -c -o lcov.info
>
> I get
>Found gcov v
On Sun, Aug 27, 2017 at 12:12 AM, Tom Lane wrote:
> Michael Paquier writes:
>> On Fri, Aug 25, 2017 at 8:10 AM, Tom Lane wrote:
>>> I think the real problem occurs where we realloc the array bigger.
>
>> Looking at the surroundings, I think that it would be nice to have
>> pqAddTuple and PQsetva
Hi,
How is this done in v8.4? (I tried adding "date; rsync ..." but pg didn't
like that *at all*.)
Thanks
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
thanks. didn't realise they were different. I discovered the difference
when using a MD5 comparison between the 2 databases in a C++ utility.
All values were matching apart from dates.
Cheers
P
On Sun, 27 Aug 2017 at 21:35 Tom Lane wrote:
> Peter Koukoulis writes:
> > I am unsure as to why th
Peter Koukoulis writes:
> I am unsure as to why the hrs, mins and seconds do not appear for a date
> column.
Uh, because it's a date.
> When performing the exact same queries in Oracle, I get the full date
> formatted to "mmddhh24miss", but cannot get the same for PostgreSQL,
> for example:
2017-08-27 18:32 GMT+03:00 Dmitry Igrishin :
>
>
> 2017-08-27 18:13 GMT+03:00 Tom Lane :
>
>> Dmitry Igrishin writes:
>> > I'm working on finishing beta release of my C++ API for PostgreSQL. The
>> > library
>> > have simple SQL parser (preprocessor) to support the queries like that:
>>
>> > SE
Hi
I am unsure as to why the hrs, mins and seconds do not appear for a date
column. I am using PostgreSQL 9.6.3 on Linux.
When performing the exact same queries in Oracle, I get the full date
formatted to "mmddhh24miss", but cannot get the same for PostgreSQL,
for example:
ft_node=# create ta
## Ron Johnson (ron.l.john...@cox.net):
> > On today's LANs, total archiving time is dominated by connection
> > startup time (how long does it take to transfer 16MB on a 10GbE link?
> > See...).
>
> And if we've only got a WAN link from one DC to another 360 miles away?
Well... TCP handshake wi
On 08/27/2017 02:23 PM, Christoph Moench-Tegeder wrote:
## Ron Johnson (ron.l.john...@cox.net):
Everything I've read says that you should use "rsync -a". Is there
any reason why we can't/shouldn't use "rsync -az" so as to reduce
transfer time?
On today's LANs, total archiving time is dominate
## Ron Johnson (ron.l.john...@cox.net):
> Everything I've read says that you should use "rsync -a". Is there
> any reason why we can't/shouldn't use "rsync -az" so as to reduce
> transfer time?
On today's LANs, total archiving time is dominated by connection
startup time (how long does it take t
Hi,
(Yes, its old. Nothing I can do about that.)
Everything I've read says that you should use "rsync -a". Is there any
reason why we can't/shouldn't use "rsync -az" so as to reduce transfer time?
Also, does that change require a full restart (difficult with production
systems)?
Thanks
2017-08-27 18:13 GMT+03:00 Tom Lane :
> Dmitry Igrishin writes:
> > I'm working on finishing beta release of my C++ API for PostgreSQL. The
> > library
> > have simple SQL parser (preprocessor) to support the queries like that:
>
> > SELECT :"column", $tag$constant string$tag$
> > FROM :tab
Dmitry Igrishin writes:
> I'm working on finishing beta release of my C++ API for PostgreSQL. The
> library
> have simple SQL parser (preprocessor) to support the queries like that:
> SELECT :"column", $tag$constant string$tag$
> FROM :tables
> WHERE name LIKE :'name' AND
> se
Hi all,
I'm working on finishing beta release of my C++ API for PostgreSQL. The
library
have simple SQL parser (preprocessor) to support the queries like that:
SELECT :"column", $tag$constant string$tag$
FROM :tables
WHERE name LIKE :'name' AND
sex = $1 AND
age > $ag
14 matches
Mail list logo
