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
> > t
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 E
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 fil
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 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
>
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 fil
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 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
> > >> latestCompletedX
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()?
> >
> > latestCom
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 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 subtrans
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, GetRunningT
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 Su
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 fil
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 s
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 vi
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 = (xl_btree_vacuum
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
@@ -106,
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...
Goo
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
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: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 miss
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 |
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
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 ki
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
PostgreSQ
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 ch
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
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
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
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 in
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 tha
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 XLOG_XACT_RUNNING
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 transact
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:
* 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
use
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
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 som
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 subscription
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
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 w
42 matches
Mail list logo
