No really a pattern.
I'm sure PG is installed in standard pure version everywhere.
No domains at all.
The rest is really custom (we are working remotely - each of us with
different hardware, OS, software, etc...).
Maybe the intel dual core has smth to do about it ?
Those are affected:
My
All of the machines are laptops. Maybe some power management stuff ?
> On Mon, Jul 6, 2009 at 11:20 AM, wstrzalka wrote:
>> After upgrading to 8.4 on Vista I see no progress on the shared memory
>> problem unfortunately.
>>
>> I think it's even worse now (previously it happened mainly when OS
nv. looks quite crazy but I could try
with some help (this will take quite long time assuming my free time,
but if there is no other way ...).
> 2009/7/6 Wojciech Strzałka :
>>
>> No really a pattern.
>> I'm sure PG is installed in standard pure version everywhere.
>
ed by postgres.exe (snapshot only)
Maybe by comparing log entries you will be able to tell smth.
Still there is not much info in the pg log file (my config file in
package).
Removing plugin_debugger.dll didn't helped.
> 2009/7/6 Alvaro Herrera :
>> Wojciech Strzałka escrib
SegID in
PGSharedMemoryCreate and maybe also on successful PGSharedMemoryReAttach
in DEBUG log level?
> 2009/7/7 Wojciech Strzałka :
>>
>> Here ( http://www.codelabs.pl/_varia/pg.zip ) is detailed info from
>> my machine (PostgreSQL 8.3.6, compile
I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
is 'off' at least in 8.3 which is active at the time).
Don't hesitate too much - reinstalling binaries with dump & restore of
data is not a problem whatever version you'll send to me.
Witam!
W liście datowanym 7 lipca 2009 (18:02:30) napisano:
> 2009/7/7 Wojciech Strzałka :
>>
>> I think both 8.3 & 8.4 are from EnterpriseDB (the integer_datetime
>> is 'off' at least in 8.3 which is active at the time).
> OK, I
Witam!
W liście datowanym 8 lipca 2009 (13:55:00) napisano:
> 2009/7/8 Wojciech Strzałka :
>> I was wondering why I can not see the DEBUG2 info you were talking
>> about (tripple star), and probably that's another bug.
>> Whichever debug1 - debug5 level I set in c
STATEMENT: SHOW TRANSACTION ISOLATION LEVEL
--
Pozdrowienia,
Wojciech Strzałka
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I've found some strange behavoiur of TOAST'able tables.
1. Lets create table with toastable column
CREATE table toastable (
x int ,
y text
);
2. Check toast size - as the table is empty it's size 0 - OK
SELECT relname, pg_relation_size(oid) FROM pg_class where oid=(select
reltoastrelid from
> To make that happen would require (at least) a full table scan. I think
> most people are more interested in DROP COLUMN being a cheap operation
> than in having the space be reclaimed quickly.
> For a comparison point: large field values that don't happen to get
> toasted don't vanish immedia
11 matches
Mail list logo
