Re: [BUGS] BUG #5951: ERRO NO INICIO DA INSTALACAO
Em 25-03-2011 17:59, DIEGO BALAN escreveu: aparece a mensagem "please provide a password for the database superuser and service account. if the service account already exists in windows, you must enter the current password for the account. if the account does not exist, it will be created when you click nex" quando eu tento instalar o programa, bem no inicio da instalacao, mas eu nunca instalei o postgree no pc, e o windows nao esta com senha de usuario? o que fazer??? This is not a bug. It is a english only list. Você leu a mensagem? A conta existe? Se ela não existir, o instalador irá criá-la; se existir, você terá que fornecer a senha que colocou. Talvez outro programa tenha instalado o postgres, sem que você saiba. Caso a conta exista e você não lembra da senha, você pode remover o usuário com o comando 'net user postgres /delete' no prompt do DOS. E depois, executar o instalador novamente. O nome do software não é postgree e sim postgres ou postgresql. -- Euler Taveira de Oliveira http://www.timbira.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 #5953: pgadmin sql-query text pad doesn't work
"martin van leeuwen" wrote: > PostgreSQL version: 9.0.2-1-win-x84 > Operating system: windows 7 enterprise SP1 > Description: pgadmin sql-query text pad doesn't work > Details: > > The text input for sql query tool in pgadmin stopped working today > (26 mrch 2011) and was succesfully used the last time on 22 mrch 2011. Something apparently changed besides the date. What? Please read this and post again: http://wiki.postgresql.org/wiki/Guide_to_reporting_problems -Kevin -- 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 #5952: SetRWConflict assertion failure
"YAMAMOTO Takashi" wrote: > Description: SetRWConflict assertion failure > SerializableXactHashLock relocking in CheckTargetForConflictsIn() > seems racy to me. You're right. The attached patch should fix the assertion you hit. I will take a close look at the code above the patched area (for the optimization to drop the predicate lock when we acquire a write lock). Looking at it just now I'm wondering if it really is a safe optimization in PostgreSQL. It was in the Cahill paper, but InnoDB doesn't have subtransactions. I fear that we could give up the SIReadLock within a subtransaction and then have problems if the subtransaction rolls back, effectively discarding the write lock. I suspect we need to do this only if we're not within a subtransaction. Will follow up on that after further review. Thanks! -Kevin ssi-recheck-conflict-in-before-flagging.patch Description: Binary data -- 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 #5946: Long exclusive lock taken by vacuum (not full)
On Fri, Mar 25, 2011 at 4:48 PM, Tom Lane wrote: > Greg Stark writes: >> On Fri, Mar 25, 2011 at 7:43 PM, Tom Lane wrote: >>> I don't recall any particular discussion of making the user contend with >>> that. My thought would be to do something like enlarging the table by >>> 10% anytime we need to extend it. > >> Just for reference this is how Oracle *used* to behave. It was widely >> hated and led to all sorts of problems. Best practice was to pick a >> reasonable size for your tablespace and pre-allocate that size and set >> future increments to be that size with 0% growth. > > Interesting, but I don't understand/believe your argument as to why this > is a bad idea or fixed-size extents are better. It sounds to me just > like the typical Oracle DBA compulsion to have a knob to twiddle. A > self-adjusting enlargement behavior seems smarter all round. I think we've had a number of pieces of evidence that suggest that extending 8kB at a time is too costly, but I agree with Greg that the idea of extending an arbitrarily large table by 10% at a time is pretty frightening - that could involve allocating a gigantic amount of space on a big table. I would be inclined to do something like extend by 10% of table or 1MB, whichever is smaller. If the main goal is to avoid extending the file many times, this will reduce the number of physical file extensions on a table > 10MB in size by more than 99% compared to the current code, which ought to be enough to eliminate this as an issue. And a 1MB extension is probably also small enough that we can do it in the foreground without too much of a hiccup. Now, there's a second effect here that's worth thinking about: allocating in really big chunks might help the filesystem lay out the space more contiguously on disk. But I'd want to see some careful testing that reveals exactly what is needed to get that benefit before we go too crazy with it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5946: Long exclusive lock taken by vacuum (not full)
On Fri, Mar 25, 2011 at 5:56 PM, Tom Lane wrote: > Christopher Browne writes: >> What seems natural-ish to me might include: >> - Stomping a bit on the FSM replacement to make sure nobody's going to >> be writing to the later extensions; >> - Watching free space during the process so the "first" extension gets >> re-opened up if the free space in the much earlier parts of the table >> (e.g. - that are not planned to be dropped off) is running out. > > You seem to be thinking only about the possibility that somebody would > try to write a new tuple into the space-to-be-freed. The problem that > necessitates use of AccessExclusiveLock is that somebody could be doing > a seqscan that tries to *read* the blocks that are about to be truncated > away. We can't really improve matters much here unless we think of a > way to fix that. It would be okay if the scan just ignored blocks it > failed to read, but how do you distinguish the case from a filesystem > error that really should be reported? It's struck me a number of times that it would make some things simpler if we were able to maintain some state in shared memory about the tables people were using - for example, in this case, we could cache the table size, or the fact that vacuum has just truncated away N blocks, or, uh, something. *waves hands* But it's hard to know how such an area could reasonably be sized or managed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- 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 #5946: Long exclusive lock taken by vacuum (not full)
Robert Haas writes: > I think we've had a number of pieces of evidence that suggest that > extending 8kB at a time is too costly, but I agree with Greg that the > idea of extending an arbitrarily large table by 10% at a time is > pretty frightening - that could involve allocating a gigantic amount > of space on a big table. I would be inclined to do something like > extend by 10% of table or 1MB, whichever is smaller. Sure, something like that sounds sane, though the precise numbers need some validation. > ... And a 1MB extension is probably also small enough > that we can do it in the foreground without too much of a hiccup. Less than convinced about this. 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
