On 2013-10-03 19:07:37 +0200, Tom Lane wrote:
> Andres Freund 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 i
To reproduce do something like:
# become root
su
# change into root-only directory
cd /root
# switch user, without changing directory
su postgres
# execute postgres
/path/to/postgres -D frakbar
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Deve
ycle - 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
--
Andr
olumns?
* Was there any preexisting 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.c
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
On 2013-08-30 19:28:39 -0400, Tom Lane wrote:
> Andres Freund 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 cov
On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> Andres Freund 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,
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
> Andres Freund 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.
>
> S
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 sp
hat introduced that message, I'd 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
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 p
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 eleme
On 2013-08-30 17:23:51 -0400, Tom Lane wrote:
> Andres Freund 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.
>
> S
ely acceptable.
>
>
> So, drop the type and recreate it with these statements:
>
>
> drop type testPop;
>
>
> create type testPop as (
> FOOBAR int
> );
Postgresql lowercases unquoted identifiers. Make that »"FOOBAR" int« and
it should wor
see whether 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
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
--
Andres Freund
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
> >
oduce yours.
Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe
NextMultiXactId/Offset using pg_resetxlog?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
o be sure, you're not running with full_page_writes = off or
something?
Could you possibly run a patched postgres against that, to get more
info?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On 2013-07-25 11:50:47 -0400, Tom Lane wrote:
> Andres Freund 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, af
On 2013-07-25 09:48:31 -0400, Tom Lane wrote:
> Andres Freund 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 compatibl
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 :
> > > On 2013-06-30 10:43:49 +, e...@hasegeli.com wrote:
> > > Could you attach config.log?
> >
> > At
http://git.postgresql.org/gitweb/?p=postgresql.git;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.co
t; --> gives 3
>
>
> Obviously both should return the same thing, preferably 3.
> 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 di
rom 9.2 that reproduces 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 su
oo big implications.
If you're worried you could do a SetHintBits(HEAP_XMAX_INVALID) like
it's done if xmin isn't in progress like it's done when xmin has
committed.
> Perhaps it'd be smart to optimize it a bit so that we first check the
> flags, and only call the
On 2013-07-01 09:19:23 -0400, Tom Lane wrote:
> Peter Eisentraut 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
>
way it's emitted - users
encountering them, which usually will be on less common platforms, will
have to patch configure.in to make things work for them. Which is a high
bar.
Given that many of those warnings will *NOT* completely prohibit them
from building postgres that might be over
On 2013-06-30 10:17:50 -0400, Andrew Dunstan wrote:
>
> On 06/30/2013 09:49 AM, Tom Lane wrote:
> >Andrew Dunstan writes:
> >>>On 2013-06-30 15:17:20 +0200, Andres Freund wrote:
> >>>>Andrew: Could we perhaps check for the "Report this to" bit in
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
On 2013-06-30 15:11:24 +0300, Emre Hasegeli wrote:
> 2013/6/30 Andres Freund :
> > 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 li
d.h... yes
Could you attach config.log?
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
too kludgey
- was to simply delay the creation of all comments and restore them
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,
: 170 170
1950; 0 0 COMMENT public INDEX tbl_test_pkey andres
; depends on: 1833
unsurprisingly after that restore completes.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --g
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 Lane wrote:
> >>> (Though if it is, it's not apparent why such
>
d might not cause errors that are as noticeable.
We 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://w
On 2013-06-18 23:30:44 -0400, Tom Lane wrote:
> Andres Freund 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
e abort even looking at further WHEN clauses if we 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/
Postg
that
via the extended protocol, outside 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@postgres
ocally vs 55s remotely. You need 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
dump to complete in
> seconds rather than minutes.
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
--
e a perf profile like:
# start_test
# perf record -a
# ctrl-C
# 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
el=hot_standby.
I think we will have to resort to running it more frequently in the not
too far away future, its way to easy to get into a situation where all
of the checkpoints/xl_running_xact's are suboverflowed delaying
consistency considerably.
Seems more consistent with the rest
everything is fine no lag at all.
>
> At moment as workaround I've switched to warm standby the slaves as, despite
> the low wal generation on the master ~200Mb/minute the slave accumulates a
> massive lag when the autovacuum processes starts with hot standby (the peak
>
@sss.pgh.pa.us
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
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 w
On 2013-04-12 10:47:52 -0400, Tom Lane wrote:
> Andres Freund 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 transactio
will preserve rows that are still visible
to some existing transaction while CREATE TABLE ... LIKE won't.
Typical suspects would be longrunning (idle in) transactions or prepared
transactions.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
P
d the transaction so
there's nothing that could flush the transaction unless we we would
*always* flush nextval() immediately if needs to get new values which
doesn't seem reasonable.
I think a reasonable compromise would be that nextval_internal()
acquires a real xid (by calling GetTopTr
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
> >>w
least not using the same timeout as actual WAL
sending, thats just has different characteristics.
On the other hand, hanging around 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 b
On 2013-04-05 07:22:08 -0700, Sergey Konoplev wrote:
> On Fri, Apr 5, 2013 at 7:15 AM, Andres Freund 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
On 2013-04-05 07:10:12 -0700, Sergey Konoplev wrote:
> On Tue, Apr 2, 2013 at 11:26 AM, Andres Freund 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.
>
>
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 wrote:
> >
> > > So if the xid is later than latestObservedXid we extend subtrans one by
> > > one. So far
On 2013-04-01 08:49:16 +0100, Simon Riggs wrote:
> On 30 March 2013 17:21, Andres Freund wrote:
>
> > So if the xid is later than latestObservedXid we extend subtrans one by
> > one. So far so good. But we initialize it in
> > ProcArrayApplyRecoveryInfo() when consiste
On 2013-03-29 14:53:26 -0700, Sergey Konoplev wrote:
> On Fri, Mar 29, 2013 at 2:38 PM, Andres Freund 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
veXID: 421766298
> Time of latest checkpoint:Птн 29 Мар 2013 22:33:01
Thats not a pg_controldata output from the broken replica though, or is
it? I guess its from a new standby?
Andres
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.co
On 2013-03-06 09:27:55 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I don't find this particularly suprising. Nothing looks at that field in
> > sequences, there imo is no point on having the name inside at all.
>
> Yeah, and we really can't update the
y don't see any way to nicely fix that. We can add code to
also change the contents, but currently thats generic code. Or we could
just remove the column in the next release?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development,
On 2013-01-25 17:07:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > The bug got introduced in 46211da1b84bc3537e799ee1126098e71c2428e8 which
> > interestingly says "Using HTABs instead of Python dictionaries makes
> > error recovery easier, and allows for proced
On 2013-01-25 15:40:46 -0500, Tom Lane wrote:
> Andres Freund 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)
>
On 2013-01-25 21:07:51 +0100, Andres Freund wrote:
> On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > Its slightly more complex than just making it one hash table with an
> > > extended key. When validating a trigger function we don't
On 2013-01-25 14:51:39 -0500, Tom Lane wrote:
> Andres Freund 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 th
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
> Andres Freund 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
repair. That would be unfortunate.
I wonder whether we could place some Assert's somewhere that verify our
signal handlers are still setup, this isn't the first bug caused by pl's
or libraries overriding them...
Greetings,
Andres Freund
--
Andres Freund http://ww
s intentionally broken by
> changing XLR_BKP_REMOVABLE to XLP_BKP_REMOVABLE (different semantics?)
> and the fixes to make it compile again look simple. It's a bit strange
> that NTT stopped maintaining the tool .. Maybe it wasn't useful anymore?
One problem is tha
On 2013-01-24 11:40:33 -0500, Tom Lane wrote:
> Andres Freund 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
ly refers to the old table that has been dropped we see
the above error.
The fix seems tob e to make PLy_trigger_cache have a key of (reloid,
fn_oid) instead of just fn_oid.
Other suggestions?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL D
On 2013-01-12 15:13:51 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
> >> I think that the alternative most likely to succeed is to consider any
> >> change in the active value of search_path as forcing replanning of
at least the latter should
still work without forcing to replan any query. Given that we advice
setting the search path for SECURITY 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
Hi,
On 2012-12-22 16:11:47 -0500, Tom Lane wrote:
> Andres Freund 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
> >> expressio
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
> >
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
2".
Concretely that seems to be transformRowExpr's fault. It overwrites
row_typeid even though its marked as COERCE_EXPLICIT_CAST.
Now the original problem seems to be that we are transforming an already
transformed expression. generateClonedIndexStmt gets the expression from
th
o.org/postgis/ticket/1959
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
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 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
hat already?
SET log_error_verbosity = 'verbose';
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
On 2012-12-05 18:35:47 -0500, Tom Lane wrote:
> Andres Freund 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 te
> acquisition is not worth the cost.
Seems safe enough to me. But I am not sure its necessary, if we move
the recoveryPausesHere() down after replaying the record, fetching
inside the spinlock for recoveryLastRecPtr seems to be natural enough.
Greetings,
Andres Freund
diff --git a/src/backen
On 2012-12-05 13:48:53 -0500, Tom Lane wrote:
> I wrote:
> > Andres Freund 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 s
ine backup started
with pg_start_backup() must be ended with pg_stop_backup(), and all WAL up to
that point must be available at recovery.")));
else
ereport(FATAL,
(errmsg("WAL ends before consistent
On 2012-12-05 18:08:01 +0100, Andres Freund wrote:
> On 2012-12-05 11:40:16 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > Basically the whole logical arround recoveryApply seems to be broken
> > > currently. Because if recoveryApply=false we currently don'
On 2012-12-05 11:40:16 -0500, Tom Lane wrote:
> Andres Freund 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
On 2012-12-05 11:11:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2012-12-05 13:34:05 +, Simon Riggs wrote:
> >> @@ -5883,6 +5889,17 @@ StartupXLOG(void)
> >> } while (record != NULL && recoveryContinue);
> >>
> >> /*
> >&g
will get:
LOG: 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
On 2012-12-05 13:34:05 +, Simon Riggs wrote:
> On 5 December 2012 02:27, Tom Lane wrote:
> > Andres Freund 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.
>
use logic 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
On 2012-12-04 21:27:34 -0500, Tom Lane wrote:
> Andres Freund 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 databa
hat the connection
> > is to the original report against 9.1.6.
>
> The behavior that we both see in 9.2.2, where it waits for a
> pg_xlog_replay_resume() that cannot be delivered because the database
> is not yet open, is the same thing I'm seeing in 9.1.6. I'll see if
03 00:08:54 CET
So the target xid far before the backend end, so it seems absolutely
correct not to permit access yet.
So maybe I am (again) missing something here, but everything looks fine.
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Supp
ther to withdraw
> 9.2.2 and issue a hasty 9.2.3. Do we have 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
--
S
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 t
to an active state
slightly in the presence of prepared transactions because its used to
create to initialize the KnownAssignedXid machinery in xlog_redo. 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
TLpKBpH=q...@mail.gmail.com,
as the issue is just as present on standbys as it is on primaries.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
>From bf1ff10acf7dbfd9a6046c5fcb4bb816485a1e7b Mo
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 c
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 th
ing 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 indicates its not using
the checkpoint location from the backup file.
Can you reproduce the issue? If so, can you give an exact
On 2012-11-18 14:07:37 -0500, Tom Lane wrote:
> Andres Freund 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 eit
On 2012-11-18 13:18:42 -0500, Tom Lane wrote:
> Andres Freund 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 preve
timeout isn't really likely to be
that high I don't think the log_rotation_age one 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 F
1 - 100 of 181 matches
Mail list logo
