Michael Paquier writes:
> On Tue, Sep 9, 2014 at 10:25 PM, Tom Lane wrote:
>> The reason for the assert is that there should never be an OR directly
>> underneath an OR in the planner after eval_const_expressions has flattened
>> such cases. Evidently commit f343a88 failed to preserve AND/OR fla
Hi Dmitriy, are you able to say a little about what's driving your quest
for async http-to-pg ?
I'm curious as to the motivations, and whether they match up with some
of my own reasons for wanting to use low-thread-count solutions.
Thanks.
--
Sent via pgsql-general mailing list (pgsql-gener
On Tue, Sep 9, 2014 at 10:25 PM, Tom Lane wrote:
> Michael Paquier writes:
>> The logic for nested OR is correct by reading it, hence why not simply
>> removing the assertion failing? The attached patch 1 does so.
>
> The reason for the assert is that there should never be an OR directly
> undern
On 09 Sep 2014, at 17:23, Dan Wells wrote:
> I often have functions which are not truly immutable (they do something
> minor, like read in configuration information), but the functions themselves
> are fairly expensive, so I want them to run just once per query. At face
> value, I feel like S
Ellen,
To date I have no solution. I'm currently trying to build a debug-able version
of 3.3.4 as I think I have a network problem which is preventing pgpool from
being a happy shareable system. Each one currently thinks it's a primary upon
startup, if it will start at all.
Sent from my iPad
Hi Jay,
Can you pls tell me how you resolved this issue.
We are running pgpool-II version 3.3.3
Thanks.
Ellen
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Pgpool-starting-problem-tp5803276p5818354.html
Sent from the PostgreSQL - general mailing list archive at Nabbl
On 09/08/2014 04:18 PM, Lou Oquin wrote:
Jerry;
When I run the query you supplied, with my database
select sli.ts::timestamptz as tstamp
from public.sql_log_import sli
where sli.id <= 10;
I get the following error:
ERROR: invalid input syntax for type timestamp with time zone: "08/06/2014
On Tue, Sep 9, 2014 at 10:23 AM, Dan Wells wrote:
> Hello all,
>
> I’ve run into this issue in several contexts recently, and wonder if folks
> here can help clear up my understanding of function volatility. I often
> have functions which are not truly immutable (they do something minor, like
> r
On 09/08/2014 04:18 PM, Lou Oquin wrote:
Jerry;
When I run the query you supplied, with my database
select sli.ts::timestamptz as tstamp
from public.sql_log_import sli
where sli.id <= 10;
I get the following error:
ERROR: invalid input syntax for type timestamp with time zone: "08/06/2014
On 9/9/2014 3:36 AM, Ramesh T wrote:
I had installed pgadmin3 but not selected stackbuilder ,let me
know how to add stackbuilder to pgadmin3 for additional addons..
afaik, you'll need to run the enterprisedb postgres installer again to
add stackbuilder
--
john r pierce
Dan Wells writes:
> I've run into this issue in several contexts recently, and wonder if
> folks here can help clear up my understanding of function volatility. I
> often have functions which are not truly immutable (they do something
> minor, like read in configuration information), but the func
Jerry;
When I run the query you supplied, with my database
select sli.ts::timestamptz as tstamp
from public.sql_log_import sli
where sli.id <= 10;
I get the following error:
ERROR: invalid input syntax for type timestamp with time zone: "08/06/2014
03:08:58"
** Error **
ERR
I'm executing the query in pgAdmin3, in a SQL query window. The results are
coming from the history tab of the output pane.
Thanks
Lou
-Original Message-
From: Adrian Klaver [mailto:adrian.kla...@aklaver.com]
Sent: Monday, September 08, 2014 2:47 PM
To: Lou Oquin; pgsql-general@postgre
The data is
ts
08/06/2014 03:08:58
08/06/2014 03:08:58
08/06/2014 03:08:58
Thanks
Lou
From: Melvin Davidson [mailto:melvin6...@gmail.com]
Sent: Monday, September 08, 2014 2:30 PM
To: Lou Oquin
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Issue with to_timestamp function
I suspect y
Hi,
I had installed pgadmin3 but not selected stackbuilder ,let me know
how to add stackbuilder to pgadmin3 for additional addons..
thanks,
ram
Hello all,
I've run into this issue in several contexts recently, and wonder if folks here
can help clear up my understanding of function volatility. I often have
functions which are not truly immutable (they do something minor, like read in
configuration information), but the functions themse
On 09/08/2014 11:45 AM, Abelard Hoffman wrote:
Hi Alban.
On Sun, Sep 7, 2014 at 4:18 AM, Alban Hertroys mailto:haram...@gmail.com>> wrote:
On 07 Sep 2014, at 10:45, Abelard Hoffman mailto:abelardhoff...@gmail.com>> wrote:
> For reports, everyone else mostly uses other tools? I'd like t
On Tue, Sep 9, 2014 at 4:27 AM, Jeff Janes wrote:
> Is there a way for a superuser to find the last time a database had an
> active user connection? (While being logged into a different database in the
> same instance, of course).
> The context here is looking for looking for automated integration
Yossi Cohen writes:
> If I request an advisory lock (pg_advisory_lock) with the same key from
> several sessions; will the lock be granted in the same order as it was
> requested?
Usually. IIRC, the lock code will grant locks out-of-order if a deadlock
would result without it. There might be so
Michael Paquier writes:
> The logic for nested OR is correct by reading it, hence why not simply
> removing the assertion failing? The attached patch 1 does so.
The reason for the assert is that there should never be an OR directly
underneath an OR in the planner after eval_const_expressions has
2014-09-09 1:28 GMT+04:00 Merlin Moncure :
> On Mon, Sep 8, 2014 at 12:59 PM, Dmitriy Igrishin
> wrote:
> > Dear community,
> >
> > I need a %subj% -- high performance HTTP server solution
> > based on asynchronous IO with ability to run PostgreSQL's
> > functions from HTML templates asynchronous
Hi,
If I request an advisory lock (pg_advisory_lock) with the same key from
several sessions; will the lock be granted in the same order as it was
requested?
I.e. if for example:
session 1: select pg_advisory_lock(1); -- acquires the lock
then
session 2: select pg_advisory_lock(1); -- blocks wait
On Tue, Sep 9, 2014 at 2:43 PM, Michael Paquier
wrote:
> Some bisecting is showing as well that the commit at the origin of the
> regression is f343a88.
The failure is caused by an assertion not happy since this commit:
frame #4: 0x000101d20670
postgres`generate_bitmap_or_paths(root=0x
23 matches
Mail list logo
