Hi,
On Wednesday 12 May 2010 03:44:16 Tom Lane wrote:
> "Mason Hale" writes:
> > ISSUE: unable to cancel queries using pg_cancel_backend(), that are in
> > send() function call, waiting on client receipt of data.
> I think what you are describing is a kernel bug. There's not a lot
> we can do ab
On 03/05/10 01:30, Tom Lane wrote:
> Russell Smith writes:
>
>> On 02/05/10 01:36, Tom Lane wrote:
>>
>>> No, that's the intended place for them given the current division of
>>> labor between pg_dump and pg_dumpall. There have been complaints before
>>> about this, but no one has propose
Hi,
pg_restore silently ignores the inclusion of -C when you do use a
restore list.
postgres$ pg_dump -Fc postgres > postgres.dump
postgres$ pg_restore -C postgres.dump | grep 'CREATE DATABASE'
CREATE DATABASE postgres WITH TEMPLATE = template0 ENCODING = 'UTF8';
## Create a restore list
postgre
It is an announcement that long-waited bug-fix of pg_lesslog is now
released. This includes the following.
1. Error in calculation of GiST-related WAL record length was fixed.
2. pg_compresslog now has an option to print WAL segment analysis.
3. New test script is added which analyzes what WAL r
On Tue, May 11, 2010 at 8:47 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>
>> You mean i'd get the pleasure of 'fixing' all my 3rd party C modules?
>
> Yeah, it's the implications for 3rd-party modules that make me not want
> to do this. A search & replace on our own code base is one thing, but
On ons, 2010-05-12 at 12:44 +0100, Greg Stark wrote:
> Well you could imagine doing this for all our types by doing:
>
> search and replace int4 -> pgint4 etc.
> add #ifndef int4 #define int4 pgint4 at the end of postgres.h
>
> That way third-party apps which define their own int4 would be
> requ
On Wed, May 12, 2010 at 1:01 PM, Peter Eisentraut wrote:
> The problem with the bool type is that it could have different sizes on
> different systems. Which will lead to problems. I doubt that that
> problem exists with int4.
>
I could imagine macros that do the wrong thing if the types they u
Hello guys
I dont know if it count but
I had installed in my pc the ODBC Drivers of Postgresql version 8.03.01 but I
saw an new version ( 8.03.02 ) but with this driver show my this error:
Windows Vista 06.00 Build 06000, SQLXpp: 3.1.24, Runtime: 1.90.355
SQLState: 07009, ErrorCode:13
Invalid
Andres Freund writes:
> I can reproduce the issue though when the connection just is very, very slow
> (high packet loss). Uppon receiving a signal the send returns with EINTR
> uppon
> which point I think a check for interrupts might be placed.
The gdb trace you showed before gave no indicati
bry...@giraffe-data.com (Bryan Henderson) writes:
> How about something less drastic? Could you at least eliminate "bool" from
> interface structures that are intended to be compiled in multiple
> environments?
No. That's not distinguishably different from eliminating it altogether.
Russell Smith writes:
> pg_restore silently ignores the inclusion of -C when you do use a
> restore list.
It would work as you expect if you use -C when creating the list file.
The reason for this is that -C basically means "don't skip the DATABASE
entry". When you use -l without -C, you get a l
Hi!
2 days ago I made a bug report through the bug reporting form on
postgresql.org regarding some unusual bloat in my TOAST tables, but it still
hasn't shown up on this ML, so I guess it's stuck in the moderation queue.
Could someone look at it (and hopefully approve it so it ends up here)? I
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> 2 days ago I made a bug report through the bug reporting form on
> postgresql.org regarding some unusual bloat in my TOAST tables, but it still
> hasn't shown up on this ML, so I guess it's stuck in the moderation queue.
> Could someone look
Hi!
I'm running 8.4.3 (the exact same problem was also present on 8.4.2) installed
from rpm packages at http://yum.pgsqlrpms.org/ on CentOS 5.4 (x86_64).
I have experienced a bit of a problem with my DB's storage and upon further
investigation, noticed that only some (2 for each day of data) of m
Rumko writes:
> INFO: vacuuming "pg_toast.pg_toast_1066371"
> INFO: "pg_toast_1066371": found 0 removable, 3259181 nonremovable row
> versions
> in 3259181 pages
> DETAIL: 0 dead row versions cannot be removed yet.
> Nonremovable row versions range from 57 to 122 bytes long.
> There were 0 unu
Tom Lane wrote:
>
> There's something extremely wacko about that vacuum output. A toast
> table should have few, if any, rows that short. And it's impossible
> to believe there's no free space at all in the table, especially since
> 122*3259181 bytes is still quite a lot less than 3259181 pages
16 matches
Mail list logo
