On 03/12/2011 03:31 PM, Vishal wrote:
Hello Robert,
I checked my logs and found the following info -
[1] Information (8196), test_db_connection: exception: The Report Server is
unable to connect to the database. Database error: could not connect to
server: Connection refused (0x274D/10061)
On 3/28/2011 8:07 PM, Tom Lane wrote:
Jan Wieck writes:
I somehow fail to see how this complete reversal of who does what and
affecting code in entirely different parts of the system will qualify
for patching back releases.
I don't think any of the proposals make sense for back-patching.
Jan Wieck writes:
> I somehow fail to see how this complete reversal of who does what and
> affecting code in entirely different parts of the system will qualify
> for patching back releases.
I don't think any of the proposals make sense for back-patching. We
should be considering what's the s
On 3/28/2011 4:01 PM, Tom Lane wrote:
Christopher Browne writes:
- Grab timestamp
- Grab exclusive lock
- Process [Some number of pages]
- Check time.
- If [# of ms] have passed then check to see if anyone else has a lock
O/S on the table.
- Commit& give up the lock for a bit if they
The following bug has been logged online:
Bug reference: 5955
Logged by: Rob Grant
Email address: r...@occipital.com
PostgreSQL version: 9.0
Operating system: OS X
Description:One-click installer does not escape password
Details:
I provided the one-click installer a
On Mon, Mar 28, 2011 at 4:01 PM, Tom Lane wrote:
> Christopher Browne writes:
>> - Grab timestamp
>> - Grab exclusive lock
>> - Process [Some number of pages]
>> - Check time.
>> - If [# of ms] have passed then check to see if anyone else has a lock
>> O/S on the table.
>> - Commit & give up th
Christopher Browne writes:
> - Grab timestamp
> - Grab exclusive lock
> - Process [Some number of pages]
> - Check time.
> - If [# of ms] have passed then check to see if anyone else has a lock
> O/S on the table.
> - Commit & give up the lock for a bit if they do
> - Go back and process more
"alex" writes:
> Such steps:
> 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
Thanks for the report. Fixed as per today's discussion (ie, disallow
creating a self-referencing rowtype).
On Mon, Mar 28, 2011 at 2:20 PM, Robert Haas wrote:
> On Mon, Mar 28, 2011 at 12:29 AM, Tom Lane wrote:
>> 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
On Mon, Mar 28, 2011 at 12:29 AM, Tom Lane wrote:
> 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 frig
Sergey Burladyan writes:
> Tom Lane writes:
>> "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:
> Not fully. There are
Tom Lane writes:
> "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:
Not fully. There are also two cases with Segmentat
Fascinating.
No real idea.
I just hit "reply to list" on a message from tom (probably a reply to a
message from you?).
So from earlier experience with such operations, I would not have
expected to not show up as sender or from of the message.
So yes it was me posting and I have no idea on what act
I digged into my sent folder,
and the outgoing message already dat the false headers.
So probably my MUA (thunderbird) got confused on something and caused
that blunder.
Sorry for that
Rainer
Am 28.03.2011 16:05, schrieb Alvaro Herrera:
> Rainer, any idea? Please see
> http://archives.postgresql
Rainer, any idea? Please see
http://archives.postgresql.org/message-id/4d906269.6060...@commandprompt.com
Excerpts from Alvaro Herrera's message of lun mar 28 11:03:16 -0300 2011:
> Excerpts from Alvaro Herrera's message of lun mar 28 07:26:49 -0300 2011:
> > Likely "too large" is more an issue
Excerpts from Alvaro Herrera's message of lun mar 28 07:26:49 -0300 2011:
> Likely "too large" is more an issue related to available resources than
> of absolute figure.
>
> On a penta byte of free storage I would not mind allocating some teras
> with extending a (large) table.
> If I'm left with
Likely "too large" is more an issue related to available resources than
of absolute figure.
On a penta byte of free storage I would not mind allocating some teras
with extending a (large) table.
If I'm left with some MB only, I'd be concerned for sure.
I still prefer an approach that will "just w
17 matches
Mail list logo
