@Konstantin
1. It's ok in my cases.
2. Not required in my cases.
3. Just require users to use different servers for now I think.
Sometimes(always?) users can be greedy with feature requests.
4. I want magically consistency + failover (I can instruct the client to
retry all masters).
Good-cluster i
On 04/10/2016 09:24 AM, David G. Johnston wrote:
On Sun, Apr 10, 2016 at 8:39 AM, Michael Nolan mailto:htf...@gmail.com>>wrote:
Here's what I did:
\d gold1604_test
Table "uscf.gold1604_test"
Column | Type | Modifiers
+--+---
data | json |
In case it wasn't clear, the sample data was 3 rows of data. (There are
actually around 890K rows in the table pgfutter built from the JSON file.)
-
Mike Nolan
On Sun, Apr 10, 2016 at 8:39 AM, Michael Nolan wrote:
> Here's what I did:
>
> \d gold1604_test
> Table "uscf.gold1604_test"
> Column | Type | Modifiers
> +--+---
> data | json |
>
> Some sample data:
> {"id":"1001","name":"MISNER, J
> NATHAN","st":"NY","exp":"2012-0
On 04/10/2016 06:29 AM, durumd...@gmail.com wrote:
Dear Alban!
2016.04.10. 13:05 keltezéssel, Alban Hertroys írta:
On 10 Apr 2016, at 9:07, Durumdara wrote:
Dear Adrian!
Again. As I see the beginning blocks are removed by mailing system in
the code.
We have an "ourlocks" table which hold
On 04/10/2016 08:39 AM, Michael Nolan wrote:
Here's what I did:
\d gold1604_test
Table "uscf.gold1604_test"
Column | Type | Modifiers
+--+---
data | json |
Some sample data:
{"id":"1001","name":"MISNER, J
NATHAN","st":"NY","exp":"2012-05-31","sts":
"A"} +
{
Here's what I did:
\d gold1604_test
Table "uscf.gold1604_test"
Column | Type | Modifiers
+--+---
data | json |
Some sample data:
{"id":"1001","name":"MISNER, J
NATHAN","st":"NY","exp":"2012-05-31","sts":
"A"} +
{"id":"1002","name":"MISNER,
JUDY","st":"TN","exp
On Sun, Apr 10, 2016 at 6:29 AM, durumd...@gmail.com
wrote:
>
> Dear Alban!
>
>
> 2016.04.10. 13:05 keltezéssel, Alban Hertroys írta:
>
>> On 10 Apr 2016, at 9:07, Durumdara wrote:
>>>
>>> Dear Adrian!
>>>
>>> Again. As I see the beginning blocks are removed by mailing system in
>>> the code.
>>
Heureka! thanks so much for your help, patience and the right hunch. Actually I
am glad now I ran into that stack issue (and you) cause the entire thing is
also much faster now.
I changed my app to emit strings like you suggested and it works, also with
smaller max_stack_depth.
Fwiw, I was no
On 04/10/2016 07:49 AM, Michael Nolan wrote:
On Sun, Apr 10, 2016 at 2:30 AM, David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
On Sat, Apr 9, 2016 at 9:48 PM, Michael Nolan mailto:htf...@gmail.com>>wrote:
2nd Followup: It turns out that loading a table from a JSON
I am not sure if I did it the right way, cause it's my first time stack
tracing, but I did get some more information.
Here's what I did.
1. Switched to ubuntu server 14.04 /w postgres 9.3 server (in a Virtual Box VM)
2. setup postgres and made sure I was able to reproduce the same error.
3. fo
I guess you are right. I have narrowed the query down
to a simple create table, followed by an insert, one text field, one hstore
field and an integer field.
No temporary table, no BEGIN etc. One record, yet the hstore has 40K kvp. No R
involved.
and I still end up with the same error.
Thanks
On Sun, Apr 10, 2016 at 7:49 AM, Michael Nolan wrote:
>
>
> On Sun, Apr 10, 2016 at 2:30 AM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Sat, Apr 9, 2016 at 9:48 PM, Michael Nolan wrote:
>>
>>>
>>> 2nd Followup: It turns out that loading a table from a JSON string is
>>> mo
On Sun, Apr 10, 2016 at 2:30 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sat, Apr 9, 2016 at 9:48 PM, Michael Nolan wrote:
>
>>
>> 2nd Followup: It turns out that loading a table from a JSON string is
>> more complicated than going from a table to JSON, perhaps for good reaso
"Bannert Matthias" writes:
> Fwiw, I was not stubbornly insisting on nesting operators. Actually I
> switched from "=>" to the hstore function cause
> a note in the manual said it was deprecated
> (http://www.postgresql.org/docs/9.0/static/hstore.html). Somehow I must have
> understand that no
Dear Alban!
2016.04.10. 13:05 keltezéssel, Alban Hertroys írta:
On 10 Apr 2016, at 9:07, Durumdara wrote:
Dear Adrian!
Again. As I see the beginning blocks are removed by mailing system in the code.
We have an "ourlocks" table which hold records (TableName, RecordID,
SessionInnerID, TimeS
> On 10 Apr 2016, at 9:07, Durumdara wrote:
>
> Dear Adrian!
>
> Again. As I see the beginning blocks are removed by mailing system in the
> code.
>
> We have an "ourlocks" table which hold records (TableName, RecordID,
> SessionInnerID, TimeStamp, etc, with TableName/RecordID prikey).
>
>
> What would be the effect of suddenly introducing a 1-2 GB of WAL archives
> to the WAL restore folder on the slave? Would there be a big performance
> effect on the incoming queries to the slave? Would the slave be available
> for queries while the WAL logs are restored into the DB?
>
If the Que
On Sat, Apr 9, 2016 at 9:48 PM, Michael Nolan wrote:
>
> 2nd Followup: It turns out that loading a table from a JSON string is
> more complicated than going from a table to JSON, perhaps for good reason.
> There does not appear to be a direct inverse to the row_to_json() function,
> but it wasn'
Dear Adrian!
Again. As I see the beginning blocks are removed by mailing system in the
code.
We have an "ourlocks" table which hold records (TableName, RecordID,
SessionInnerID, TimeStamp, etc, with TableName/RecordID prikey).
If anybody wants to lock record "for long time", "over the transactio
20 matches
Mail list logo
