/to/postgres -D frakbar
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
On 2013-10-03 19:07:37 +0200, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Starting postgres with a CWD that's not readable will trigger an Assert
and if those are disabled it presumably will segfault.
Yeah, we've discussed that before. I'm not sure it's worth fixing
- is that 8.1 is out
of support and thus unmaintained for more than 2 years. Check
http://www.postgresql.org/support/versioning/ for details.
The also have been several maintenance releases with important fixes in
the 8.1 line since then.
Greetings,
Andres Freund
--
Andres Freund
data?
* Were there any concurrent inserts?
* Are the duplicates rows in the same relation or in different ones?
* How many records do exist in the restore you made?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
No need, found the bug. And I think can build a testcase myself.
ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
binaryheap. Thus no new elements fit.
Sounds like a bug all
On 2013-08-30 17:15:32 -0400, Alvaro Herrera wrote:
Andres Freund wrote:
No need, found the bug. And I think can build a testcase myself.
ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
binaryheap. Thus no new elements fit.
Um. Are we missing a binaryheap_clear
On 2013-08-30 23:00:15 +0200, Andres Freund wrote:
Hi,
On 2013-08-30 20:46:27 +, te...@elde.net wrote:
I'm getting out of binary heap slots, which offcourse spoils the fun of
the query.
Explain analyze gives this plan (again anonymized a bit, but can send proper
off-list
be
interested in getting that. Ideally in a state where I can reproduce the
issue in a new cluster.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql
On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
On 2013-08-30 23:00:15 +0200, Andres Freund wrote:
Hi,
On 2013-08-30 20:46:27 +, te...@elde.net wrote:
I'm getting out of binary heap slots, which offcourse spoils the fun of
the query.
Explain analyze gives this plan
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
No need, found the bug. And I think can build a testcase myself.
ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
binaryheap. Thus no new elements fit.
Sounds like a bug all
On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
binaryheap. Thus no new elements fit.
Ok, patch for that attached.
I think
On 2013-08-30 19:28:39 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
Not sure. It's pretty disturbing that this wasn't caught earlier;
it seems to me that means there's no regression coverage that hits
work.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
things got better there?
Alternatively, it might be very worthwile to try to get way from
per-transaction or even per-function temporary tables. As you've
discovered, they have quite the cost...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
a patch. Could anyone confirm for me.
Nice diagnosis and thanks for the patch!
I think the the issue has already been fixed while investigating a
similar issue, could you verify that the current git version works for
you?
c.f. commit 99ee15b315c187045a95db7b27fd9d866aea93e0
Greetings,
Andres Freund
a safe
NextMultiXactId/Offset using pg_resetxlog?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
On 2013-08-02 22:25:36 -0400, Alvaro Herrera wrote:
Andres Freund escribió:
On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote:
Alvaro Herrera escribió:
As it turns out, I have a patched slru.c that adds a new function to
verify whether a page exists on disk. I created
that, to get more
info?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
Hi,
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:
2013/6/30 Andres Freund and...@2ndquadrant.com:
On 2013-06-30 10:43:49 +, e...@hasegeli.com wrote:
Could you attach config.log?
Attached.
This seems to be caused
On 2013-07-25 09:48:31 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Before that commit the checks for cmsgcred which includes sys/ucred.h
happened to include params.h... Patch attached, missing the configure
update since I don't have a compatible autoconf on my laptop
On 2013-07-25 11:50:47 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The problem is that you can't include sys/ucred.h on some platforms
(e.g. openbsd) without first including sys/params.h because the
resulting file won't compile.
BTW, after committing this I re
;a=commitdiff;h=e472b921406407794bab911c64655b8b82375196
Which has also been backported to the 9.2 branch. There hasn't been a
release since the commit though.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
the
problem when loaded into 9.3?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
It looks like a bug to me, or at least a non desirable behaviour.
Hm. Doesn't really look like a bug to me. The first parses as:
ROUND((1/2) * 3.2), the second as ROUND((3.2 * 1) / 2). So the different
result makes sense to me.
Greetings,
Andres Freund
--
Andres Freund http://www
On 2013-07-01 09:19:23 -0400, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 6/30/13 11:26 AM, Andres Freund wrote:
If we would treat that warning as an error unconditionally - and I am
not sure how easy that is given the way it's emitted - users
encountering them, which
: ## ##
configure: WARNING: ## Report this to pgsql-bugs@postgresql.org ##
configure: WARNING: ## ##
checking for sys/ucred.h... yes
Could you attach config.log?
Greetings,
Andres Freund
--
Andres
On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:
2013/6/30 Andres Freund and...@2ndquadrant.com:
On 2013-06-30 10:43:49 +, e...@hasegeli.com wrote:
Could you attach config.log?
Attached.
This seems to be caused by be4585b1c27ac5dbdd0d61740d18f7ad9a00e268. The
fault imo lies
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
Andrew: Could we perhaps check for the Report this to bit in the
buildfarm?
FWIW: I checked that there are no other reports on HEAD atm.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:
On 06/30/2013 09:49 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
Andrew: Could we perhaps check for the Report this to bit in the
buildfarm?
I'm not sure what you're
that many of those warnings will *NOT* completely prohibit them
from building postgres that might be overreaching.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing
; depends on: 1833
unsurprisingly after that restore completes.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 2ce0cd8
together with ACLs. I don't think we can have dependencies towards
comments.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
only write xlog in XLOG_BLCKSZ units - which is 8kb by default as
well...
Yuri, have you compiled postgres with nonstandard configure or
pg_config_manual.h settings?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On 2013-06-26 15:40:08 +0300, Heikki Linnakangas wrote:
On 26.06.2013 15:21, Andres Freund wrote:
On 2013-06-26 13:14:37 +0100, Greg Stark wrote:
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lanet...@sss.pgh.pa.us wrote:
(Though if it is, it's not apparent why such
failures would only
On 2013-06-18 23:30:44 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-06-18 13:17:14 +, and...@lombardoni.ch wrote:
template1=# SELECT CASE WHEN (SELECT 0)=0 THEN 0 ELSE 1/0 END;
ERROR: division by zero
Hrmpf. This is rather annoying.
Annoying, maybe
know
that one WHEN succeeds.
So it seems we need to stop processing after finding a single WHEN
that's not const? Does anybody have a better idea?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
the transaction, should do the trick.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
.
Which of those queries take how long in your case?
E.g. I could imagine that the first two can be sped up a bit without
changing the result. E.g. not calling pg_tablespace_location() for every
relation and such.
Greetings,
Andres Freund
--
Andres Freund http://www
to have a
tremendous amount of dependencies.
Could you do a count(*) of pg_depend, pg_type and pg_class?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql
standby (the peak
was 400 GB and was still increasing before switching to warm standby).
By switching to a warm standby you mean disabling hot_standby=on in the
standbys or changing wal_level?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
into a situation where all
of the checkpoints/xl_running_xact's are suboverflowed delaying
consistency considerably.
Seems more consistent with the rest of the code too. But anyway, I am
fine with fixing it either way.
Greetings,
Andres Freund
--
Andres Freund http://www
# perf report somefile
And then send somefile?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
be that nextval_internal()
acquires a real xid (by calling GetTopTransactionId()). In that case the
commit would force a WAL flush but there are no forced wal flushes ones
inside the transaction. And it would support async commits.
Greetings,
Andres Freund
--
Andres Freund http://www
won't.
Typical suspects would be longrunning (idle in) transactions or prepared
transactions.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs
On 2013-04-12 10:47:52 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Thats caused by the fact that you didn't do anything that forces a WAL
flush since you didn't do any inserts or such. If you would do any
DML in the nextval() calling transaction this shouldn't happen
On 2013-04-12 20:02:07 +0300, Tarvi Pillessaar wrote:
On 12.04.2013 17:04, Andres Freund wrote:
On the other hand, at
least in the first example you haven't even committed the transaction so
there's nothing that could flush the transaction unless we we would
*always* flush nextval
that long isn't nice either...
Blocking in send(2) might could occur for async-rep connection but not
likely for sync-rep since it does not fill the buffers of libpq and
socket easilly.
You just need larger transactions for it. A COPY or so ought to do it.
Greetings,
Andres Freund
--
Andres
On 2013-04-10 23:37:44 +0900, Dang Minh Huong wrote:
Thanks all,
(2013/04/10 22:55), Andres Freund wrote:
On 2013-04-10 22:38:07 +0900, Kyotaro HORIGUCHI wrote:
Hello,
On Wed, Apr 10, 2013 at 6:57 PM, Dang Minh Huong kakalo...@gmail.com
wrote:
In 9.3, it sounds replication_timeout
On 2013-04-05 07:10:12 -0700, Sergey Konoplev wrote:
On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund and...@2ndquadrant.com wrote:
The attached patch fixes this although I don't like the way it knowledge of
the
point up to which StartupSUBTRANS zeroes pages is handled.
Thank you
On 2013-04-05 07:22:08 -0700, Sergey Konoplev wrote:
On Fri, Apr 5, 2013 at 7:15 AM, Andres Freund and...@2ndquadrant.com wrote:
Cool. It would be very helpful if you could apply the patch and verify
that it works, it has been written somewhat blindly. Also I am afraid
that at least last
On 2013-04-02 12:10:12 +0200, Andres Freund wrote:
On 2013-04-01 08:49:16 +0100, Simon Riggs wrote:
On 30 March 2013 17:21, Andres Freund and...@2ndquadrant.com wrote:
So if the xid is later than latestObservedXid we extend subtrans one by
one. So far so good. But we initialize
On 2013-03-29 14:53:26 -0700, Sergey Konoplev wrote:
On Fri, Mar 29, 2013 at 2:38 PM, Andres Freund and...@2ndquadrant.com wrote:
I have to admit, I find it a bit confusing that so many people report a
bug and then immediately destroy all evidence of the bug. Just seems to
a happen a bit
though, or is
it? I guess its from a new standby?
Andres
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
just remove the column in the next release?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
ISTM the caching code for plpythonu trigger functions has been broken
for some time. The bug seem to be that PLy_procedure_get looks up
On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Its slightly more complex than just making it one hash table with an
extended key. When validating a trigger function we don't have a
relation to do the cache lookup. I chose to handle that case
On 2013-01-25 15:40:46 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
quite possibly doesn't work if copied from here but for quicker viewing:
CREATE OR REPLACE FUNCTION foo():
pass
import os
os._exit(1)
def () RETURNS void LANGUAGE plpythonu AS $$pass
On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
The bug got introduced in 46211da1b84bc3537e799ee1126098e71c2428e8 which
interestingly says Using HTABs instead of Python dictionaries makes
error recovery easier, and allows for procedures
.
Other suggestions?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-24 15:03:36 +0100, Sandro Santilli wrote:
ISTM the caching code for plpythonu trigger functions has been broken
for some time. The bug seem to be that PLy_procedure_get looks up
a bit strange
that NTT stopped maintaining the tool .. Maybe it wasn't useful anymore?
One problem is that it was hard to trust the tool, it had relatively bad
bugs several times and it wasn't maintained by pgdg...
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com
handlers are still setup, this isn't the first bug caused by pl's
or libraries overriding them...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs
DEFINER...
I guess it wouldn't really be feasible to keep the search path used to
plan a query in its cached form and check that it fits the one currently
used on every use of the cached plan?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
On 2012-12-20 22:50:54 +0100, Andres Freund wrote:
On 2012-12-20 21:17:04 +0100, Andres Freund wrote:
On 2012-12-20 12:40:44 +, no...@nix.hu wrote:
The following bug has been logged on the website:
Bug reference: 7763
Logged by: Norbert Buchmuller
Email address
Hi,
On 2012-12-22 16:11:47 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-20 22:50:54 +0100, Andres Freund wrote:
Ok, here are two patches:
* Add a cooked_expr member to IndexElem and use it for transformed
expressions, including filling it directly
. generateClonedIndexStmt gets the expression from
the old index via nodeToString, remaps some attnos, but thats about
it.
ISTM IndexElem grow a cooked_expr member.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
On 2012-12-20 21:17:04 +0100, Andres Freund wrote:
On 2012-12-20 12:40:44 +, no...@nix.hu wrote:
The following bug has been logged on the website:
Bug reference: 7763
Logged by: Norbert Buchmuller
Email address: no...@nix.hu
PostgreSQL version: 9.2.2
Operating
tell us very much. Could you get a backtrace
for that? I don't really see which table should receive such large
tuples...
# SELECT pg_backend_pid();
3493
$ gdb -p 3493
(gdb) b hio.c:24
(gdb) c
# ALTER EXTENSION postgis UPDATE TO 2.1.0SVN;
(gdb) bt full
Greetings,
Andres Freund
--
Andres
Its irritating that the error is happening in that simple_heap_update
where the backtrace indicates the old tuple has a t_len = 7011 and the
only variable length field changed is extversion which shouldn't be that
long.
Greetings,
Andres Freund
--
Andres Freund http://www
is broken this same
way since 9.1. So I no longer think that we need a rewrap.
Imo the bug isn't all that critical, it cause confusion but no data corruption
or such.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On 2012-12-05 13:34:05 +, Simon Riggs wrote:
On 5 December 2012 02:27, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
But the key is, the database was not actually consistent at that
point, and so opening hot standby was a dangerous thing to do
: recovery has paused
HINT: Execute pg_xlog_replay_resume() to continue.
Instead of
FATAL: requested recovery stop point is before consistent recovery point
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On 2012-12-05 11:11:23 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-05 13:34:05 +, Simon Riggs wrote:
@@ -5883,6 +5889,17 @@ StartupXLOG(void)
} while (record != NULL recoveryContinue);
/*
+ * We've reached stop point
On 2012-12-05 11:40:16 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Basically the whole logical arround recoveryApply seems to be broken
currently. Because if recoveryApply=false we currently don't pause at
all because we jump out of the apply loop with the break
On 2012-12-05 18:08:01 +0100, Andres Freund wrote:
On 2012-12-05 11:40:16 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Basically the whole logical arround recoveryApply seems to be broken
currently. Because if recoveryApply=false we currently don't pause at
all
.)));
else
ereport(FATAL,
(errmsg(WAL ends before consistent
recovery point)));
}
}
Seems to be good enough to me. Once the pause logic is fixed obviously.
Greetings,
Andres Freund
--
Andres Freund
On 2012-12-05 13:48:53 -0500, Tom Lane wrote:
I wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-05 17:24:42 +, Simon Riggs wrote:
So ISTM that we should make recoveryStopsHere() return false while we
are inconsistent. Problems solved.
I prefer the previous (fixed
for recoveryLastRecPtr seems to be natural enough.
Greetings,
Andres Freund
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 187b609..e962f62 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5923,6 +5923,10
On 2012-12-05 18:35:47 -0500, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2012-12-05 16:15:38 -0500, Tom Lane wrote:
That's fine, but the immediate question is what are we doing to fix
the back branches. I think everyone is clear that we should be testing
a regression here since
9.2.1, and if so how bad is it?
Not sure.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
seeing in 9.1.6. I'll see if I
can repeat it in 9.1.7 and post the tarball of the data directory.
Could you check whether the attached patch fixes the behaviour?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support
On 2012-12-04 21:27:34 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
But the key is, the database was not actually consistent at that
point, and so opening hot standby was a dangerous thing to do.
The bug that allowed the database to open early (the original topic
anything that would
make it dangerous besides this.
This looks like it also explains #6291 and the slighly different issue
described in CAAZKuFbB7UR3NXV1pkZFRXy=6V1QBq_OeHJWJNTLpKBpH=q...@mail.gmail.com,
as the issue is just as present on standbys as it is on primaries.
Greetings,
Andres Freund
. If the
prepared xacts are suboverflown its a *good* thing to have an old
-nextXid.
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 2012-12-02 00:10:22 +0100, Andres Freund wrote:
On 2012-12-01 17:56:33 -0500, Tom Lane wrote:
So barring objections, I'm going to remove LogStandbySnapshot's behavior
of returning the updated nextXid.
I don't see any reason why it would be bad to remove this. I think the
current
you reproduce the issue? If so, can you give an exact guide? If not,
do you still have the datadir et al. from above?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs
On 2012-11-28 15:37:38 +0200, Heikki Linnakangas wrote:
On 28.11.2012 15:26, Andres Freund wrote:
Hm. Are you sure its actually reading your backup file? Its hard to say
without DEBUG1 output but I would tentatively say its not reading it at
all because the the redo starts at ... message
On 2012-11-28 16:34:55 +0200, Heikki Linnakangas wrote:
On 28.11.2012 15:47, Andres Freund wrote:
I mean the label read by read_backup_label(). Jeff's mail indicated it
had CHECKPOINT_LOCATION at 1/188D8120 but redo started at 1/CD89E48.
That's correct. The checkpoint was at 1/188D8120
On 2012-11-18 19:22:04 +0200, Igor wrote:
2012/11/18 Andres Freund and...@2ndquadrant.com
On 2012-11-18 18:53:13 +0200, Igor wrote:
..
Could you give a bit more context about when exactly that error is
happening?
It would also be helpful if you could set log_error_verbosity
to ...
According to the manpages freebsds poll won't return EINVAL if a
contained fd is invalid... I wonder if the the timeout value is screwed
and overflowed the cast from 'long' to int and got negative.
Igor, I guess youre on a 64bit system?
Greetings,
Andres Freund
--
Andres Freund
On 2012-11-18 17:36:40 +, Peter Geoghegan wrote:
On 18 November 2012 17:12, Andres Freund and...@2ndquadrant.com wrote:
Ok, this is already helpful. Do you have anything the log that shows
what process pid 95528 is? Could you grep for it?
I haven't looked at this in detail, but are you
is unlikely to be set
to something in the month range, thats not an unreasonable value.
I suggest adding an Assert before the (int)timeout cast, but I guess you
already plan to do so.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL
On 2012-11-18 13:18:42 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-18 12:44:55 -0500, Tom Lane wrote:
I'm inclined to propose limiting both of these to the equivalent of 15
days. Alternatively we could try to rejigger things to prevent asking
WaitLatch
On 2012-11-18 14:07:37 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-11-18 13:18:42 -0500, Tom Lane wrote:
Well, we have two reports of people trying such values (assuming that
#7545 actually is the same thing), and it didn't work for either of
them. I don't
is wrong error
from other ERRORs that are expected during normal operation..
Greetings,
Andres Freund
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
some minutes ago confirmed on IRC that the
table is older than the last checkpoint...
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org
Andres Freund
and...@2ndquadrant.com wrote:
We had a similar issue at a customer site. The server was shut down
for updating it from 9.1.4 to 9.1.5, after starting it again the log
was immediately cluttered with
How was it shutdown? -m fast or -m immediate?
-m fast
1 - 100 of 168 matches
Mail list logo
