Hi all,
Our application executes come scripts with the code consist of DDL which
creates lot of objects in the database in various schemas,also there are
lot of connections firing the same code. I am able to locate the IP from
where the script is initiated (which is causing more load on the datab
On 5/19/2016 12:18 AM, Shrikant Bhende wrote:
Our application executes come scripts with the code consist of DDL
which creates lot of objects in the database in various schemas,also
there are lot of connections firing the same code. I am able to locate
the IP from where the script is initiat
On Thu, May 19, 2016 at 3:29 PM John R Pierce wrote:
> On 5/19/2016 12:18 AM, Shrikant Bhende wrote:
>
>
> Our application executes come scripts with the code consist of DDL which
> creates lot of objects in the database in various schemas,also there are
> lot of connections firing the same code
On 19/05/2016 10:57, Sameer Kumar wrote:
On Thu, May 19, 2016 at 3:29 PM John R Pierce mailto:pie...@hogranch.com>> wrote:
On 5/19/2016 12:18 AM, Shrikant Bhende wrote:
Our application executes come scripts with the code consist of DDL which
creates lot of objects in the database i
On 19 May 2016 at 05:04, Tom Smith wrote:
> It would really save all the troubles for many people if postgresql has a
> built-in first/last function along with sum/avg.
> There is already a C extension and a wiki sample and implemented for
> window function.
> I am curious why these two functi
Hello Tom,
I agree such functions are very useful, as they allow you to use
ordinary aggregation functions such as sum/max/avg
along with first/last ones (traditionally served by DISTINCT ON or
LIMIT) in the same group-by node
which improves performance and readability.
The first/last extensi
El 18/05/16 a las 19:03, Rene . escribió:
Hi, Check for long running Idle in transaction sessions. Idle in transaction
sessions may holding events table from cleaning itself up.
If there is more then days long running idle in transaction sessions, kill
them, event table should be cleaned automa
Queue - Event are stored in queue tables i.e queues. Several producers can write
into same queue and several consumers can read from the queue. Events are kept
in queue until all the consumers have seen them.
Maybe you have some inactive consumers holding a event tables.
qadmin -h -p 5432 -U pos
I got the query:
SELECT c1, c2,
ARRAY_TO_STRING(ARRAY_AGG((SELECT t3.c1 FROM s.t1 as t3 JOIN s.t1 as
t2 ON t3.c3 = t2.c2)), ',')
FROM s.t1 t1
GROUP BY c1;
DROP SCHEMA s CASCADE;
Thanks for all the help.
Thanks
Shankha Banerjee
On Wed, May 18, 2016 at 2:40 PM, David G. Johnston
wrote:
> On We
On Thu, May 19, 2016 at 7:10 AM, Alexey Bashtanov wrote:
> As for the original question unfortunately the way from an extension to
> postgres core is not too easy
> and normally requires an extension to become popular and to be included in
> postgres distribution as a contrib module first.
>
Do
Hi PostgreSQL community,
I am investigating a problem with a backend that appears to be stuck
and spinning while performing a "DISCARD ALL" command. The system is
running an older release 9.2.2. Are there any bugs that could be
causing this behavior? How can I tell what the process is actually
doi
"k...@rice.edu" writes:
> I am investigating a problem with a backend that appears to be stuck
> and spinning while performing a "DISCARD ALL" command. The system is
> running an older release 9.2.2.
You do realize that the current release in that series is 9.2.17.
> Are there any bugs that coul
On 05/19/2016 06:46 AM, k...@rice.edu wrote:
Hi PostgreSQL community,
I am investigating a problem with a backend that appears to be stuck
and spinning while performing a "DISCARD ALL" command. The system is
running an older release 9.2.2. Are there any bugs that could be
causing this behavior?
On Thu, May 19, 2016 at 09:58:45AM -0400, Tom Lane wrote:
> "k...@rice.edu" writes:
> > I am investigating a problem with a backend that appears to be stuck
> > and spinning while performing a "DISCARD ALL" command. The system is
> > running an older release 9.2.2.
>
> You do realize that the cur
On Wed, May 18, 2016 at 5:05 AM, Boszormenyi Zoltan wrote:
> 2016-05-17 15:29 keltezéssel, Albe Laurenz írta:
>>
>> Boszormenyi Zoltan wrote:
>>>
>>> it was a long time I have read this list or written to it.
>>>
>>> Now, I have a question. This blog post was written about 3 years ago:
>>> https:/
On Thu, May 19, 2016 at 8:46 AM, k...@rice.edu wrote:
> Hi PostgreSQL community,
>
> I am investigating a problem with a backend that appears to be stuck
> and spinning while performing a "DISCARD ALL" command. The system is
> running an older release 9.2.2. Are there any bugs that could be
> caus
Hi all,
this is somewhat involved so please bear with me.
We've found a situation where canceling a query may cause the client to
hang, possibly indefinitely. This can happen if the network connection
fails in a specific way.
The reason for this lies in the way the PQcancel function (which
event
This has happened to us where we have dead or unmanaged consumer. Turns out
londiste is keeping the event even if the consumer is unreachable. This is
to ensure that the consumer gets what it should.
To clean this up, delete the unused/dead consumer, with qadmin or manually
if necessary. The table
Hi PostgreSQL community:
We have a three node postgresql BDR set up. One of our nodes went down due to
a power issue. After bringing the server back online the OS reported the need
to repair some files. Once this completed and we restarted the postgresql
service, we noticed that it was cras
Cameron Smith wrote:
> t:2016-05-19 01:14:51.668 UTC d= p=144 a=PANIC: could not create replication
> identifier checkpoint "pg_logical/checkpoints/8-F3923F98.ckpt.tmp": Invalid
> argument
This line corresponds to the following code in BDR's 9.4.4
src/backend/replication/logical/replication_id
## Cameron Smith (csm...@stereodllc.com):
> t:2016-05-19 01:14:51.668 UTC d= p=144 a=PANIC: could not create replication
> identifier checkpoint "pg_logical/checkpoints/8-F3923F98.ckpt.tmp": Invalid
> argument
> t:2016-05-19 01:14:51.671 UTC d= p=9729 a=WARNING: could not create
> relation-ca
On Thu, May 19, 2016 at 10:37 AM, Peter Juhasz
wrote:
> Hi all,
>
> this is somewhat involved so please bear with me.
>
> We've found a situation where canceling a query may cause the client to
> hang, possibly indefinitely. This can happen if the network connection
> fails in a specific way.
>
>
Peter Juhasz writes:
> We've found a situation where canceling a query may cause the client to
> hang, possibly indefinitely. This can happen if the network connection
> fails in a specific way.
> ...
> However, if the network fails in a way that the connection appears to
> have been established b
On Thu, May 19, 2016 at 3:32 PM, Tom Lane wrote:
> Peter Juhasz writes:
>
> > Is this known?
>
> I do not recall anyone ever reporting something similar --- and that code
> has been like that for a long time.
>
>
I'd take Tom's word over mine :)
David J.
"David G. Johnston" writes:
> On Thu, May 19, 2016 at 3:32 PM, Tom Lane wrote:
>> I do not recall anyone ever reporting something similar --- and that code
>> has been like that for a long time.
> âI'd take Tom's word over mine :)â
Well, my memory is often faulty ;-). But I did trawl the P
On Thu, May 19, 2016 at 09:58:45AM -0400, Tom Lane wrote:
> "k...@rice.edu" writes:
> > I am investigating a problem with a backend that appears to be stuck
> > and spinning while performing a "DISCARD ALL" command. The system is
> > running an older release 9.2.2.
>
> You do realize that the cur
I'd agree: most likely a file system problem. Is there any hope that this
file could be re-built?
My current plan is to use bdr_part_by_node_names to remove the failing node and
then rebuild it from a fresh backup (and probably on a new server).
Thank you for your help!
Cameron Smith
_
"k...@rice.edu" writes:
> The stack trace just appeared to be what I would expect while a 'DISCARD ALL'
> command was being run:
> #0 0x0073bc7c in MemoryContextSetParent ()
> #1 0x0073bde3 in MemoryContextDelete ()
> #2 0x0054e3a9 in DropAllPreparedStatements ()
> #3
El 19/05/16 a las 16:15, Cameron Smith escribió:
> I'd agree: most likely a file system problem. Is there any hope that this
> file could be re-built?
>
> My current plan is to use bdr_part_by_node_names to remove the failing node
> and then rebuild it from a fresh backup (and probably on a ne
Hi,
"make" command is generating the following error while compiling
postgresql-9.5.3 on Solaris SPARC.
I tried compiling 9.2 and 9.3, works fine. This is only happening on 9.5.
../../src/port/libpgport_srv.a ../../src/common/libpgcommon_srv.a -lnsl
-lrt -lsocket -lm -o postgres
Undefined
Hi Venkata,
I have't work on solaris sparc system since long but I would like to share
my feedback on this, I hope it might be useful.
On Fri, May 20, 2016 at 10:14 AM, Venkata Balaji N
wrote:
> Hi,
>
> "make" command is generating the following error while compiling
> postgresql-9.5.3 on Solar
31 matches
Mail list logo
