ERROR: setval: value 0 is out of bounds for sequence "foo_id_seq"
(1..9223372036854775807)
FATAL: block 0 of 1663/97972/98006 is still referenced (private 1,
global
1)
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while p
There exists a crash that could easily be used as a denial of service
against PostgreSQL by any user who can call a trusted stored procedure
that makes use of temp tables.
What this is actually exposing is a case where CurrentResourceOwner is
left pointing at garbage. PortalRun saves and restores
When making lots of DDL changes to a database (I believe this includes
temp tables too), delayed flushing of dirty buffers from the system
catalogs is causing a severe problem with maintaining a consistent
view
of the structure of the database.
This analysis is completely bogus.
That doesn't surpr
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Under beta3, the following behaviour is observed:
> test=# create or replace function execute_sql(text) returns void AS $$begin
> execute $1; return; end; $$ language plpgsql;
> CREATE FUNCTION
> test=#
> test=# select execute_sql('create tabl
Sean Chittenden <[EMAIL PROTECTED]> writes:
> When making lots of DDL changes to a database (I believe this includes
> temp tables too), delayed flushing of dirty buffers from the system
> catalogs is causing a severe problem with maintaining a consistent view
> of the structure of the database.
Sean Chittenden <[EMAIL PROTECTED]> writes:
> There exists a crash that could easily be used as a denial of service
> against PostgreSQL by any user who can call a trusted stored procedure
> that makes use of temp tables.
What this is actually exposing is a case where CurrentResourceOwner is
lef
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> This code works correct in 7.4.1-dbExperts but also fails in
> 7.3.4-dbExperts.
As you say, this has been fixed in 7.4. We considered the fix not
a suitable candidate for back-patching into older releases.
regards, to
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, this has been on my to-do list for awhile...
> Ah, ok. Is this something you want to handle, or should I take a look?
Well, it's not *high* on my to-do list; feel free to take a look.
>> One question here is whether Oracle's PL/S
The following bug has been logged online:
Bug reference: 1278
Logged by: Michael Howitz
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.3.7
Operating system: 2.6.8-gentoo-r3
Description:PL/pgSQL: ROWTYPE does not care for droped columns
Details:
IF you d
There exists a crash that could easily be used as a denial of service
against PostgreSQL by any user who can call a trusted stored procedure
that makes use of temp tables. This DoS does not exist without the use
of a stored procedure (from what I can tell). The gist of it being:
CREATE DATABA
Tom Lane wrote:
Yeah, this has been on my to-do list for awhile...
Ah, ok. Is this something you want to handle, or should I take a look?
One question here is whether Oracle's PL/SQL has a
precedent, and if so which way does it point?
I did some limited testing of this, and it appears that PL/SQL's
When making lots of DDL changes to a database (I believe this includes
temp tables too), delayed flushing of dirty buffers from the system
catalogs is causing a severe problem with maintaining a consistent view
of the structure of the database. For these examples, I'd create a
quick Makefile t
set nomail
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
13 matches
Mail list logo