On 07/20/2015 03:01 PM, Andres Freund wrote:
Heikki,
On 2015-07-20 13:27:12 +0200, Andres Freund wrote:
On 2015-07-20 13:22:42 +0200, Andres Freund wrote:
Hm. The problem seems to be the WaitXLogInsertionsToFinish() call in
XLogFlush().
These are the relevant stack traces:
db9lock/debuglog-c
On 07/23/2015 11:31 AM, Spiros Ioannou wrote:
Well, so far with commit_delay=0 no problems. I will report back of couse
if something happens, but I believe that the problem may indeed be
solved/masked with that setting.
Rough description of our setup, or how to reproduce:
* Timeseries data in ta
On 07/23/2015 02:36 PM, Heikki Linnakangas wrote:
On 07/23/2015 11:31 AM, Spiros Ioannou wrote:
Well, so far with commit_delay=0 no problems. I will report back of couse
if something happens, but I believe that the problem may indeed be
solved/masked with that setting.
Rough description of our
A-ha, I succeeded to reproduce this now on my laptop, with pgbench! It
seems to be important to have a very large number of connections:
pgbench -n -c400 -j4 -T600 -P5
That got stuck after a few minutes. I'm using commit_delay=100.
Now that I have something to work with, I'll investigate this
On 07/28/2015 11:36 PM, Heikki Linnakangas wrote:
A-ha, I succeeded to reproduce this now on my laptop, with pgbench! It
seems to be important to have a very large number of connections:
pgbench -n -c400 -j4 -T600 -P5
That got stuck after a few minutes. I'm using commit_delay=100.
Now t
On 07/30/2015 04:23 PM, Spiros Ioannou wrote:
I'm very sorry but we don't have a synthetic load generator for our testing
setup, only production and that is on SLA. I would be happy to test the
next release though.
Ok, no worries. I've pushed this changes, it will appear in the next
release. T
On 01/13/2015 12:11 PM, Vladimir Borodin wrote:
05 янв. 2015 г., в 18:15, Vladimir Borodin написал(а):
Hi all.
I have a simple script for planned switchover of PostgreSQL (9.3 and 9.4)
master to one of its replicas. This script checks a lot of things before doing
it and one of them is that
On 05.03.2013 15:59, Kevin Grittner wrote:
Daniel Farina wrote:
This kind of change may have many practical problems that may
make it un-pragmatic to alter at this time (considering the
workaround is to set the extra float digits), but I can't quite
grasp the rationale for "well, the only prog
(pgeu-general is not the right list for technical discussions, moving to
pgsql-general)
On 20.03.2013 10:46, Albe Laurenz wrote:
Umashanker, Srividhya wrote:
I am looking for a solution the Alphanumeric sorting
I am expecting
1, bay1
2, bay2
10, bay10
11, bay11
We are working on a framew
On 21.05.2013 08:11, Dev Kumkar wrote:
On Mon, May 20, 2013 at 9:12 PM, Atri Sharma wrote:
If you wish to work in C,then,I would suggest libpq.I would wait for more
replies on this,as I have little knowledge
about psqlODBC.
Thanks for the comments. Yes objective is to work in C and found l
BTW, pgeu-general is not for technical questions, so moving to
pgsql-general. (I didn't notice the mailing list this came from until
after replying).
On 22.05.2013 18:22, Heikki Linnakangas wrote:
On 22.05.2013 10:23, TJ wrote:
I am looking to migrate my databases from one set of hardwa
On 23.05.2013 03:55, TJ wrote:
We have a few different sets of servers with different versions.
9.0.4
9.1.4
9.2.3
I recently tried to fail-over a set of 9.2.3 servers and server4 did
notice the timeline change but did not start following it.
We do not have the recovery_target_timeline set in th
mestamp on the file and triggers a reload whenever it
changes.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Put a small elephant logo *inside* the mug. With a text: "also for
embedded systems"
- Heikki
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 14.11.2013 02:26, Jeff Janes wrote:
On Wed, Nov 13, 2013 at 3:53 PM, Sergey Burladyan wrote:
Jeff Janes writes:
If I not mistaken, looks like lazy_scan_heap() called from
lazy_vacuum_rel()
(see [1]) skip pages, even if it run with scan_all == true,
lazy_scan_heap()
does not increment scann
hives.postgresql.org/message-id/1308926157-sup-7...@alvh.no-ip.org
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 23.11.2012 17:53, Tom Lane wrote:
Euler Taveira writes:
On 22-11-2012 04:27, Pavel Stehule wrote:
significantly larger catalog
Less than 5% of catalog columns? I don't buy your argument.
It's not about count, it's about size. For instance, pg_attribute
currently requires 140 bytes per
On 15.12.2012 17:06, hubert depesz lubaczewski wrote:
I might be missing something, but what exactly does that commit give us?
I mean - we were able, previously, to make slave switch to new master
- as Phil Sorber described in here:
http://philsorber.blogspot.com/2012/03/what-to-do-when-your-tim
On 18.12.2012 13:42, hubert depesz lubaczewski wrote:
In pg_log on ubuntu2 I see:
2012-12-18 12:41:34.428 CET [unknown]@[unknown] 1685 LOG: connection
received: host=172.28.173.142 port=45842
2012-12-18 12:41:34.430 CET replication@[unknown] 1685 172.28.173.142(45842)
LOG: replication conne
point out
that we prefer context diffs.
Please resend the patch as a context diff, using "diff -c" or "cvs diff
-c", so that it's easier to review.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
the system
thought.
That was fixed by Hannu Krosing's patch in 8.2 that made vacuum to
ignore other vacuums in the oldest xmin calculation.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: i
nce 8.2 we do index vacuums in
a single scan in physical order. In fact, in many applications the index
is be mostly cached and the index scan doesn't generate any I/O at all.
I believe the heap scans are the biggest issue at the moment.
--
Heikki Linnakangas
Ente
Bruce Momjian wrote:
Heikki Linnakangas wrote:
Russell Smith wrote:
2. Index cleanup is the most expensive part of vacuum. So doing a
partial vacuum actually means more I/O as you have to do index cleanup
more often.
I don't think that's usually the case. Index(es) are typica
ood bet that the
blocks that need vacuuming are also not randomly distributed. In fact,
they might very well all be in one cluster, so that scanning that
cluster is indeed sequential I/O.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---
yback.
Yeah, I had the same idea when we discussed synchronizing sequential
scans. The biggest difference is that with queries, there's often a user
waiting for the query to finish, but with vacuum we don't care so much
how long it takes.
--
Heikki Linnakangas
Ente
cuting the long running query, and
then use pg_cancel_backend (or kill -INT) to cancel it.
and also tell me how to log slow queries to a log file.
Using the log_min_duration_statement configuration variable.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---
26 matches
Mail list logo
