On Wed, 2009-01-14 at 08:27 +0200, Heikki Linnakangas wrote:
Thanks for picking this up, despite my report was so vague.
Simon Riggs wrote:
Best way seems to be to do (almost) the same thing as ExtendSubtrans()
during recovery, so we zero out pages at the point that recovering
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
Normally, GetRunningTransactionData determines the xid of the latest
running xid by scanning the procarray. If the subxid cache has
overflowed, it simply gives up. Comment there suggests that it could
call ReadNewTransactionId()
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or
Thanks for picking this up, despite my report was so vague.
Simon Riggs wrote:
Best way seems to be to do (almost) the same thing as ExtendSubtrans()
during recovery, so we zero out pages at the point that recovering
transactions get written to pg_subtrans.
Yep.
Do we have the same bug with
On Wed, 2009-01-07 at 22:08 +, Simon Riggs wrote:
On Wed, 2009-01-07 at 23:56 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid instead of
Simon Riggs wrote:
On Wed, 2009-01-07 at 22:08 +, Simon Riggs wrote:
On Wed, 2009-01-07 at 23:56 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or
On Thu, 2009-01-08 at 12:12 +0200, Heikki Linnakangas wrote:
Sounds good to me then. Will rework.
Applies brakes suddenly.
I realise this is subtle trap I almost fell into the first time I coded
it. The function is retrieving GetRunningTransactionData() and so we are
interested
Simon Riggs wrote:
* btree VACUUM code - must scan every block of index (v6)
Need to unlock them too.
--- a/src/backend/access/nbtree/nbtxlog.c
+++ b/src/backend/access/nbtree/nbtxlog.c
@@ -472,7 +472,7 @@ btree_xlog_vacuum(XLogRecPtr lsn, XLogRecord *record)
xlrec =
On Wed, 2009-01-07 at 11:35 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* btree VACUUM code - must scan every block of index (v6)
Need to unlock them too.
Oh c**p. Thanks.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or directory.
in the standby after some testing.
I created a lot of
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
There's still something wrong with the way subtransactions are handled.
I got:
postgres=# SELECT * FROM foo;
ERROR: could not access status of transaction 118649
DETAIL: Could not open file pg_subtrans/0001: No such file or
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6b now available via Wiki, fixes 5 reported issues.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and
Another annoyance I noticed while testing the case of a lot of
subtransactions (overflowing the procarray cache) is that when you have
a transaction with a lot of subtransactions open, getting the initial
snapshot fails, and the standby doesn't open for read-only queries.
Normally,
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
Another annoyance I noticed while testing
I'm sorry this has annoyed you. Thanks for testing.
the case of a lot of
subtransactions (overflowing the procarray cache) is that when you have
a transaction with a lot of
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid instead of calling ReadNewTransactionId()?
latestCompletedXid is protected by ProcArrayLock so not much difference
between those two.
On Wed, 2009-01-07 at 23:56 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
When there's no xids in the procarray, couldn't we just use
latestCompletedXid instead of calling ReadNewTransactionId()?
latestCompletedXid is
On Sun, 2009-01-04 at 21:03 +1300, Mark Kirkwood wrote:
bench=# select now(),count(*) from history;
ERROR: could not open relation base/16384/16394: No such file or
directory
Thanks for the report.
I'm attempting to recreate now.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
Simon Riggs wrote:
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6 of Hot Standby now uploaded to Wiki (link above), with these changes:
* Must ignore_killed_tuples and never
Simon Riggs wrote:
On Sun, 2009-01-04 at 21:03 +1300, Mark Kirkwood wrote:
bench=# \d history
Table public.history
Column |Type | Modifiers
+-+---
tid| integer |
bid| integer
On Sun, 2009-01-04 at 22:18 +1300, Mark Kirkwood wrote:
bench=# select now(),count(*) from history;
ERROR: could not open relation base/16384/16394: No such file or
directory
I'm guessing something tied up with the fact that history has no rows
to
start with...
Good guess,
On Sun, 2009-01-04 at 21:03 +1300, Mark Kirkwood wrote:
bench=# \d history
Table public.history
Column |Type | Modifiers
+-+---
tid| integer |
bid| integer |
On Sun, 2009-01-04 at 22:13 +1300, Mark Kirkwood wrote:
Simon Riggs wrote:
Is the file actually missing? i.e. ls -l mydatadir/base/16384/16394*
Yeah -
$ ls -l $PGDATA/base/16384/16394*
ls: /data0/pgslave/8.4/base/16384/16394*: No such file or directory
What else is missing? Files,
Mark Kirkwood wrote:
Simon Riggs wrote:
On Sun, 2009-01-04 at 21:03 +1300, Mark Kirkwood wrote:
bench=# \d history
Table public.history
Column |Type | Modifiers
+-+---
tid| integer |
Simon Riggs wrote:
On Sun, 2009-01-04 at 22:18 +1300, Mark Kirkwood wrote:
bench=# select now(),count(*) from history;
ERROR: could not open relation base/16384/16394: No such file or
directory
I'm guessing something tied up with the fact that history has no rows
to
start with...
What I ifind interesting about this is that whereas I had been
concerned that adding hot standby late in the development cycle might
be destabilize the tree and add lots of time to the release cycle it
seems having it might actually increase our ability to see problems in
the recovery code
Heikki Linnakangas wrote:
I can reproduce that too with CVS HEAD, so it's clearly a bug. I
probably introduced it with the recent smgr changes; I'll try to hunt it
down.
Now that was an embarrassingly simple bug:
--- a/src/backend/catalog/storage.c
+++ b/src/backend/catalog/storage.c
@@
On Fri, 2009-01-02 at 17:35 +, Simon Riggs wrote:
I use latest CVS version. I tried to apply the patches and I have the
following error :
Thanks, will fix.
Fixed various bit rots and re-packaged. v6a now up, v6 unlinked.
Thanks,
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs a écrit :
On Fri, 2009-01-02 at 17:35 +, Simon Riggs wrote:
I use latest CVS version. I tried to apply the patches and I have the
following error :
Thanks, will fix.
Fixed various bit rots and re-packaged. v6a now up, v6 unlinked.
Thanks. I only did a few checks and it
Simon Riggs a écrit :
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6 of Hot Standby now uploaded to Wiki (link above), with these changes:
* Must ignore_killed_tuples and never
On Fri, 2009-01-02 at 11:02 +0100, Guillaume Lelarge wrote:
Simon Riggs a écrit :
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6 of Hot Standby now uploaded to Wiki (link
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch.
v6 of Hot Standby now uploaded to Wiki (link above), with these changes:
* Must ignore_killed_tuples and never kill_prior_tuple during
Simon Riggs wrote:
* corner case behaviour of backendids - bgwriter writes checkpoint WAL
records. Has no backendid, but needs a slotid (possibly others)
Why does bgwriter need a slotid? It doesn't run any transactions.
* slotids are assigned once and never changed, so allowing them to be
On Fri, 2008-12-19 at 10:59 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* corner case behaviour of backendids - bgwriter writes checkpoint WAL
records. Has no backendid, but needs a slotid (possibly others)
Why does bgwriter need a slotid? It doesn't run any transactions.
*
Simon Riggs wrote:
On Fri, 2008-12-19 at 10:59 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
* corner case behaviour of backendids - bgwriter writes checkpoint WAL
records. Has no backendid, but needs a slotid (possibly others)
Why does bgwriter need a slotid? It doesn't run any
Heikki Linnakangas wrote:
Well, to be honest, I don't much like the whole notion of tracking the
slots. I think we should just rely on the XLOG_RECOVERY_END records to
purge stale PGPROC entries, belonging to backends that died without
writing an abort record.
Sorry, I meant
On Fri, 2008-12-19 at 14:00 +0200, Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Well, to be honest, I don't much like the whole notion of tracking the
slots. I think we should just rely on the XLOG_RECOVERY_END records to
purge stale PGPROC entries, belonging to backends that died
Can't we use the existing backendid in place of the slot id?
(sorry if this has been discussed already; can't remember)
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, 2008-12-18 at 15:13 +0200, Heikki Linnakangas wrote:
Can't we use the existing backendid in place of the slot id?
(sorry if this has been discussed already; can't remember)
Exactly the sort of question we need, but unfortunately I'm a little
hazy, but I just woke up some maybe some
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch. This is still at
v5, just brought forward to CVS HEAD.
I will be doing further work on the patch from here and will reply to
this post
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch. This is still at
v5, just brought forward to CVS HEAD.
I will be doing further work on the patch from here and will reply to
this post each time I submit a new version.
--
Simon Riggs
On Wed, 2008-12-17 at 15:21 +, Simon Riggs wrote:
http://wiki.postgresql.org/wiki/Hot_Standby
now contains a link to latest version of this patch. This is still at
v5, just brought forward to CVS HEAD.
I will be doing further work on the patch from here and will reply to
this post
42 matches
Mail list logo
