The following bug has been logged online:
Bug reference: 5946
Logged by: Maxim Boguk
Email address: maxim.bo...@gmail.com
PostgreSQL version: 8.4
Operating system: Linux
Description:Long exclusive lock taken by vacuum (not full)
Details:
From documentation I know
The following bug has been logged online:
Bug reference: 5947
Logged by: Raman Sharma
Email address: rsha...@10kinfo.com
PostgreSQL version: 7.4
Operating system: Ubnato
Description:Error while running query
Details:
ERROR: could not extend relation test_table: No
On Fri, Mar 25, 2011 at 9:47 AM, Raman Sharma rsha...@10kinfo.com wrote:
ERROR: could not extend relation test_table: No space left on device
HINT: Check free disk space.
But i have 27 GB space in my disk where it loaded and running query
Have you checked df -i ?
Also, this may seem like a
The following bug has been logged online:
Bug reference: 5950
Logged by: alex
Email address: perepelica.a...@gmail.com
PostgreSQL version: 9.0.3
Operating system: archlinux x86_64
Description:backend terminating after altering table
Details:
Such steps:
1. create
On tis, 2011-03-22 at 06:34 +, Vincent Chan wrote:
when saving a bytes array,
for example a bytes array which length is 2,
but after saving,
it's length will be change to 3.
but in postgres 8.4, the array length is still 2.
Please show an actual example of what you are observing.
--
Excerpts from Maxim Boguk's message of vie mar 25 05:56:41 -0300 2011:
From documentation I know that vacuum (without full) can truncate empty
pages from end of a relation if they are free and vacuum successfully grabed
exclusive lock for short time.
However, I wasn't ready to learn that
The following bug has been logged online:
Bug reference: 5945
Logged by: shenwenguang
Email address: swg0...@163.com
PostgreSQL version: 8.4
Operating system: ubuntu 11.04
Description:serial repetition Error!
Details:
PHP5 + PostgreSQL8.4 + ubuntu 11.04
1: insert
The following bug has been logged online:
Bug reference: 5948
Logged by: yuriy.tereschuk
Email address: as...@evernet.lutsk.ua
PostgreSQL version: postgresql90
Operating system: Linux Fedora 14
Description:JDBC wrond insert of timestamp data
Details:
The following bug has been logged online:
Bug reference: 5949
Logged by: Mihail Popov
Email address: mi1...@tut.by
PostgreSQL version: 9.3
Operating system: windows 7
Description:ODBC driver. Binding Arrays of Parameters
Details:
Using ODBC, I encountered an error.
On Fri, 25 Mar 2011, yuriy.tereschuk wrote:
The following bug has been logged online:
Bug reference: 5948
PostgreSQL version: postgresql90
Operating system: Linux Fedora 14
Description:JDBC wrond insert of timestamp data
Details:
org.postgresql.util.PSQLException: ERROR:
Maxim Boguk maxim.bo...@gmail.com writes:
In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and
each time (3) it was cost 10+ minutes of service downtime (because that
table was completely locked).
Is that correct behaviour? Are here any way to speedup that process or at
alex perepelica.a...@gmail.com writes:
1. create table t (
);
2. alter table t add childs t;
3. alter table t add id serial not null primary key;
server closed the connection unexpectedly
Hmm. This seems to be fixed in HEAD:
regression=# create table t (
regression(# );
CREATE TABLE
Fujii Masao wrote:
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai a...@sesda2.com wrote:
I have no idea why I keep getting the message:\
could not connect to the primary server: FATAL: no pg_hba.conf entry for
replication connection from host slave_server_ip, user
my_super_user_name
Can
On Fri, Mar 25, 2011 at 11:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Maxim Boguk maxim.bo...@gmail.com writes:
In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and
each time (3) it was cost 10+ minutes of service downtime (because that
table was completely locked).
Is
Christopher Browne cbbro...@gmail.com writes:
On Fri, Mar 25, 2011 at 11:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Use autovacuum --- if there's something that wants to access the table,
autovac will get kicked off the lock. (Of course, the table may never
get truncated then, but maybe you
Hi,
Recently I had trouble compiling from source on Fedora Core 14. The
configure script was not finding libreadline.so nor libz.so. Is there more
information I can provide? Over the weekend, I will make another attempt to
try and understand why configure does not see these libraries.
Thank
Jim Woodworth jimw54...@gmail.com writes:
Recently I had trouble compiling from source on Fedora Core 14. The
configure script was not finding libreadline.so nor libz.so. Is there more
information I can provide? Over the weekend, I will make another attempt to
try and understand why
On Fri, 2011-03-25 at 10:27 -0500, Jim Woodworth wrote:
Recently I had trouble compiling from source on Fedora Core 14.
FWIW, http://yum.pgrpms.org has the precompiled packages for Fedora 14.
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL
Excerpts from Tom Lane's message of vie mar 25 13:10:21 -0300 2011:
Christopher Browne cbbro...@gmail.com writes:
If there's almost always something that wants to access the table,
which would be hardly surprising, in view that the table is being
updated with sufficient regularity that
Alvaro Herrera alvhe...@commandprompt.com writes:
What happened to the idea of preallocating tables to a size defined by
the user at CREATE TABLE time, and extending it in chunks instead of a
block at a time, with the idea of reducing fragmentation? Was it
rejected, or just not implemented?
On Fri, Mar 25, 2011 at 7:43 PM, Tom Lane t...@sss.pgh.pa.us 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. The main issue here is where to cause
that to
Greg Stark gsst...@mit.edu writes:
On Fri, Mar 25, 2011 at 7:43 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
Greg Stark gsst...@mit.edu writes:
On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Sat, Mar 26, 2011 at 4:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Maxim Boguk maxim.bo...@gmail.com writes:
In my case vacuum tried to truncate last 10-15GB from 100Gb relation, and
each time (3) it was cost 10+ minutes of service downtime (because that
table was completely locked).
On Fri, Mar 25, 2011 at 5:09 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
Christopher Browne cbbro...@gmail.com 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
27 matches
Mail list logo
