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 m
On Fri, Mar 25, 2011 at 5:09 PM, Greg Stark wrote:
> On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane 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 h
On Sat, Mar 26, 2011 at 4:17 AM, Tom Lane wrote:
> "Maxim Boguk" 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? A
Greg Stark writes:
> On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane 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
>> sel
On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane 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 enlargement be
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
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. The main issue here is where to cause
> that to happen. An indi
Alvaro Herrera 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?
I don't recall any part
Excerpts from Tom Lane's message of vie mar 25 13:10:21 -0300 2011:
> Christopher Browne 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 it's got 10GB+
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 Danı
Jim Woodworth 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 configure does not see
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 yo
Christopher Browne writes:
> On Fri, Mar 25, 2011 at 11:17 AM, Tom Lane 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 don't care.)
> I could see this
On Fri, Mar 25, 2011 at 11:17 AM, Tom Lane wrote:
> "Maxim Boguk" 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 h
Fujii Masao wrote:
On Wed, Mar 23, 2011 at 9:07 PM, Alex Lai 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 you connect
"alex" 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
regression=# alter table
"Maxim Boguk" 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
> least allow re
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: colu
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.
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:
org.postgresql.
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 a
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 tha
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.
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 ta
On Fri, Mar 25, 2011 at 9:47 AM, Raman Sharma 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 silly questi
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": N
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 t
27 matches
Mail list logo
