> On Apr 8, 2015, at 3:43 PM, Vasudevan, Ramya
> wrote:
>
> Thank You John.
>
> > the state_change to idle-in-transaction took place about 0.0001 seconds
> > later (so the insert took all of a millisecond).
> Yes, the DML “finished” but stayed uncommitted.
>
> > What date/time was it when y
Thank You John.
> the state_change to idle-in-transaction took place about 0.0001 seconds later
> (so the insert took all of a millisecond).
Yes, the DML “finished” but stayed uncommitted.
> What date/time was it when you did that select from pg_stat_activity ?
> thats how long this transact
So is there a third and even faster way of doing this?
On Wed, Apr 8, 2015 at 4:08 PM, Adrian Klaver
wrote:
> On 04/07/2015 07:49 PM, Tim Uckun wrote:
>
>> I understand that there is overhead involved in parsing the strings and
>> such. The amount of overhead was surprising to me but that's ano
I'm working on a background worker (BGW) for my pg_partman extension. I've
gotten the basics of it working for my first round, but there's two
features I'm missing that I'd like to add before release:
1) Only allow one instance of this BGW to run
2) Create a bgw_terminate_partman() function to sto
On 4/8/2015 10:55 AM, Vasudevan, Ramya wrote:
state | idle in transaction
query | INSERT into distributed_events (type, action, id, properties)
VALUES ($1, $2, $3, $4) RETURNING "distributed_event_id"
idle means its NOT executing any query... thats just the LAST query it
executed.id
"Nykolyn, Andy (AS)" writes:
> I get the following error in my 9.4.1 database when I issue the command:
> Create extension dblink;
> ERROR: could not load library "/usr/local/pgsql941/lib/dblink.so":
> /usr/local/pgsql941/lib/dblink.so: undefined symbol: PQsetSingleRowMode
> Is this a bug or d
I get the following error in my 9.4.1 database when I issue the command:
Create extension dblink;
ERROR: could not load library "/usr/local/pgsql941/lib/dblink.so":
/usr/local/pgsql941/lib/dblink.so: undefined symbol: PQsetSingleRowMode
Is this a bug or did I do something wrong? Any help woul
I noticed 100s of waiting sessions in my production DB yesterday. Upon
troubleshooting, I found an insert statement (idle in transaction) that was
blocking.
This is what I saw in pg_stat_activity:
site=# select * from pg_stat_activity where pid=62334;
-[ RECORD 1
]+-
On 04/08/2015 01:38 PM, Andrew Pennebaker wrote:
Could you be more specific?
I can't find a relevant section to address my specific problem: ecpg
complaining when I try to check the syntax of my .sql files that use
input parameters.
I think this has more to do with pgsanity:
https://github.co
Andrew Pennebaker writes:
> I can't find a relevant section to address my specific problem: ecpg
> complaining when I try to check the syntax of my .sql files that use input
> parameters.
I'm not sure why you think that should work. psql and ecpg have quite
distinct input languages. Both are ex
Could you be more specific?
I can't find a relevant section to address my specific problem: ecpg
complaining when I try to check the syntax of my .sql files that use input
parameters.
On Wed, Apr 8, 2015 at 9:34 AM, Adrian Klaver
wrote:
> On 04/08/2015 07:22 AM, Andrew Pennebaker wrote:
>
>> Po
I need to make a correct to the status of the removed node. The removed node’s
status is ‘k’ not ‘r’ in the bdr.bdr_nodes table.
> On Apr 8, 2015, at 10:05 AM, Dennis wrote:
>
> I have removed a node from a three node bdr cluster using
> bdr.bdr_part_by_node_names() however I am still seeing
I have removed a node from a three node bdr cluster using
bdr.bdr_part_by_node_names() however I am still seeing the removed node in the
bdr.bdr_nodes table (it’s status is ‘r’.) Will the removed node entry in the
bdr.bdr_nodes table be automatically removed eventually or should I delete the
On 04/08/2015 07:22 AM, Andrew Pennebaker wrote:
PostgreSQL uses a :colon syntax for parameterizing SQL commands with
command line variables.
create-database.sql:
CREATE DATABASE :db;
Usage:
$ psql -f create-database.sql -v db=test
However, pgsanity/ecpg rejects these.
$ pgsanity create-dat
PostgreSQL uses a :colon syntax for parameterizing SQL commands with
command line variables.
create-database.sql:
CREATE DATABASE :db;
Usage:
$ psql -f create-database.sql -v db=test
However, pgsanity/ecpg rejects these.
$ pgsanity create-database.sql
line 1: ERROR: syntax error at or near ":
On 2015-04-08 13:10, Glyn Astill wrote:
>> From: Chris Mair
>
>
>
> I think this is down to behaviour changes in glibc, there was a thread a
> while ago where somebody replicating via streaming rep between with different
> versions of glibc ended up in a bit of a pickle.
>
> http://www.postg
Yes. Its working fine.
What i mean i created function to delete parts from table.Then i need to
place it on pgagent.
i placed function in pagent
like this..
do $$
declare
job_id int;
begin
/* add a job and get its id: */
insert into
pgagent.pga_job (jobjclid, jobname)
val
> From: Chris Mair
> To: Björn Lundin ; pgsql-general@postgresql.org
> Cc:
> Sent: Wednesday, 8 April 2015, 10:36
> Subject: Re: [GENERAL] unexpected (to me) sorting order
>
>
>> select * from T_SORT order by NAME ;
>>
>> rollback;
>> id |name
>> +
>>1
Exactly, my point was not to repeat point 4 but the whole step.
Upon serialization failure exception it would re-read data from database,
perform the same something with data and save it. And point 2 is the part
that fails in my "restart wrapper" function in the code I posted in
stackoverflow, it
On Wed, 08 Apr 2015 11:36:01 +0200
Chris Mair wrote:
> PostreSQL relies on the OS's C lib. So this kind
> of ordering problems depend on the OS' idea about
> collations.
>
> I don't know what's the rationale behin this,
> but it looks like Linux ignores the . when doing the sort.
Not only '.'.
On 2015-04-08 11:36, Chris Mair wrote:
>
> I don't know what's the rationale behin this,
> but it looks like Linux ignores the . when doing the sort.
>
Yes, I see that now,
and it makes sense
Thanks.
--
Björn
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make chang
On 2015-04-08 11:33, Glyn Astill wrote:
> The collation of your "bnl" database is utf8, so the "." punctuation
> character is seen as a "variable element" and given a lower weighting in
> the sort to the rest of the characters. That's just how the collate
algorithm works in UTF8.
> Try with LC_C
> select * from T_SORT order by NAME ;
>
> rollback;
> id |name
> +
> 1 | FINISH_110_150_1
> 2 | FINISH_110_200_1
> 3 | FINISH_1.10_20.0_3
> 4 | FINISH_1.10_20.0_4
> 5 | FINISH_1.10_30.0_3
> 6 | FINISH_1.10_30.0_4
> 7 | FINISH_120_150_1
> 8 | FINIS
> From: Björn Lundin
>To: pgsql-general@postgresql.org
>Sent: Wednesday, 8 April 2015, 10:09
>Subject: [GENERAL] unexpected (to me) sorting order
>
>
>
>Hi!
>below are some commands to
>replicate a strange sorting order.
>
>I do not see why id:s 3-6 are in the middle of the result set.
>
>What
Hi!
below are some commands to
replicate a strange sorting order.
I do not see why id:s 3-6 are in the middle of the result set.
What am I missing?
begin;
create table T_SORT (
ID bigint default 1 not null , -- Primary Key
NAME varchar(100) default ' ' not null
);
alter table T_SORT add cons
25 matches
Mail list logo
