On Thu, Jun 26, 2014 at 10:03 PM, Anand Kumar, Karthik <
karthik.anandku...@classmates.com> wrote:
> We run postgres 9.3.3 on Centos 6.3, kernel 2.6.32-431.3.1. Every once in
> a while, we see postgres processes spinning on semop:
>
it might be long shot, but when we had problems with lots of bac
Hey,
thanks, now we have good information:
the python package are really loaded once per connection, so no
optimization is needed.
Unlike plperl or plR there is no easy way to preload packages.
There may be some solutions to make this import at connection start but it
would involve C modification
On Thu, 26 Jun 2014 15:00:56 -0700
Tom Lane wrote:
> James Le Cuirot writes:
> > Tom Lane wrote:
> >> PG is not capable of executing queries that are not in
> >> transactions, so yes, PQsendQuery will create a single-statement
> >> transaction if you haven't sent BEGIN. However, there's a huge
Thank you very much for your reply.
I've spoken with my boss, databases aren't so important, so if there is a
little of data lost, there isn't problem .. so I'm configuring this with
continuous archiving and base backups. If you are expert, please, I would
like make you some questions ..
I only hav
Another question please.
I've had to modify pg_hba.conf and postgresql.conf for doing work
pg_basebackup. About max_wal_senders, it would have 0 value, I've changed
it to 1 for doing work to pg_basebackup. Continuous archiving was working
with the value to 0, so I understand that max_wal_senders ca
On 06/26/2014 05:31 PM, Tim Uckun wrote:
1. If there is a very large set of data in the table that needs to be
moved this will be slow and might throw locks which would impact the
performance of the inserts and the updates.
Well, the locks would only affect the rows being moved. If this is
Tim Uckun wrote
> The database is functioning fine now but I am anticipating a much higher
> workload in the future. The table in question is probably going to have a
> few million rows per day inserted into it when it gets busy, if it gets
> very busy it might be in the tens of millions per day b
On Thu, Jun 26, 2014 at 1:03 PM, Anand Kumar, Karthik
wrote:
> Hi,
>
> We run postgres 9.3.3 on Centos 6.3, kernel 2.6.32-431.3.1. Every once in a
> while, we see postgres processes spinning on semop:
Are there a lot of tuples in the table that have been inserted or
updated by still-open transact
On 2014-06-27 10:51:20 -0700, Jeff Janes wrote:
> On Thu, Jun 26, 2014 at 1:03 PM, Anand Kumar, Karthik
> > Samples: 33K of event 'cycles', Event count (approx.): 20693251070
> > 26.16% postmaster postgres [.] 0x00188450
> > 21.13% postmaster postgres [.] h
>1. disabling zone_reclaim (echo 0 > /proc/sys/vm/zone_reclaim_mode)
> 2. disabling transparent hugepage support - this has various names on
> different kernel/distributions, but "find /sys | grep -i
> transparent.*hugepage.*enable" will find it, and then just echo never there.
Thank you, yes,
>Are there a lot of tuples in the table that have been inserted or
updated by still-open transactions?
Yes, there are likely to be inserts. That table is a log capture table
used by our replication software, so essentially every
update/delete/insert will have a record inserted into the table. It
Hello
plpgsql_check is PostgreSQL extension for deep check of plpgsql functions.
Only PostgreSQL 9.3 was supported.
Today I did a backport for PostgreSQL 9.2
https://github.com/okbob/plpgsql_check
Regards
Pavel Stehule
12 matches
Mail list logo
