On Tue, Sep 23, 2014 at 10:38 PM, Rajeev rastogi
wrote:
> On 22 September 2014 19:17, Heikki Linnakangas wrote:
>
>> On 09/22/2014 04:45 PM, Tom Lane wrote:
>> > Heikki Linnakangas writes:
>> >> On 09/22/2014 07:47 AM, Rajeev rastogi wrote:
>> >>> So my proposal is to skip the condition check on
On Sat, Oct 25, 2014 at 1:20 AM, Heikki Linnakangas
wrote:
> Argh, looks like I forgot the actual code changes required.
> I just noticed that pg_controldata and pg_resetxlog don't check for extra
> arguments:
> $ pg_resetxlog data fds sdf sdf
> Transaction log reset
I think that it would be good
Tom,
I believe there are two main concerns that you raise, addressed below:
First:
> It needs to be a more constrained syntax.
> One possibility is to insist that the wildcard be only a part
> of the name string, eg
>
> [myservers-%]
> host=%.domain.com
> port=5433
> user=admi
Peter Eisentraut writes:
> On 10/25/14 2:52 PM, Tom Lane wrote:
>> And a bit of experimentation later: it seems that on Yosemite (and
>> probably earlier OS X versions), "localhost" maps to all three of these
>> addresses:
>> 127.0.0.1
>> ::1
>> fe80:1::1
>> Binding to 127.0.0.1 does not trigger t
On 10/25/14 2:52 PM, Tom Lane wrote:
> And a bit of experimentation later: it seems that on Yosemite (and
> probably earlier OS X versions), "localhost" maps to all three of these
> addresses:
> 127.0.0.1
> ::1
> fe80:1::1
> Binding to 127.0.0.1 does not trigger the firewall popup
On Sun, Oct 26, 2014 at 12:12 PM, Tom Lane wrote:
> Haribabu Kommi writes:
>> Thanks for the details. I am sorry It is not proc_exit. It is the exit
>> callback functions that can cause problem.
>
>> The following is the callstack where the problem can happen, if the signal
>> handler is called a
Haribabu Kommi writes:
> Thanks for the details. I am sorry It is not proc_exit. It is the exit
> callback functions that can cause problem.
> The following is the callstack where the problem can happen, if the signal
> handler is called after the spin lock took by the worker.
> Breakpoint 1, 0x
On Sun, Oct 26, 2014 at 10:17 AM, Andres Freund wrote:
> Hi,
>
> On 2014-10-26 08:52:42 +1100, Haribabu Kommi wrote:
>> I am thinking of a possible problem with shm_mq structure spin lock.
>> This is used for protecting the shm_mq structure.
>>
>> During the processing of any code under the spin l
Hi,
On 2014-10-26 08:52:42 +1100, Haribabu Kommi wrote:
> I am thinking of a possible problem with shm_mq structure spin lock.
> This is used for protecting the shm_mq structure.
>
> During the processing of any code under the spin lock, if the process
> receives SIGQUIT signal then it is leading
My logical decoding plugin is occasionally getting this error
"could not resolve cmin/cmax of catalog tuple"
I get this when my output plugin is trying to read one of the user
defined catalog tables (user_catalog_table=true)
I am not sure if this is a bug in the time-travel support in the l
I sometimes get the error "snapshot too large" from my logical
replication walsender process when in response to a CREATE_REPLICATION_SLOT.
This is in SnapBuildExportSnapshot in snapbuild.c
newxcnt is 212 at that point
I have max_connections = 200
procArray->maxProcs=212
Should we be testing
Hi Hackers,
I am thinking of a possible problem with shm_mq structure spin lock.
This is used for protecting the shm_mq structure.
During the processing of any code under the spin lock, if the process
receives SIGQUIT signal then it is leading to a dead lock situation.
SIGQUIT->proc_exit->shm_mq
On 25 October 2014 19:19, Thom Brown wrote:
> On 25 October 2014 13:28, Alvaro Herrera wrote:
>
>> Thom Brown wrote:
>> > On 24 October 2012 18:17, Tom Lane wrote:
>> >
>> > > Marco Nenciarini writes:
>> > > > Please find the attached refreshed patch (v2) which fixes the loose
>> ends
>> > > >
On 24 Oct 2014 20:28, "Robert Haas" wrote:
>
> You could perhaps try to create a command that would move a schema
> between two databases in the same cluster. It's fraught with
> practical difficulties because a single backend can't be connected to
> both databases at the same time, so how exactl
I wrote:
> Peter Eisentraut writes:
>> Have we dug deep enough into the firewall configuration to evaluate
>> other options? Can we, for example, exclude a port range?
> Not that I've been able to detect. Any simple way to do that would
> presumably open up exactly the security hole Apple is tr
Peter Eisentraut writes:
> Given that this doesn't affect "make check" anymore, I'm unsure about
> this patch. There is a lot of magic in the configure change. I don't
> know what to pass as the configure option argument, so can't really
> evaluate that. I'd like to see an explanation for what
On 25 October 2014 13:28, Alvaro Herrera wrote:
> Thom Brown wrote:
> > On 24 October 2012 18:17, Tom Lane wrote:
> >
> > > Marco Nenciarini writes:
> > > > Please find the attached refreshed patch (v2) which fixes the loose
> ends
> > > > you found.
> > >
> > > Attached is a v3 patch that upda
On Fri, Oct 24, 2014 at 12:07:42PM -0400, Robert Haas wrote:
> I think instead of focusing on foreign keys, we should rewind a bit
> and think about the locking level required to add a trigger.
Agreed.
> http://www.postgresql.org/message-id/ca+tgmoy4glsxzk0tao29-ljtcuj0sl1xwcwq51xb-hfysgi...@mail
On Fri, Oct 24, 2014 at 6:48 PM, Peter Geoghegan wrote:
>> You're conflating the user-visible syntax with the parse tree
>> representation in way that is utterly without foundation. I don't
>> have a position at this point on which parse-analysis representation
>> is preferable, but it's complete
Hi,
There was recently talk about if we should start using 128-bit integers
(where available) to speed up the aggregate functions over integers
which uses numeric for their internal state. So I hacked together a
patch for this to see what the performance gain would be.
Previous thread:
http
>
> you can check it? We can test, how performance lost we get. As second
> benefit we can get numbers for introduction new optimized array builder
>
array_agg(anyarray) with deconstruct_array, unchanged accumArrayResult and
makeMdArrayResult:
> INSERT 0 1
> Time: 852,527 ms
> INSERT 0 1
> Time:
On 10/24/14 9:39 AM, Tom Lane wrote:
> Peter, Dave: maybe you have tweaked things to keep listen_addresses
> empty and rely only on Unix-socket connections?
I can confirm that I do get the popup when starting an installed
postmaster with the default settings.
Given that this doesn't affect "make
On 10/24/14 10:27 AM, Tom Lane wrote:
> Some clients (eg JDBC) don't support Unix-socket connections AFAIK, so
> this seems like a rather restricted solution.
While this is a valid point, they're actually working on fixing that.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Alvaro Herrera wrote:
> Thom Brown wrote:
> > Does anyone have any intention of resurrecting this at this stage?
>
> Not in this room. Do you?
I should have added some more context so that people realizes that "this
room" contains the 2ndQuadrant people involved in writing this patch.
Also I wa
Thom Brown wrote:
> On 24 October 2012 18:17, Tom Lane wrote:
>
> > Marco Nenciarini writes:
> > > Please find the attached refreshed patch (v2) which fixes the loose ends
> > > you found.
> >
> > Attached is a v3 patch that updates the syntax per discussion, uses what
> > seems to me to be a sa
On Tue, Oct 7, 2014 at 11:10 AM, Dilip kumar wrote:
>
> On 26 September 2014 12:24, Amit Kapila Wrote,
>
> >I don't think this can handle cancel requests properly because
>
> >you are just setting it in GetIdleSlot() what if the cancel
>
> >request came during GetQueryResult() after sending sql fo
2014-10-25 12:20 GMT+02:00 Ali Akbar :
> 2014-10-25 15:43 GMT+07:00 Pavel Stehule :
>
>>
>>
>> 2014-10-25 10:16 GMT+02:00 Ali Akbar :
>>
>>> makeArrayResult1 - I have no better name now
>
> I found one next minor detail.
>
> you reuse a array_agg_transfn function. Inside is a mess
Robert Haas wrote:
> On Fri, Oct 24, 2014 at 4:46 PM, Jim Nasby wrote:
> > On 10/24/14, 12:21 PM, Robert Haas wrote:
> >> - What should we call dsm_unkeep_mapping, if not that?
> >
> > Only option I can think of beyond unkeep would be
> > dsm_(un)register_keep_mapping. Dunno that it's worth it.
>
Peter Geoghegan wrote:
> On Fri, Oct 24, 2014 at 4:39 PM, Petr Jelinek wrote:
> > Ugh, you want to auto-magically detect what value is behind the EXCLUDED
> > based on how/where it's used in the UPDATE? That seems like quite a bad
> > idea.
>
> That's *exactly* how DEFAULT works within UPDATE ta
2014-10-25 15:43 GMT+07:00 Pavel Stehule :
>
>
> 2014-10-25 10:16 GMT+02:00 Ali Akbar :
>
>> makeArrayResult1 - I have no better name now
I found one next minor detail.
you reuse a array_agg_transfn function. Inside is a message
"array_agg_transfn called in non-aggregate
On 24 October 2012 18:17, Tom Lane wrote:
> Marco Nenciarini writes:
> > Please find the attached refreshed patch (v2) which fixes the loose ends
> > you found.
>
> Attached is a v3 patch that updates the syntax per discussion, uses what
> seems to me to be a saner (more extensible) catalog repr
2014-10-25 10:16 GMT+02:00 Ali Akbar :
> makeArrayResult1 - I have no better name now
>>>
>>> I found one next minor detail.
>>>
>>> you reuse a array_agg_transfn function. Inside is a message
>>> "array_agg_transfn called in non-aggregate context". It is not correct for
>>> array_agg_anyarray_tr
>
> makeArrayResult1 - I have no better name now
>>
>> I found one next minor detail.
>>
>> you reuse a array_agg_transfn function. Inside is a message
>> "array_agg_transfn called in non-aggregate context". It is not correct for
>> array_agg_anyarray_transfn
>>
>
Fixed.
> probably specification
33 matches
Mail list logo
