On Mon, Feb 21, 2011 at 10:46 PM, Daniel Farina wrote:
> It may also be useful information to know that no recent shenanigans
> have happened on this server: it's been up continuously for about 500
> days. That doesn't mean something interesting did not occur a very
> long time ago, and I'm curren
On Tue, Feb 22, 2011 at 7:14 AM, Mark Kirkwood
wrote:
> On 22/02/11 19:47, Heikki Linnakangas wrote:
>>
>> A long query on the same table can block vacuum. Vacuum needs to take a
>> so-called "cleanup lock" on each page, which means that it has to wait until
>> no other backend holds a pin on the
On Tue, Feb 22, 2011 at 8:48 AM, Daniel Farina wrote:
> The modern namespace OID is
> 378382, which is in line with a smooth monotonic increase over time.
Wait, what? namespace OID is the OID of the schema. The OID of an
object doesn't change over the lifetime of the object, it's a unique
identi
The following bug has been logged online:
Bug reference: 5897
Logged by: Nilson
Email address: laut...@uol.com.br
PostgreSQL version: 9.0
Operating system: Windows XP
Description:INSTALACAO
Details:
Srs.
Não estou conseguinda instalar o postgres na minha maquina.
C
On Thu, Feb 17, 2011 at 5:05 PM, gunziptarball wrote:
>
> I too am experiencing this problem, which has only appeared today. I have
> been running queries against million-record sized tables...so it was using
> probably a bunch of memory. My entire computer froze mid-work as I was
> typing in a
On Tue, Feb 22, 2011 at 6:26 AM, Greg Stark wrote:
> Actually it's not waiting for the LockBuffer LWLock. it's waiting
> until your query unpins the buffer it wants. Vacuum tries to get an
> exclusive lock on the buffer, if it gets it then it checks if anyone
> is using that buffer. If someone is
"Nacho Mezzadra" wrote:
> could not start server
> PostgreSQL 8.3 started successfully
That looks like a packaging problem. The lines starting with
uppercase letters appear to have come from the service script, not
PostgreSQL itself.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@
Daniel Farina writes:
> From what I can tell, people only see this problem with pg_dump, which
> is interesting. This symptom has a very long history:
Yeah. There seems to be some well-hidden bug whereby dropping an object
sometimes fails to drop (some of?) its dependencies. I'm still looking
f
The following bug has been logged online:
Bug reference: 5898
Logged by: Scott Dunbar
Email address: sc...@xigole.com
PostgreSQL version: 9.0.3
Operating system: Ubuntu 10.10
Description:Nested "in" clauses hide bad column names
Details:
I have a nested in clause li
"Scott Dunbar" writes:
> I have a nested in clause like:
> select respondent_id from respondent where respondent_id in (select
> respondent_id from chat_session where project_id in (select project_id from
> project where company_id = 4));
> However, in this example, there is no column named resp
Yes, you're correct. I guess this makes sense but it does seem strange
that I can enter garbage in a query but it still runs. And in my case
the output from this (the entire table) was then used in a delete
statement that toasted the entire table. Allowing bogus SQL just seems
"wrong" but I
On Tue, Feb 22, 2011 at 8:54 AM, Tom Lane wrote:
> Daniel Farina writes:
>> From what I can tell, people only see this problem with pg_dump, which
>> is interesting. This symptom has a very long history:
>
> Yeah. There seems to be some well-hidden bug whereby dropping an object
> sometimes fail
Scott Dunbar wrote:
> I guess this makes sense but it does seem strange that I can enter
> garbage in a query but it still runs.
It wasn't garbage.
> And in my case the output from this (the entire table) was then
> used in a delete statement that toasted the entire table.
I can suggest a
On 23/02/11 00:26, Greg Stark wrote:
It's also possible there's a bug of course. If someone was using that
buffer and somehow failed to notify the vacuum that they were done it
would wait for a very long time (forever?). However if vacuum
eventually continued when the query was canceled then it
On 23/02/11 03:27, Robert Haas wrote:
On Tue, Feb 22, 2011 at 6:26 AM, Greg Stark wrote:
Actually it's not waiting for the LockBuffer LWLock. it's waiting
until your query unpins the buffer it wants. Vacuum tries to get an
exclusive lock on the buffer, if it gets it then it checks if anyone
is
Using table aliases prevents such problems by disambiguating the column
names. For example, if you had table aliases in just one part of this
query as in the below, you would have gotten an error instead of
deleting all those rows:
select respondent_id from respondent where respondent_id in (s
16 matches
Mail list logo
