Hi Frank:
On Tue, Mar 15, 2016 at 6:57 AM, Frank Millman wrote:
> 2. As pointed out, there are two forms of the power function.
>
> test=> select pg_typeof(power(10, 2));
> pg_typeof
> --
> double precision
>
> test=> select pg_typeof(power(10., 2));
> pg_typeof
> --
>
On Tue, Mar 15, 2016 at 12:02 PM, Francisco Olarte wrote:
> Hi Frank:
>
> This may byte you any day, so I wuld recommend doing
>
> s=> select v, pg_typeof(v) from (select floor(4.725 * power(cast(10 as
> numeric), 2) + 0.5)) as aux(v);
> v | pg_typeof
> -+---
> 473 | numeric
>
Thank you, I was in direct contact with the author. All my issues and
questions got sorted out. it's working perfectly!
Thank you, Johann
2016-03-13 18:32 GMT+01:00 Dane Foster :
> Hello,
>
>
> On Sat, Mar 12, 2016 at 11:40 AM, Johann Höchtl
> wrote:
>
>> I fear I have an involved challenge c
Thank you both for the advice.
pg_rewind is a nice utility and not only more robust than what I came up with
but also easier to use and avoids need to shut down new Primary.
Re editing the wiki, I do have a community account but it seems I need more
than that :
==> Editing this wik
On 03/15/2016 06:54 AM, John Lumby wrote:
Thank you both for the advice.
pg_rewind is a nice utility and not only more robust than what I came up with
but also easier to use and avoids need to shut down new Primary.
Re editing the wiki, I do have a community account but it seems I need more
th
I'm likely abusing the psql program. What I have is an awk program which
reads a file and produces a number of INSERT INTO commands. I then feed
these commands into psql to execute them. Yes, a Perl program would be a
better idea. Anyway, sometimes the commands are rejected due to some
problem, suc
On 03/15/2016 07:33 AM, John McKown wrote:
I'm likely abusing the psql program. What I have is an awk program which
reads a file and produces a number of INSERT INTO commands. I then feed
these commands into psql to execute them. Yes, a Perl program would be a
better idea. Anyway, sometimes the c
On Tue, Mar 15, 2016 at 9:38 AM, Adrian Klaver
wrote:
> On 03/15/2016 07:33 AM, John McKown wrote:
>
>> I'm likely abusing the psql program. What I have is an awk program which
>> reads a file and produces a number of INSERT INTO commands. I then feed
>> these commands into psql to execute them.
On Tue, Mar 15, 2016 at 10:49 AM, John McKown
wrote:
> On Tue, Mar 15, 2016 at 9:38 AM, Adrian Klaver
> wrote:
>
>> On 03/15/2016 07:33 AM, John McKown wrote:
>>
>>> I'm likely abusing the psql program. What I have is an awk program which
>>> reads a file and produces a number of INSERT INTO com
On Tue, Mar 15, 2016 at 9:57 AM, Melvin Davidson
wrote:
>
>
> On Tue, Mar 15, 2016 at 10:49 AM, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
>> On Tue, Mar 15, 2016 at 9:38 AM, Adrian Klaver > > wrote:
>>
>>> On 03/15/2016 07:33 AM, John McKown wrote:
>>>
I'm likely abusing the psq
John McKown wrote:
> I'm likely abusing the psql program. What I have is an awk program which
> reads a file and produces a
> number of INSERT INTO commands. I then feed these commands into psql to
> execute them. Yes, a Perl
> program would be a better idea. Anyway, sometimes the commands are re
Not best practice but perhaps viable...
In the target table add a serial datatype column as part of the unique
constraint.
Do not populate this column explicitly on insert, but have the db do it for
you. It will allocate an incremental (unique) value automatically on insert.
But I think you
Hi Melvin:
On Tue, Mar 15, 2016 at 3:57 PM, Melvin Davidson wrote:
> What you really want is
> "ON_ERROR_STOP
...
> So just
> SET ON_ERROR_STOP = ON
> before any other statements
IIRC you are right with the variable ... BUT .. it is a psql setting,
not a session setting, so he'll probably need t
Hello,
since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3.
Everything is fine except the daily backup. When calling pg_dump as part of a
cron job pg_dump crashes:
2016-03-15 01:00:02 CETFATAL: semctl(23232524, 3, SETVAL, 0) failed: Invalid
argument
2016-03-15 01:00:02 CE
I have already hit a different problem with pg_rewind and would like to check
my understanding.
The problem is, on 9.5.1 , pg_rewind fails to find a log file that it thinks
it needs :
pg_rewind -D ${pg_cluster_dir} --source-server='host=10.19.0.1 port=5432 xxx'
-P --debug
__
On Tue, Mar 15, 2016 at 4:10 PM, Matthias Schmitt
wrote:
> since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3.
> Everything is fine except the daily backup. When calling pg_dump as part of a
> cron job pg_dump crashes:
>
> 2016-03-15 01:00:02 CETFATAL: semctl(23232524, 3,
On Tue, Mar 15, 2016 at 5:14 PM, John Lumby wrote:
> But my question is, given that the divergence point was 2B60,
> why is it looking for a file earlier than that?
(please do not top-post, this is annoying as it breaks the logic of the thread)
pg_rewind begins scanning WAL records not at th
I've been working with PG 9.1.8 for two years now, mainly asynchronous
replication. Recently, an IT admin of another group contested that the
PG's asynchronous replication can result in loss of data in a 1-node
failure. After re-readinG the documentation, I cannot determine to what
extent this is t
> Date: Tue, 15 Mar 2016 17:21:50 +0100
> Subject: Re: how to switch old replication Master to new Standby after
> promoting old Standby - pg_rewind log file missing
> From: michael.paqu...@gmail.com
> To: johnlu...@hotmail.com
> CC: pgsql-general@postgresql.org; oleksandr.shul...@zalando.de;
> a
On Tue, 2016-03-15 at 16:10 +0100, Matthias Schmitt wrote:
> Hello,
>
> since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian
> 8.3. Everything is fine except the daily backup. When calling pg_dump
> as part of a cron job pg_dump crashes:
>
> 2016-03-15 01:00:02 CETFATAL: semctl(2
>
>
>>
> Not reading the documentation for functions you've never heard of makes
> the list.
>
> David J.
>
INSERT INTO junk.test1 (account_id, code, info)SELECT account_id,
uuid_generate_v4(), infoFROM junk.test2;
It works but I get data like:
abc77f31-0ee6-44fd-b954-08a3a3aa7b28
f307fb42-23e5-
On Tue, Mar 15, 2016 at 2:01 PM, drum.lu...@gmail.com
wrote:
>
>>>
>> Not reading the documentation for functions you've never heard of makes
>> the list.
>>
>> David J.
>>
>
> INSERT INTO junk.test1 (account_id, code, info)SELECT account_id,
> uuid_generate_v4(), infoFROM junk.test2;
>
> It wor
On 16 March 2016 at 10:30, David G. Johnston
wrote:
> On Tue, Mar 15, 2016 at 2:01 PM, drum.lu...@gmail.com <
> drum.lu...@gmail.com> wrote:
>
>>
>>> Not reading the documentation for functions you've never heard of makes
>>> the list.
>>>
>>> David J.
>>>
>>
>> INSERT INTO junk.test1 (accou
On Tue, Mar 15, 2016 at 2:35 PM, drum.lu...@gmail.com
wrote:
>
>
> On 16 March 2016 at 10:30, David G. Johnston
> wrote:
>
>> On Tue, Mar 15, 2016 at 2:01 PM, drum.lu...@gmail.com <
>> drum.lu...@gmail.com> wrote:
>>
>>>
>
Not reading the documentation for functions you've never heard o
>
>>>
>> I wouldn't ask if I wouldn't have tested it!
>>
>> Will have a look.
>>
>>
> I didn't asked if you tested what you did post. I asked if you tried
> anything else before asking to be fed the answer. If you did it would be
> nice to include those other attempts.
>
> David J.
>
>
>
It
On 3/15/2016 2:48 PM, drum.lu...@gmail.com wrote:
It's already working:
INSERT INTO junk.wm_260_billables2 (account_id, code, info)
SELECT account_id, 'test_' || uuid_generate_v4(), info
FROM junk.wm_260_billables1;
BUT.. I'm getting a very long UUID - Would like some smaller
On Tue, Mar 15, 2016 at 2:48 PM, drum.lu...@gmail.com
wrote:
>
>
>>> I wouldn't ask if I wouldn't have tested it!
>>>
>>> Will have a look.
>>>
>>>
>> I didn't asked if you tested what you did post. I asked if you tried
>> anything else before asking to be fed the answer. If you did it w
On Wed, Mar 16, 2016 at 6:26 AM, otheus uibk wrote:
> I've been working with PG 9.1.8 for two years now, mainly asynchronous
> replication. Recently, an IT admin of another group contested that the PG's
> asynchronous replication can result in loss of data in a 1-node failure.
> After re-readinG t
Your results are close enough to mine, I think, to prove the point. And, I
agree that the EDB benchmark is not necessary reflective of a real-world
scenario.
However, the cache I'm referring to is PG's shared_buffer cache. You can see
the first run of the select causing a lot of disk reads.
29 matches
Mail list logo
