Re: [BUGS] BUG #8001: Cannot install Slony
Hi, This is not really a PostgreSQL bug, so you should contact directly Slony people using a mailing list like this one: http://lists.slony.info/mailman/listinfo/slony1-general Thanks, -- Michael
Re: [BUGS] Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
Heikki Linnakangas writes: > This bug was introduced by commit > 8805ff6580621d0daee350826de5211d6bb36ec3, in 9.2.2 (and 9.1.7 and > 9.0.11), which fixed multiple WAL replay issues with Hot Standby. Ooops. Thanks for finding that. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8001: Cannot install Slony
The following bug has been logged on the website: Bug reference: 8001 Logged by: Eduardo Email address: eimbass...@yahoo.com.br PostgreSQL version: 8.4.11 Operating system: windows7 Home Premium SP1 i64 Description: I,m trying to install the Slony in my Postgres 8.4. I,ve copied the binaries to the directory \"Program Files (x86)"\Postgresql\8.4\ when try to register the servive using the command line "slon -regservice Slony-I" I've got the error "Failed to create service: 1057" that means the account use have no privileges to do that. Then I've register the service usin the "sc" command: -- "sc create Slony-I binPath= "c:\Program Files (x86)\PostgreSQL\8.4\bin\slon.exe -service" depend= "RPCSS"". This worked. Then I've created the pgbench schema in my database using de command "pgbench -i -U postgres master -P postgres -p 5432" and included the the primary key in the history table. I've created the master and slave configuration files cluster_name='pgbench' conn_info='host=127.0.0.1 port=5432 user=postgres dbname=Master' then added both in Slony confivuration with the comand line slon -addengine Slony-I C:\slony\master.conf slon -addengine Slony-I C:\slony\slave.conf Restarted the Slony-I service. Changed the Slony path to "C:\Program Files (x86)\PostgreSQL\8.4\share" Tried to create a Slony cluster under the master database. cluster name: pgbench Local node: 1 master Admin node: 99 Admin press and got an error type "_pgbench.xxid" does not exist. I need help to anderstand what is hapening, how to install the Slony and how to create the .xxid type. thanks. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
On 27.03.2013 21:04, Heikki Linnakangas wrote:
On 27.03.2013 20:27, Josh Berkus wrote:
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
It seems like a new issue. At a quick glance, I think there's a bug in
heap_xlog_update, ie. the redo routine of a heap update. If the new
tuple is put on a different page, and at redo, the new page doesn't
exist (that's normal if it was later vacuumed away), heap_xlog_update
leaks a pin on the old page. Here:
{
nbuffer = XLogReadBuffer(xlrec->target.node,
ItemPointerGetBlockNumber(&(xlrec->newtid)),
false);
if (!BufferIsValid(nbuffer))
return;
page = (Page) BufferGetPage(nbuffer);
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
{
UnlockReleaseBuffer(nbuffer);
if (BufferIsValid(obuffer))
UnlockReleaseBuffer(obuffer);
return;
}
}
Notice how in the first 'return' above, obuffer is not released.
I'll try to create a reproducible test case for this, and fix..
Ok, here's how to reproduce it:
create table foo (i int4 primary key);
insert into foo select generate_series(1,1000);
checkpoint;
-- update a tuple from the first page, new tuple goes to last page
update foo set i = 1 where i = 1;
-- delete everything on pages > 1
delete from foo where i > 10;
-- truncate the table, including the page the updated tuple went to
vacuum verbose foo;
pg_ctl stop -m immediate
This bug was introduced by commit
8805ff6580621d0daee350826de5211d6bb36ec3, in 9.2.2 (and 9.1.7 and
9.0.11), which fixed multiple WAL replay issues with Hot Standby. Before
that commit, replaying a heap update didn't try to keep both buffers
locked at the same time, which is necessary for the correctness of hot
standby. The patch fixed that, but missed releasing the old buffer in
this corner case. I was not able to come up with a scenario with
full_page_writes=on where this would fail, but I'm also not 100% sure it
can't happen.
I scanned through the commit, and couldn't see any other instances of
this kind of a bug. heap_xlog_update is more complicated than other redo
functions, with all the return statements inside it. It could use some
refactoring, but for now, I'll commit the attached small fix.
- Heikki
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 595dead..860fd20 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -5367,7 +5367,11 @@ newt:;
ItemPointerGetBlockNumber(&(xlrec->newtid)),
false);
if (!BufferIsValid(nbuffer))
+ {
+ if (BufferIsValid(obuffer))
+UnlockReleaseBuffer(obuffer);
return;
+ }
page = (Page) BufferGetPage(nbuffer);
if (XLByteLE(lsn, PageGetLSN(page))) /* changes are applied */
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
On 27.03.2013 20:27, Josh Berkus wrote:
Folks,
So I'm a bit surprised that this bug report hasn't gotten a follow-up.
Does this sound like the known 9.2.2 corruption issue, or is it
potentially something else?
It seems like a new issue. At a quick glance, I think there's a bug in
heap_xlog_update, ie. the redo routine of a heap update. If the new
tuple is put on a different page, and at redo, the new page doesn't
exist (that's normal if it was later vacuumed away), heap_xlog_update
leaks a pin on the old page. Here:
{
nbuffer = XLogReadBuffer(xlrec->target.node,
ItemPointerGetBlockNumber(&(xlrec->newtid)),
false);
if (!BufferIsValid(nbuffer))
return;
page = (Page) BufferGetPage(nbuffer);
if (XLByteLE(lsn, PageGetLSN(page)))/* changes are applied
*/
{
UnlockReleaseBuffer(nbuffer);
if (BufferIsValid(obuffer))
UnlockReleaseBuffer(obuffer);
return;
}
}
Notice how in the first 'return' above, obuffer is not released.
I'll try to create a reproducible test case for this, and fix..
- Heikki
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Re: BUG #7969: Postgres Recovery Fatal With: "incorrect local pin count:2"
Folks, So I'm a bit surprised that this bug report hasn't gotten a follow-up. Does this sound like the known 9.2.2 corruption issue, or is it potentially something else? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7999: Regexp with utf8
somloiea...@gmail.com writes: > PostgreSQL version: 9.1.8 > I've checked with a few other characters which are >1byte in utf8. U+00F0 > counds as \w, but nothing I've tried > FF matches. I wonder if it's > something to do with >256? Yup. This is partially resolved in PG 9.2, but will never be fixed in older branches. From the commit log: Also, remove the hard-wired limitation to not consider wctype.h results for character codes above 255. It turns out that we can't push the limit as far up as I'd originally hoped, because the regex colormap code is not efficient enough to cope very well with character classes containing many thousand letters, which a Unicode locale is entirely capable of producing. Still, we can push it up to U+7FF (which I chose as the limit of 2-byte UTF8 characters), which will at least make Eastern Europeans happy pending a better solution. Thus, this commit resolves the specific complaint in bug #6457, but not the more general issue that letters of non-western alphabets are mostly not recognized as matching [[:alpha:]]. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #8000: ExclusiveLock on a simple SELECT ?
On 27.03.2013 15:07, roberto.menon...@netspa.it wrote: after upgrading to version 9.2.3 we having a performance degradation. We are investigating the matter on several fronts. We've seen that Postgres (9.2.3) creates ExclusiveLock even with simple SELECT * From myschema.mytable. You mean like this: postgres=# create table mytable(i int4); CREATE TABLE postgres=# begin; BEGIN postgres=# select * from mytable; i --- (0 rows) postgres=# select * from pg_locks; locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | gran ted | fastpath +--+--+--+---++---+- +---+--++---+-+- +-- relation |12010 |11069 | | || | | | | 1/3| 19811 | AccessShareLock | t | t relation |12010 |16482 | | || | | | | 1/3| 19811 | AccessShareLock | t | t virtualxid | | | | | 1/3| | | | | 1/3| 19811 | ExclusiveLock | t | t (3 rows) That last ExclusiveLock is on the transactions virtual transactaction ID. Not on the table. There is no change from previous versions here. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8000: ExclusiveLock on a simple SELECT ?
The following bug has been logged on the website: Bug reference: 8000 Logged by: Roberto Email address: roberto.menon...@netspa.it PostgreSQL version: 9.2.3 Operating system: CentOS 5.6 (Final) Description: Hy, after upgrading to version 9.2.3 we having a performance degradation. We are investigating the matter on several fronts. We've seen that Postgres (9.2.3) creates ExclusiveLock even with simple SELECT * From myschema.mytable. Is it normal ? Thank you -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7999: Regexp with utf8
The following bug has been logged on the website: Bug reference: 7999 Logged by: david Email address: somloiea...@gmail.com PostgreSQL version: 9.1.8 Operating system: linux Description: \y and \Y do not behave correctly next to multibyte utf-8 characters - they seem to invert their sensesː Propper behaivour with ascii e 'es'~$$\y[eɛ]s$$ => t Inverted behaviour with epsilon 'ɛs'~$$\y[eɛ]s$$ => f 'ɛs'~$$[eɛ]\ys$$ => t 'ɛs'~$$[eɛ]\Ys$$ => f This seems to be a case of utf8 characters not being recognised as word-forming: 'ɛ'~$$\w'$$ => f I've checked with a few other characters which are >1byte in utf8. U+00F0 counds as \w, but nothing I've tried > FF matches. I wonder if it's something to do with >256? In case anyone else hits this bug, replacing \y with (^|$|\s|[[:punct:]]) seems to work for me, although it's ugly. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
