[BUGS] BUG #3632: couldn't start postgreSQL
The following bug has been logged online: Bug reference: 3632 Logged by: andrew Email address: [EMAIL PROTECTED] PostgreSQL version: postgresql-8.2. Operating system: winxp Description:couldn't start postgreSQL Details: Hello when i use postgresql-8.2.msi to install under winxp sp2 in the end of the step it always said: Service 'PostgreSQL Database Server 8.2'(pgsql-8.2) failed to start.Verify that you have sufficient privileges to start system services before installing I have set up an user account for the postgresql.And in the windows service list I found the postgreSQL service but when right click to let it start that is said I have no privileges to start this server.and finally the install process rolling back. Could you help me I will appricate you very much looking forward for you reply. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #1920: Installer no WIN1252 & UTF8 selection
The following bug has been logged online: Bug reference: 1920 Logged by: Andrew Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1-B2 (win32) Operating system: XP Professional Description:Installer no WIN1252 & UTF8 selection Details: I can't select those 2 options for database encoding when initializing cluster from the Win32 installer. This is in the list of new features for 8.1. Most likely just a minor oversight on the installer and not the database itself. Please correct me if I'm not raising this in the correct forum or place. Thanks to all developers, great job so far. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #7622: Incorrect aggregate level processing
The following bug has been logged on the website: Bug reference: 7622 Logged by: Andrew Gierth Email address: and...@tao11.riddles.org.uk PostgreSQL version: 9.2.1 Operating system: n/a Description: Tested on git-master, 9.2.1, various older versions. select (select array_agg(random()*i) from (values (1),(2)) v(a)) from generate_series(1,3) i; Expected output is three rows each with a 2-element array; actual output is: ERROR: more than one row returned by a subquery used as an expression Looking at the explain, the aggregate is being pulled out of the subplan and evaluated at the top query level. (This came up while doing some random data generation, I've simplified it a bit.) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7881: SQL function failures in long-lived calling contexts
The following bug has been logged on the website:
Bug reference: 7881
Logged by: Andrew Gierth
Email address: and...@tao11.riddles.org.uk
PostgreSQL version: 9.2.3
Operating system: any
Description:
The range type code accepts SQL functions for subtype_diff, but stores the
flinfo in a long-lived context (typcache).
The SQL function handler, fmgr_sql, isn't prepared to deal with the
possibility that the fcache entry may be left over from a previous query
that failed.
The combination of these two allows a non-superuser to provoke at least an
assertion failure as follows:
create or replace function inet_subdiff(inet,inet) returns float8 language
sql immutable as $f$ select ($2 - $1)::float8; $f$;
create type inetrange as range (subtype = inet, subtype_diff =
inet_subdiff);
create table inetr as select
format('[%s::,%s::]',to_hex(i),to_hex(i+1))::inetrange as r from
generate_series(0,65534) i;
postgres=# create index inetr_idx on inetr using gist (r);
ERROR: result is out of range
CONTEXT: SQL function "inet_subdiff" statement 1
postgres=# create index inetr_idx on inetr using gist (r);
TRAP: FailedAssertion("!(snapshot->regd_count > 0)", File: "snapmgr.c",
Line: 557)
I'm inclined to think this is fmgr_sql's fault for apparently assuming that
if an error is thrown that it'll never see the fcache entry again, but in
this example that's clearly not true.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8274: Wildly insane boolean selectivity estimates
The following bug has been logged on the website: Bug reference: 8274 Logged by: Andrew Gierth Email address: and...@tao11.riddles.org.uk PostgreSQL version: 9.1.9 Operating system: any Description: The guy on IRC who ran into this one was using 9.1.9, but it seems to still exist in master. The handling of freq_null for estimating IS NOT TRUE/FALSE for boolean columns which are all null or almost all null (enough that analyze doesn't find any non-null values to put in MCV) is completely off in the weeds. Suggested fix at: https://gist.github.com/RhodiumToad/5901567 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #8453: uninitialized memory access in pg_receivexlog and other bugs
The following bug has been logged on the website: Bug reference: 8453 Logged by: Andrew Gierth Email address: and...@tao11.riddles.org.uk PostgreSQL version: 9.3.0 Operating system: any Description: The first snprintf in writeTimeLineHistoryFile in receivelog.c accesses uninitialized data in the "path" variable, thus creating the .tmp file in a random place (usually the current dir, leading to unexpected EXDEV errors on the rename). Also, receivexlog is ignoring .partial and .history files when determining which timeline to start streaming from, which means that if there are two timeline changes that are not separated by a WAL segment switch, it will fail to operate due to attempting to start from a too-old timeline (for which xlogs are not available on the server). Found from my analysis of a report from irc. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4328: help in creating database encoded with LATIN1
The following bug has been logged online: Bug reference: 4328 Logged by: andrew victoria Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: fedora core 9 Description:help in creating database encoded with LATIN1 Details: i got an error message createdb: database creation failed: ERROR: encoding LATIN1 does not match server's locale en_US.utf8 DETAIL: The server's LC_CTYPE setting requires encoding UTF8. when im trying to create a database encoded with LATIN1 which is needed in our work. what will i do? many thanks en more power.. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Segfault manifesting in libm from cost_sort
Our pg keeps going into recovery mode after segfaulting. This is a compiled 8.3.3 on Ubuntu 6.04 with Slony. Some ideas from IRC: RhodiumToad: 1) probably least likely, something corrupt in the math libs; the fact that it's not reproducible makes this improbable RhodiumToad: 2) more likely: a register or memory stomp in a signal handler, which could be the result of an OS bug or a pg miscompile RhodiumToad: 3) slightly less likely: a memory stomp somewhere else in pg that happens to be clobbering something in the math library Here is some gdb output from a core dump: (gdb) bt #0 0x2ae09a32 in fegetexcept () from /lib/libm.so.6 #1 0x2ae1e7e4 in log () from /lib/libm.so.6 #2 0x0055250d in cost_sort () #3 0x00554757 in cost_mergejoin () #4 0x00570673 in create_mergejoin_path () #5 0x0055a337 in add_paths_to_joinrel () #6 0x0055b650 in make_join_rel () #7 0x0055bb61 in join_search_one_level () #8 0x0055145d in standard_join_search () #9 0x00563329 in query_planner () #10 0x00563e98 in grouping_planner () #11 0x00564d08 in subquery_planner () #12 0x0056511a in standard_planner () #13 0x005a7271 in pg_plan_query () #14 0x005a7877 in pg_plan_queries () #15 0x005a7b2e in exec_simple_query () #16 0x005a9495 in PostgresMain () #17 0x0057ec88 in ServerLoop () #18 0x0057f7cb in PostmasterMain () #19 0x005370ee in main () (gdb) frame #0 0x2ae09a32 in fegetexcept () from /lib/libm.so.6 (gdb) info reg rax0xa2dd8010673536 rbx0x3ffc4610560118520545280 rcx0x2b0688 rdx0x3fec4606056518893174784 rsi0x2ae5596846912499964264 rdi0x690026880 rbp0x2ae559600x2ae55960 rsp0x7f8775100x7f877510 r8 0x2ae54e0846912499961352 r9 0x2ae54e0046912499961344 r100x2ae542a046912499958432 r110x690026880 r120x684c26700 r130xffe04294967264 r140x2ae53ce046912499956960 r150xa0a44810527816 rip0x2ae09a320x2ae09a32 eflags 0x1020666054 cs 0x3351 ss 0x2b43 ds 0x00 es 0x00 fs 0x00 gs 0x00 (gdb) disass 0x2ae09a00 0x2ae09b00 Dump of assembler code from 0x2ae09a00 to 0x2ae09b00: 0x2ae09a00 :and$0x8,%al 0x2ae09a02 :mov0x8(%rsp),%r11 0x2ae09a07 :movlpd 317329(%rip),%xmm6 # 0x2ae571a0 <__signbitl+131008> 0x2ae09a0f :sar$0x20,%r11 0x2ae09a13 :mulsd %xmm11,%xmm6 0x2ae09a18 :and$0xf,%r11d 0x2ae09a1f :addsd %xmm14,%xmm5 0x2ae09a24 :sar$0x4,%r11d 0x2ae09a28 :lea 0xff4c(%r11),%r12d 0x2ae09a2f :movslq %r11d,%rdi 0x2ae09a32 :mulsd (%r10,%rdi,8),%xmm8 # <-- where it segfaults 0x2ae09a38 :shl$0x4,%rdi 0x2ae09a3c :cvtsi2sd %r12d,%xmm9 0x2ae09a41 :movlpd (%rdi,%rbp,1),%xmm3 0x2ae09a46 :movlpd (%rdi,%rsi,1),%xmm13 0x2ae09a4c :ucomisd %xmm3,%xmm12 0x2ae09a51 :mulsd 317246(%rip),%xmm9 # 0x2ae57198 <__signbitl+131000> 0x2ae09a5a :addsd %xmm14,%xmm9 The value of r10 is the same every time, but rdi changes. Andrew
Re: [BUGS] Segfault manifesting in libm from cost_sort
ECC memory, RAID 10 w/ adaptec 3405 hardware controller. Period between crashes ranged from about 1min-5mins. Just switched to a new box so the problem is "gone". In the original email I meant ubuntu 6.06. On Wed, Jul 30, 2008 at 12:06 AM, John R Pierce <[EMAIL PROTECTED]> wrote: > Andrew Badr wrote: > >> Our pg keeps going into recovery mode after segfaulting. This is a >> compiled 8.3.3 on Ubuntu 6.04 with Slony. >> >> Some ideas from IRC: >> RhodiumToad: 1) probably least likely, something corrupt in the math libs; >> the fact that it's not reproducible makes this improbable >> RhodiumToad: 2) more likely: a register or memory stomp in a signal >> handler, which could be the result of an OS bug or a pg miscompile >> RhodiumToad: 3) slightly less likely: a memory stomp somewhere else in pg >> that happens to be clobbering something in the math library >> > > does this server have ECC memory? if not > > Pierce: 4) flakey memory > > > does this server have an 'enterprise' grade disk system (eg, SAS, SCSI, > Fiberchannel, with a decent qualilty RAID controller)?if its a desktop > ATA/SATA disk... > > Pierce: 5) flakey disk drive or channel > > >
Re: [BUGS] BUG #4340: SECURITY: Is SSL Doing Anything?
On Tue, Aug 19, 2008 at 02:57:55PM -0400, Tom Lane wrote: > To impose such a requirement, we'd have to forbid naming the server > by IP address or via a domain-search-path abbreviation. If you ask me, the second idea at least is a good one anyway. In an SSL context, search paths are a terrible idea. (Frankly, they're a terrible idea outside that context also, but that ship sailed some time ago.) A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Magnus Hagander wrote: I had a chat with Heikki about this, and the proper way to fix it. Should there actually be any reason not to *always* open our files with O_BINARY? That seems to be what should mimic what Unix does, which would be what we expect, no? If that is so, then I propose we do that for 8.4, and just backpatch the O_BINARY flag to these two locations for 8.3 and 8.2. Thoughts? ISTR there are a few places where we want CRLF translation (config files?) I'd be fairly conservative about making changes like this. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: Tom Lane wrote: Well, why is that a bug? If the platform is so silly as to define text files that way, who are we to argue? The problem is that our pg_controldata might have binary values that contain 0x1a that will be confused by the operating system as end-of-file. pg_controldata is certainly already being read as binary. Umm, no, it is in the backend I believe but not in the utilities. Hence the original bug report. We need to add the binary flag in pg_controldata.c and pg_resetxlog.c. The discussion here is about *text* files, particularly configuration files. Why should we not adhere to the platform standard about what a text file is? If you need a positive reason why this might be a bad idea, consider the idea that someone is examining postgresql.conf with a text editor that stops reading at control-Z. He might not be able to see items that the postmaster is treating as valid. Yes, exactly right. We certainly can't just open everything in binary mode. Magnus did say that all the current config files are opened in text mode as far as he could see. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] [HACKERS] 0x1A in control file on Windows
Tom Lane wrote: The point being that the config files are opened with AllocateFile(), which in turn calls fopen(). It doesn't use open(). The proposal was only to make all *open()* calls do it binary. I was under the impression that on Unix, that's what open() did, so we should behave the same? That seems just weird. I do not think there's any correlation between whether we use open or fopen and whether the file is text or binary. Even if it happens to be true right now, depending on it would be fragile. I agree. If you really want something like that you should invent OpenConfigFile() or some such. But it hardly seems worth it. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4465: GROUP BY is not to SQL standard
On Wed, Oct 15, 2008 at 01:47:40PM +0100, Tony Marston wrote: > Support for functional dependencies is not a feature that can be > turned off in any database engine. Repeating the same premise over and over again does not constitute an argument. In this case, you appear to be begging the question. I think you have your answer, even if you don't like it. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4486: CSV feature request
The following bug has been logged online: Bug reference: 4486 Logged by: Andrew Grillet Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3 Operating system: Windows XP Description:CSV feature request Details: Excel 2007 decides on the fly whether to quote fields or not on the basis of whther individual rows have a comma in that field. There does not appear any obvious way to prevent this bizarre behaviour. I suggest the syntax: COPY table (columns) FROM 'filename.csv. with csv OPTIONAL QUOTE [AS '"']; As a way to tell PostgreSQL this behaviour is expected and must be handled without complaint. Default should be to complain if file is stupidly formatted. Additionally, where a character that is not a member of the acceptable character set is found, plese attempt to print it as char as well as octal/hex. It can be very difficult to find which character is causeing the problem! (Eg em-dashes, smart quotes) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
Alex Hunsaker wrote:
On Tue, Nov 4, 2008 at 12:43, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
It has something to do with anon subs not sure what...
It has to do with us returning the anonymous sub inside of the safe
and then calling the function outside of the safe (or at least in a
different namespace)
we do something eqvilient to this:
my $func_ptr = $safe->reval('sub { ... }');
$func_ptr->();
because safe makes its own namespace from perldoc Safe
The "root" of the namespace (i.e. "main::") is changed to a
different package and code evaluated in the compartment cannot
refer to variables outside this namespace, even with run-time
glob lookups and other tricks.
I only see one way to "fix" this which is to do something groddy like
share a global variable between the safe and the real interpreter.
Something like:
my $_pl_sub;
sub call_pl_sub
{
retrun $_pl_sub;
}
$safe->share(qw(call_pl_sub);
my $sub = $safe->reval('sub { ...}');
$_pl_sub = $sub;
$safe->reval('call_pl_sub();');
Note I tried just sharing $_pl_sub and doing
$safe->reval('$_pl_sub->()'); but I just get 'Undefined subroutine
&main::'
Should I work up a patch? Assuming someone confirm this?
OK, the first thing to note is that there is an easy workaround, which
is to use a sort routine that doesn't need $a/$b. Example:
create or replace function mysort() returns text language plperl as $f$
my $sfunc = sub ($$) { $_[0] <=> $_[1] };
my @vals = (5,3,4,2,7);
return join(' ',sort $sfunc @vals);
$f$;
We need to document that, and given that this exists I think we don't
need to backpatch old versions.
Beyond that, we need to be very careful with any "solution" that we
don't upset the moderately fragile security of trusted plperl, and I'm
going to look fairly skeptically at anything that changes the way we set
up and call functions. But by all means if you can come up with a robust
way of allowing the more traditional way of calling sort routines, send
it in. Sharing globals between the Safe and non-Safe worlds is not a
solution - we removed an instance of that not long ago for security reasons.
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
Alex Hunsaker wrote:
On Tue, Nov 4, 2008 at 15:02, Alex Hunsaker <[EMAIL PROTECTED]> wrote:
On Tue, Nov 4, 2008 at 14:43, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
But by all means if you can come up with a robust way of allowing
the more traditional way of calling sort routines, send it in.
Well its not just sort its anything that uses main:: right?
Err no you're right its only builtins that use main:: sort being the
only one I know of off the top of my head... its a shame
PLContainer->share('$main::a'); does not seem to work..
$a and $b are magical *package* variables. See "perldoc perlvar". This
has nothing whatever to do with main::
cheers
andrew
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
>>>>> "nathan" == nathan wagner <[EMAIL PROTECTED]> writes: nathan> Completely untested speculation based on my knowledge of perl nathan> and a bit of reading: nathan> The reason you can't see $a and $b is that sort internally nathan> sets these variables in the main package. That is, sort is nathan> setting $main::a and $main::b, and when you run the plperl nathan> code in the safe compartment, main:: isn't visible any more. Nice theory, but completely wrong: sort creates $a and $b in the current package, not in main::. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: >> Hmm ... so then why are we seeing a failure? [...] Alex> This is not a Safe bug IMHO its our (ab)use of it that is Alex> causing the problem. Then explain why the problem goes away when you build perl with threading turned off. -- Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
>>>>> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes: >> Nice theory, but completely wrong: sort creates $a and $b in the >> current package, not in main::. Tom> Hmm ... so then why are we seeing a failure? FWIW, I _don't_ see the failure. It seems to occur ONLY if perl was built with threading support (ithreads). Without ithreads, I can't reproduce it (I've tried enabling and disabling multiplicity with no effect, so it's not that). Ithreads seem to be the default on many linux package builds of perl. It is _not_ the default on FreeBSD. -- Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes:
>> Then explain why the problem goes away when you build perl with
>> threading turned off.
Alex> Hrm yep i built one without threads problem disappears... Guess
Alex> Ive just been out to lunch :)
If it helps any, I've tracked down in the perl guts exactly why this
happens:
cop.h:
struct cop {
BASEOP
char * cop_label; /* label for this construct */
#ifdef USE_ITHREADS
char * cop_stashpv;/* package line was compiled in */
char * cop_file; /* file name the following line # is from */
#else
HV *cop_stash; /* package line was compiled in */
GV *cop_filegv; /* file the following line # is from */
#endif
U32 cop_seq;/* parse sequence number */
I32 cop_arybase;/* array base this line was compiled with */
line_t cop_line; /* line # of this command */
SV *cop_warnings; /* lexical warnings bitmask */
SV *cop_io; /* lexical IO defaults */
};
A COP in perl is a control operation, basically a compiled statement,
and the pointer to the current COP is used to determine all the
lexical state, including the current package. pp_sort uses
CopSTASH(PL_curcop) to get the package stash (symbol table) in order
to locate the $a and $b variables in it.
Notice, though, that without ithreads, the COP points directly to the
stash, but with ithreads, it points instead to the _name_ of the stash
(e.g. "main"). The problem arises because with Safe in use, the
package created by Safe to use as a container _thinks_ that its name
is "main" even though it's not, so the COPs compiled inside it point
to the name "main" rather than to the real name of the container.
So with ithreads enabled, pp_sort looks up the package stash by name,
gets the "main" package rather than the safe container, and creates
$main::a and $main::b to store the comparison values in. But the
compiled comparison block has its own references to the variables
which refers to the correct stash, so it all goes Horribly Wrong at
that point.
So there are three factors involved:
1) the change in layout of COP with ithreads enabled
2) the fact that Safe changes the internally-seen name of a package
3) any operation that relies on CopSTASH(PL_curcop) (I can only find a
few: sort, reset, and bless) will then behave incorrectly
However, I have no idea why Perl has this difference between threaded
and non-threaded code.
--
Andrew.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] plperl & sort
>>>>> "Alex" == Alex Hunsaker <[EMAIL PROTECTED]> writes: Alex> I submitted http://rt.perl.org/rt3/Public/Bug/Display.html?id=60374 Feel free to add my explanation to that (I couldn't see an obvious way to do it myself) -- Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4516: FOUND variable does not work after RETURN QUERY
>>>>> "Pavel" == "Pavel Stehule" <[EMAIL PROTECTED]> writes: >> Well, changing the semantics of an already-released statement >> carries a risk of breaking existing apps that aren't expecting it >> to change FOUND. So I'd want to see a pretty strong case why this >> is important --- not just that it didn't meet someone's >> didn't-read-the-manual expectation. Pavel> It's should do some problems, but I belive much less than Pavel> change of casting or tsearch2 integration. And actually it's Pavel> not ortogonal. Every not dynamic statement change FOUND Pavel> variable. Regardless of what you think of FOUND, a more serious problem is this: postgres=# create function test(n integer) returns setof integer language plpgsql as $f$ declare rc bigint; begin return query (select i from generate_series(1,n) i); get diagnostics rc = row_count; raise notice 'rc = %',rc; end; $f$; CREATE FUNCTION postgres=# select test(3); NOTICE: rc = 0 test -- 1 2 3 (3 rows) Since GET DIAGNOSTICS is documented as working for every SQL query executed in the function, rather than for a specific list of constructs, this is clearly a bug. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4547: sort columns in \d
On Sun, Nov 23, 2008 at 05:36:13PM +0100, toruvinn wrote: > Actually, I prefer it the old way. I just like to know the column order > `SELECT *' would return (though I never use `SELECT *' myself). Not to You can't know that, as a matter of SQL semantics. A -- Andrew Sullivan [EMAIL PROTECTED] -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4547: sort columns in \d
On Mon, Nov 24, 2008 at 01:39:48AM -0500, Andrew Sullivan wrote: > > You can't know that, as a matter of SQL semantics. I shouldn't reply to listmail when bone tired. I was thinking of rows. Sorry. A -- Andrew Sullivan [EMAIL PROTECTED] -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4553: HOLD cursors not materializing results fully
The following bug has been logged online:
Bug reference: 4553
Logged by: Andrew Gierth
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3-8.4
Operating system: all
Description:HOLD cursors not materializing results fully
Details:
(tested on 8.3.5 and HEAD as of a few weeks ago)
The materialization logic for holdable cursors isn't detoasting data prior
to storage in the portal's tuplestore, which leads to problems like this:
postgres=# create table test1 (a text);
CREATE TABLE
postgres=# insert into test1 values
(repeat('daafadslksdfalkeshfalkhfalsdjfhalsjdfhaldjfhalkfhd',1));
INSERT 0 1
postgres=# declare testcur cursor with hold for select * from test1;
DECLARE CURSOR
postgres=# delete from test1;
DELETE 1
postgres=# vacuum
test1;
VACUUM
postgres=#
fetch first from testcur;
ERROR: missing chunk number 0 for toast value 65571 in pg_toast_65565
Obviously truncate, etc., is affected too.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] backend crash on CREATE OR REPLACE of a C-function on Linux
Stefan Kaltenbrunner wrote: Hi all! While hacking on some C-level functions I noticed that everytime I replaced the .so file and used CREATE OR REPLACE FUNCTION the backend immediatly crashed. To test that it was not caused by something my function does (or one of the libaries it links in) I created the following testcase based on the example in the docs: I think I've seen this before and reported it. Try removing your so file and then copying it, rather than overwriting it. I think dlopen has something funnky going on with inodes; may need to generate a new one. If it is what I think it is, the problem is with libc not postgres. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4667: pg_standby error on Solaris 10 SPARC 64 bin
The following bug has been logged online: Bug reference: 4667 Logged by: Andrew Shved Email address: ash...@symcor.com PostgreSQL version: 8.3.5 Operating system: Sun Sloaris 10 SPARC 64 bit ( SunOS 5.10) Description:pg_standby error on Solaris 10 SPARC 64 bin Details: I rely heavily on pg_standby for my BCP site and seems to have a bug on my platform. I installed PostgreSQL 8.3.5 from binaries using from http://www.postgresql.org/ftp/binary/v8.3.5/solaris/solaris10/sparc/ and I get the following error in my standby log when trying to restore - ld.so.1: pg_standby: fatal: libpq.so.5: open failed: No such file or directory Looks like C error. My restrore_command is restore_command = '/postgres/postgres/8.3-community/bin/64/pg_standby -d -s 5 -t /pgdata/HA1/pgsql.trigger.5442 /pg_xlog/HA1/restorelog %f %p %r 2>>/pgdata/HA1/standby.log' just to make sure i am not going insane I did restore using this - restore_command='cp /pg_xlog/HA1/restorelog/%f %p >> /pgdata/HA1/standby.log' and it worked perfectly so my set up is ok. Can I get your help on fixing this as it worked so well for linux on version 8.2.4 but seems to fail on solaris 10 sparc. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4717: Installing PostGIS via StackBuilder gives an 'Error opening file' error
The following bug has been logged online: Bug reference: 4717 Logged by: Andrew Smith Email address: laconi...@gmail.com PostgreSQL version: 8.3.7 Operating system: Windows XP Description:Installing PostGIS via StackBuilder gives an 'Error opening file' error Details: 1. Install PostgreSQL. Use default settings for everything (I used 'English - Australia for Locale but I don't think it matters). 2. At the end of the installation ensure that 'Launch Stack Builder' is ticked, and click finish 3. Inside Stack Builder, select your PostgreSQL installation and click next. 4. Expand 'Spatial Extensions' and tick 'PostGIS 1.3.5' and click next 5. Choose any mirror and click next 6. Click next and the installation files should start downloading. Once they have download, click next. 7. Install PostGIS and use the default values for everything 8. Almost immediately, an error occurs: Error opening file for writing: C:\Program Files\PostgreSQL\8.3\bin\libiconv-2.dll Using the unlocker program (http://ccollomb.free.fr/unlocker/) I can see that pg_ctl.exe and postgres.exe both have locks on the file, which is why it can't be overwritten. Stopping the PostgreSQL service removes the locks on the file; however the PostGIS installation then fails because it cannot create a PostGIS database. At the moment, the workaround is to rename the DLL (after PostgreSQL service is started) before installing PostGIS. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] Re: [BUGS] BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
Simon Riggs wrote: On Fri, 2009-05-15 at 22:56 +0900, Fujii Masao wrote: OK, I probably understood your point. The timeline history files whose timeline ID is larger than that of an oldest backup must not be deleted from the archive. On the other hand, the smaller or equal one can be deleted. Not all history files are necessary. So, if we don't keep older backup, we probably can delete all files in the archive before pg_start_backup(). Is my understanding right? Heikki is right in one sense: if you do pg_start_backup() then for *that* backup you do not need earlier files. However, as you have pointed out, if you have *multiple* backups then deleting history files may cause problems with an earlier backup. It's standard practice to have >1 backup, so there is potential for error and minimum is we must document that. Rather than explaining the problem and the rules by which we can work out exactly which history files to keep, I think it is safer to say that we must keep all history files. This whole area is unfortunately way too fragile. We need some way of managing these facilities that hides a lot of these details and is therefore less likely to produce shot feet, IMNSHO. I get very nervous every time I have to touch it. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] Re: [BUGS] BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
Simon Riggs wrote: On Fri, 2009-05-15 at 10:17 -0400, Andrew Dunstan wrote: This whole area is unfortunately way too fragile. We need some way of managing these facilities that hides a lot of these details and is therefore less likely to produce shot feet, IMNSHO. I get very nervous every time I have to touch it. I think it is complex, though that is because we now support a huge number of use cases and options, to the benefit of many users. In fact, more than I would like, but this is a group project. Not sure why you say it's fragile; there have been very few bugs considering the wide user base and those that have occurred have had fixes submitted for them quickly. Yes, we require you to actually read the docs, rather than open up psql and play, but this is business critical stuff. Realistically, we have more developers on this part of the code now than any other. That's one reason for all the debate. No problem in receiving feedback, just want to be able to understand it sufficiently well to be able to enhance it. I don't mean that it has bugs. I mean that it's far too easy to get it wrong and far too hard to get it right. I have reduced my uses to a couple of cases where I have worked out, with some trial and error, recipes that I follow. If I find these facilities complex to use, and I make virtually 100% of my living working with Postgres, what are more ordinary users going to say? That's why I think we need at the very least some tools for supporting the most common use cases, and hiding the messy details. And no, I haven't even begun to think of what such tools might look like. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4821: LIKE '%_' fails
The following bug has been logged online: Bug reference: 4821 Logged by: Andrew Gierth Email address: and...@tao11.riddles.org.uk PostgreSQL version: 8.3-8.4 Operating system: all Description:LIKE '%_' fails Details: # select 'foo' like '%_'; ?column? -- f (1 row) correct result would be 't' 8.1 and 8.2 seem to get this one right. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
TAKATSUKA Haruka wrote: Hi. We found the unbalance of xxAlloc and xxFree at AddUserToDacl() in src/port/exec.c (of current HEAD code). psidUser is a pointer of the element of a TOKEN_USER structure allocated by HeapAlloc(). The FreeSid() frees a SID allocated by AllocateAndInitializeSid(). I think that it is correct to use HeapFree(GetProcessHeap(), 0, pTokenUser). At present, a specific error, crash or trouble seems not to have happened. src/port/exec.c:748 AddUserToDacl() src/port/exec.c:841 GetUserSid() pTokenUser = (PTOKEN_USER) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, dwLength); src/port/exec.c:807 AddUserToDacl() FreeSid(psidUser); I quickly poked around and found what I believe to be two memory issues. 1. GetUserSid() uses HeapAlloc() to allocate a TOKEN_USER, but never calls HeapFree() if the function succeeds. Instead, it pulls out the token's SID and returns it. This is a memory leak. 2. The SID returned by GetUserSid() is incorrectly being passed to FreeSid() within AddUserToDacl()'s cleanup section. This memory belongs to the TOKEN_USER allocated by HeapAlloc() in GetUserSid(), it cannot be passed to FreeSid. Quick question, Why HeapAlloc and LocalAlloc. Why not use malloc? One solution would be to return a copy of the SID from GetUserSid and HeapFree the TOKEN_USER. Replace GetUserSid() line 869 *ppSidUser = pTokenUser->User.Sid; return TRUE; With the below (error checking excluded) DWORD len = GetLengthSid(pTokenUser->User.Sid) *ppSidUser = (PSID) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len); CopySid(len, *ppSidUser, pTokenUser->User.Sid); // SID is copied, free TOKEN_USER HeapFree(GetProcessHeap(), 0, pTokenUser); return TRUE; Also, AddUserToDacl() line 807 FreeSid(psidUser) should be HeapFree(GetProcessHeap(), 0, psidUser) in order to work with my suggested changes in GetUserSid(). -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
At present, a specific error, crash or trouble seems not to have happened. The reason its not crashing is that most, if not all, windows allocation functions know which addresses belong to them. FreeSid is actually documented as returning NULL on success. On failure it returns the address you tried to free. Although the FreeSid call causes no harm because its defensive, there is still the issue of leaking the TOKEN_USER structure. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
DWORD len = GetLengthSid(pTokenUser->User.Sid)
*ppSidUser = (PSID) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, len);
CopySid(len, *ppSidUser, pTokenUser->User.Sid);
I attached a patch for this. Although, I did not use CopySid. Instead,
I changed GetUserSid to GetTokenUser. AddUserToDacl() is the only
function making use of GetUserSid(), so this change won't break
anything. The benefit to this approach over my first suggestion is that
it avoids an unneeded HeapAlloc(sid), CopySid(sid) ... and its cleaner.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
Index: src/port/exec.c
===
RCS file: /projects/cvsroot/pgsql/src/port/exec.c,v
retrieving revision 1.63
diff -C6 -r1.63 exec.c
*** src/port/exec.c 11 Jun 2009 14:49:15 - 1.63
--- src/port/exec.c 23 Jun 2009 14:57:46 -
***
*** 53,65
static int validate_exec(const char *path);
static int resolve_symlinks(char *path);
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetUserSid(PSID *ppSidUser, HANDLE hToken);
#endif
/*
* validate_exec -- validate "path" as an executable file
*
* returns 0 if the file is found and no error is encountered.
--- 53,65
static int validate_exec(const char *path);
static int resolve_symlinks(char *path);
static char *pipe_read_line(char *cmd, char *line, int maxsize);
#ifdef WIN32
! static BOOL GetTokenUser(HANDLE hToken, PTOKEN_USER *ppTokenUser);
#endif
/*
* validate_exec -- validate "path" as an executable file
*
* returns 0 if the file is found and no error is encountered.
***
*** 694,706
ACCESS_ALLOWED_ACE *pace;
DWORD dwNewAclSize;
DWORD dwSize = 0;
DWORD dwTokenInfoLength = 0;
HANDLE hToken = NULL;
PACL pacl = NULL;
! PSID psidUser = NULL;
TOKEN_DEFAULT_DACL tddNew;
TOKEN_DEFAULT_DACL *ptdd = NULL;
TOKEN_INFORMATION_CLASS tic = TokenDefaultDacl;
BOOL ret = FALSE;
/* Get the token for the process */
--- 694,706
ACCESS_ALLOWED_ACE *pace;
DWORD dwNewAclSize;
DWORD dwSize = 0;
DWORD dwTokenInfoLength = 0;
HANDLE hToken = NULL;
PACL pacl = NULL;
! PTOKEN_USER pTokenUser = NULL;
TOKEN_DEFAULT_DACL tddNew;
TOKEN_DEFAULT_DACL *ptdd = NULL;
TOKEN_INFORMATION_CLASS tic = TokenDefaultDacl;
BOOL ret = FALSE;
/* Get the token for the process */
***
*** 741,761
AclSizeInformation))
{
log_error("could not get ACL information: %lu", GetLastError());
goto cleanup;
}
! /* Get the SID for the current user. We need to add this to the ACL. */
! if (!GetUserSid(&psidUser, hToken))
{
! log_error("could not get user SID: %lu", GetLastError());
goto cleanup;
}
/* Figure out the size of the new ACL */
! dwNewAclSize = asi.AclBytesInUse + sizeof(ACCESS_ALLOWED_ACE) + GetLengthSid(psidUser) -sizeof(DWORD);
/* Allocate the ACL buffer & initialize it */
pacl = (PACL) LocalAlloc(LPTR, dwNewAclSize);
if (pacl == NULL)
{
log_error("could not allocate %lu bytes of memory", dwNewAclSize);
--- 741,764
AclSizeInformation))
{
log_error("could not get ACL information: %lu", GetLastError());
goto cleanup;
}
! /* Get the user token for the current user. This provides us with the
! * user's SID which is needed for creating the ACL.
! */
! if (!GetTokenUser(hToken, &pTokenUser))
{
! log_error("could not get user token: %lu", GetLastError());
goto cleanup;
}
/* Figure out the size of the new ACL */
! dwNewAclSize = asi.AclBytesInUse + sizeof(ACCESS_ALLOWED_ACE) +
! GetLengthSid(pTokenUser->User.Sid) - sizeof(DWORD);
/* Allocate the ACL buffer & initialize it */
pacl = (PACL) LocalAlloc(LPTR, dwNewAclSize);
if (pacl == NULL)
{
log_error("could not allocate %lu bytes of memory", dwNewAclSize);
***
*** 782,794
log_error("could not add ACE: %lu", GetLastError());
goto cleanup;
}
}
/* Add the new ACE for the current user */
! if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, psidUser))
{
log_error("could not add access allowed ACE: %lu", GetLastError());
goto cleanup;
}
/* Set the new DACL in the token */
--- 785,797
log_error("could not add ACE: %lu", GetLastError());
goto cleanup;
}
}
/* Add the new ACE for the current user */
! if (!AddAccessAllowedAce(pacl, ACL_REVISION, GENERIC_ALL, pTokenUser->User.Sid))
{
log_error("could not add access allowed ACE: %lu", GetLastError());
goto cleanup;
}
/* Set the new DACL in the token */
***
*** 800,813
goto cleanup;
}
ret = TRUE;
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
How about something like this? I switched to using LocalAlloc() in all places to be consistent, instead of mixing heap and local. (Though per doc, LocalAlloc is actually a wrapper for HeapAlloc in win32). Our patches crossed. Although, in my patch I left the allocation scheme alone since I wasn't sure if someone wanted that way. I'd suggest malloc and free if your going to change it. The only time I use an MS allocater is when a win32 api function specifically states it must be used. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems
Jim Michaels wrote: The following bug has been logged online: Bug reference: 4876 Logged by: Jim Michaels Email address: jmich...@yahoo.com PostgreSQL version: 8.3.7-1 Operating system: windows XP Pro SP3 Description:author of MD5 says it's seriously broken - hash collision resistance problems Details: If you are looking for hash collision protection, start looking at SHA-256 or SHA-512. I personally avoid using sha256 and sha512 because they have proven to be cpu hogs, profilers show them sucking the life out of my applications ... adding large amounts of latency. If you use these, make sure their use is rather small; ie. not for lots of files or blobs. If you realy need good collision detection, I would recommend combining two algorithms into a single hash, like crc32+md5 or md5+sha1. The chances of a collision on both algorithms on the same message becomes far more unlikely. Also, they end up being more efficient than sha256 by itself. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
Attached is a mix of our two patches. How does that look to you? looks good. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] GetTokenInformation() and FreeSid() at port/exec.c
The only issue now is a small leak of memory in a function that is only called a fixed (and very small) number of times per process. Given this, I'm inclined to say we should put it on hold for 8.5. Thoughts? Doesn't sound urgent to me. If it were my decision, I'd punt it to 8.5. Hard to keep that win32 acl stuff leak free. There is always a cleanup goto because you need 6 billion objects to answer any question :o -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4913: Row missing from primary key index
| 2009-05-09 13:40:23.072695 (above 3 rows are) (full list at http://pastebin.com/m16600dc8 - that list is from a seqscan, so includes rows missing from the index) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4913: Row missing from primary key index
>>>>> "Tom" == Tom Lane writes: >> Notice that the two rows seem entirely independent (different >> xmin). The OP stated that his app generally does single-row >> inserts (with some exceptions not relevent here); however, we >> found a nearby row which shares the xmin: Tom> How is the timestamp column generated? I'm wondering what we Tom> can deduce from the fact that the timestamps are all different. Tom> It's evidently not now(). (answering this one since the OP has probably gone for the night) My understanding is that it is now(), but the OP should be able to give a definitive answer. (Yes, this does raise some questions about why it appears to have gone backwards at some points.) Tom> One thing that seems odd is that the xids are kinda small. Did Tom> the system just recently have a wraparound event? The system was recently dump/restored from a different box. The failing rows are all new inserts since the restore. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4913: Row missing from primary key index
>>>>> "Tom" == Tom Lane writes: >> The system was recently dump/restored from a different box. The >> failing rows are all new inserts since the restore. Tom> So the table has been insert-only so far? I was just thinking Tom> that HOT bugs seemed like a probable explanation, but that idea Tom> goes out the window if there have been no UPDATEs. No UPDATEs (and there are no HOT flags set on any tuple I looked at). There may have been DELETEs. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4929: Corrupted pg_class, possibly truncate/rollback related
>>>>> "Robert" == "Robert Treat" writes: Robert> Bug reference: 4929 Robert> Logged by: Robert Treat Robert> Email address: xzi...@users.sourceforge.net Robert> PostgreSQL version: 8.3.1 pe2=# select xmin, xmax, cmin, cmax, ctid, oid, relnamespace, relname, reltype, relowner, relfilenode, relpages, reltuples from pg_class where oid = 23708; xmin|xmax| cmin | cmax | ctid | oid | relnamespace | relname | reltype | relowner | relfilenode | relpages | reltuples ++--+--+--+---+--+--+-+--+-+--+- 3291061347 | 0 |6 |6 | (1118,2) | 23708 |23681 | prooln_m | 23710 | 10 | 654963 | 114055 | 7.42746e+06 2 | 3291061347 |6 |6 | (23,39) | 23708 |23681 | prooln_m | 23710 | 10 | 181519 | 104401 | 6.5017e+06 Robert> So, clearly this is bad. It seems we've gotten some level of Robert> corruption on disk. The most perculiar bits of information Robert> around this system are that we tend to have long running Robert> vacuum jobs (multiple days), and we recently did a truncate + Robert> rollback within a transaction on the table in question. I've Robert> also noticed that the file on disk for the 181519 row is not Robert> actually there. Oh, and this does run on lvm, though we Robert> haven't used the lvm feature set for a long time. So, worth Robert> investigating? I did some analysis on this at Robert's request on IRC. Here are hexdumps of the offending tuples: (1118,2): 1e60 63 9c 29 c4 00 00 00 00 06 00 00 00 00 00 5e 04 |c.)...^.| 1e70 02 00 1b 00 0b 29 20 ff ff ff 03 00 9c 5c 00 00 |.) ..\..| 1e80 70 72 6f 6f 6c 6e 5f 6d 00 00 00 00 00 00 00 00 |prooln_m| 1e90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 1ec0 81 5c 00 00 9e 5c 00 00 0a 00 00 00 00 00 00 00 |.\...\..| 1ed0 73 fe 09 00 00 00 00 00 87 bd 01 00 02 ab e2 4a |s..J| 1ee0 00 00 00 00 00 00 00 00 01 00 72 00 0f 00 00 00 |..r.| 1ef0 00 00 00 00 00 00 00 00 00 01 00 00 42 9c 29 c4 |B.).| 1f00 5b 01 00 00 00 00 00 00 00 09 04 00 00 02 00 00 |[...| 1f10 00 01 00 00 00 0a 00 00 00 0a 00 00 00 6f 00 00 |.o..| 1f20 00 15 5a 02 00 0a 00 00 00 02 00 00 00 00 00 00 |..Z.| Everything above looks about as we expect. (1118,1): this is an earlier version of the tuple, correctly marked dead, presumably resulting from the truncate/rollback referred to above: 1f30 19 55 23 c4 00 00 00 00 06 00 00 00 00 00 5e 04 |.U#...^.| 1f40 01 00 1b 00 0b 2a 20 ff ff ff 03 00 9c 5c 00 00 |.* ..\..| 1f50 70 72 6f 6f 6c 6e 5f 6d 00 00 00 00 00 00 00 00 |prooln_m| 1f60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 1f90 81 5c 00 00 9e 5c 00 00 0a 00 00 00 00 00 00 00 |.\...\..| 1fa0 72 fe 09 00 00 00 00 00 00 00 00 00 00 00 00 00 |r...| 1fb0 00 00 00 00 00 00 00 00 01 00 72 00 0f 00 00 00 |..r.| 1fc0 00 00 00 00 00 00 00 00 00 01 00 00 19 55 23 c4 |.U#.| 1fd0 5b 01 00 00 00 00 00 00 00 09 04 00 00 02 00 00 |[...| 1fe0 00 01 00 00 00 0a 00 00 00 0a 00 00 00 6f 00 00 |.o..| 1ff0 00 15 5a 02 00 0a 00 00 00 02 00 00 00 00 00 00 |..Z.| Again, no obvious surprises. This is (23,39) which is the broken one; note HEAP_XMAX_INVALID is set, despite the fact that this is a transaction that committed (as evidenced by the removal of the old relfilenode) so the row is showing up incorrectly to queries. Note also that HEAP_ONLY_TUPLE is set (but there are no other versions of this tuple on page 23). 0a20 02 00 00 00 63 9c 29 c4 06 00 00 00 00 00 5e 04 |c.)...^.| 0a30 02 00 1b 80 0b 29 20 ff ff ff 03 00 9c 5c 00 00 |.) ..\..| 0a40 70 72 6f 6f 6c 6e 5f 6d 00 00 00 00 00 00 00 00 |prooln_m| 0a50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0a80 81 5c 00 00 9e 5c 00 00 0a 00 00 00 00 00 00 00 |.\...\..| 0a90 0f c5 02 00 00 00 00 00 d1 97 01 00 8a 6a c6 4a |.j.J| 0aa0 00 00 00 00 00 00 00 00 01 00 72 00 0f 00 00 00 |..r.| 0ab0 00 00 00 00 00 00 00 00 00 01 00 00 c5 52 c5 b9 |.R..| 0ac0 5b 01 00 00 00 00 00 00 00 09 04 00 00 02 00 00 |[...| 0ad0 00 01 00 00 00 0a 00 00 00 0a 00 00 00 6f 00 00 |.o..| 0ae0 00 15 5a 02 00 0a 00 00 00 02 00 00 00 00 00 00 |..Z.| -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4929: Corrupted pg_class, possibly truncate/rollback related
>>>>> "Tom" == Tom Lane writes: > "Robert Treat" writes: >> PostgreSQL version: 8.3.1 >> Description:Corrupted pg_class, possibly truncate/rollback related Tom> FWIW, there is a bug fix in 8.3.4 addressing possible HOT-chain Tom> corruption after a REINDEX of pg_class. Not sure if that Tom> could've been the issue here. I asked Robert about that when we were discussing it on IRC, and he said that no such REINDEX had been done (and nor had ALTER TABLE RENAME and ALTER TABLE SET SCHEMA been done on the affected table). However I'm wondering if another 8.3.4 fix, the RecentGlobalXmin one, could be relevant here? http://archives.postgresql.org/pgsql-committers/2008-09/msg00105.php (I'm not seeing how it would be, but... note that the xids have got to the point that they'd appear to be in the past from the point of view of FirstNormalTransactionId) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] 8.4.0 data loss / HOT-related bug
>>>>> "Greg" == Greg Stark writes: Greg> Either of two things are true. Greg> Either transaction 6179 committed, [snip] This is all missing the point. The row should have been killed by transaction 4971, NOT 6179. By the time transaction 6179 tried to do anything with it, it was almost certainly already broken (or possibly 6179 broke it). Notice that in the log table, the log entry that records the most recent update to the row is the one with xmin=4971. There is no entry in the log table corresponding to 6179. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5048: psql: \g doesn't redirect COPY TO STDOUT, but redirects next query
The following bug has been logged online: Bug reference: 5048 Logged by: Andrew Deryabin Email address: and...@deryabin.com PostgreSQL version: 8.4 Operating system: FreeBSD Description:psql: \g doesn't redirect COPY TO STDOUT, but redirects next query Details: [pg...@localhost:site]=# COPY (SELECT 1) TO STDOUT \g filename.ext 1 Time: 0.370 ms [pg...@localhost:site]=# SELECT 2; Time: 0.290 ms [pg...@localhost:site]=# SELECT 3; ?column? -- 3 (1 row) Time: 0.295 ms ^Z $ cat filename.ext ?column? -- 2 (1 row) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5053: domain constraints still leak
The following bug has been logged online: Bug reference: 5053 Logged by: Andrew Gierth Email address: and...@tao11.riddles.org.uk PostgreSQL version: 8.5devel Operating system: FreeBSD Description:domain constraints still leak Details: Domain NOT NULL constraints (and probably other constraints too) aren't being enforced in some code paths. e.g. \pset null '' create domain tstdom as integer not null; create table test (a tstdom); insert into test values (null); ERROR: domain tstdom does not allow null values all correct up to now, but: insert into test select (r).* from (select null::test as r) s; INSERT 0 1 oops. select * from test; a (1 row) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5077: Corrupted Table
>>>>> "Bryan" == "Bryan McLemore" writes: Bryan> "invalid page header in block 900 of relation pg_tblspc/32041/138911/187737" Bryan> http://pgsql.privatepaste.com/83JfmQGtS5 Privatepaste urls do expire, so for the record here is the relevant part of the data in question: 82 00 00 00 50 01 72 8a 01 00 04 00 00 00 84 03 |P.r.| 0010 02 00 04 20 13 01 d9 00 a8 8e a2 01 d0 8d a2 01 |... | 0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0030 00 00 00 00 00 00 00 00 16 00 01 00 17 00 01 00 || 0040 18 00 01 00 19 00 01 00 1a 00 01 00 00 00 00 00 || 0050 1b 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0060 00 00 00 00 00 00 00 00 00 00 00 00 e8 9e 24 02 |..$.| 0070 60 9e 0c 01 d0 9d 1c 01 10 9d 74 01 48 9c 84 01 |`.t.H...| 0080 c0 9b 0c 01 e8 9a a2 01 30 9a 6c 01 50 99 bc 01 |0.l.P...| 0090 1c 00 01 00 1d 00 01 00 1e 00 01 00 28 00 01 00 |(...| 00a0 29 00 01 00 2a 00 01 00 2b 00 01 00 2c 00 01 00 |)...*...+...,...| 00b0 2d 00 01 00 30 98 32 02 68 97 8c 01 80 96 cc 01 |-...0.2.h...| 00c0 d8 95 44 01 98 94 74 02 c0 93 a8 01 a8 92 24 02 |..D...t...$.| 00d0 20 92 0c 01 90 91 1c 01 d0 90 74 01 08 90 84 01 | .t.| 00e0 80 8f 0c 01 00 00 00 00 00 00 00 00 00 00 00 00 || 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || The data appears intact other than invalid values for pd_lower and pd_special (and possibly pd_upper, wasn't sure about that one). Bryan> The reason they asked me to report this is that it appears Bryan> this occured when a disk filled up while pg_dump was running. I have no idea whether the disk full was the cause of this, but there was no evidence in the page data of a hardware failure, so it could do with investigation. (I don't know of any external cause that could damage pd_lower while leaving the rest of the page intact.) I did ask Bryan on IRC to make a copy of his data directory before doing the fix. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5084: Query gives different number of rows depending on ORDER BY
> Bernt Marius Johnsen wrote: >> Dump of the database: To save anyone else the bother, there's a VASTLY simpler testcase for this one, requiring no tables at all: test1=# explain select * from (values (1),(null)) v(k) where k = k order by k; QUERY PLAN --- Sort (cost=0.04..0.04 rows=2 width=4) Sort Key: "*VALUES*".column1 -> Values Scan on "*VALUES*" (cost=0.00..0.03 rows=2 width=4) (3 rows) test1=# explain select * from (values (1),(null)) v(k) where k = k; QUERY PLAN - Values Scan on "*VALUES*" (cost=0.00..0.03 rows=1 width=4) Filter: (column1 = column1) (2 rows) Notice that the (k = k) qual is being dropped somewhere, which changes the output since that's a disguised not-null condition. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5084: Query gives different number of rows depending on ORDER BY
>>>>> "Tom" == Tom Lane writes: Tom> After digging into it, I find that: Tom> 1. Without ORDER BY, process_equivalence generates an Tom> equivalence class that lists k twice. This is pretty bogus but Tom> it happens to produce the desired results in the example at Tom> hand. (In some other cases you'll get redundant clauses out, Tom> because the eclass machinery isn't expecting this.) Tom> 2. With ORDER BY k, the code first creates a single-element Tom> equivalence class containing k, because it needs that to Tom> represent the desired pathkey. Then, process_equivalence finds Tom> that both sides of the k = k clause are already known to be in Tom> the same eclass, so it concludes that this is redundant Tom> information. I'd found the right place in the code, but I hadn't twigged that the ORDER BY one was being called _first_, so I hadn't spotted the bug yet. Tom> I'm inclined to think that the best solution is to have Tom> process_equivalence just reject any clauses that have equal() Tom> left and right sides, ie, throw them back to be processed as Tom> ordinary non-equivalence clauses. The only case I can think of Tom> where this might be less than ideal is if you have "k = k AND k Tom> = x"; if both operators are strict then the k = k test is indeed Tom> redundant and could be discarded, but it won't be. But it Tom> doesn't seem like that's going to come up enough to be worth Tom> stressing about. If we wanted to be smart about it we'd have to Tom> have two kinds of single-element equivalence classes (one that Tom> implies a k = k check is needed, and one that does not). It Tom> doesn't seem worth the complication. Hmm. Is it ever possible for mergejoinable operators to be non-strict? Does that matter? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5084: Query gives different number of rows depending on ORDER BY
>>>>> "Tom" == Tom Lane writes: Tom> I'm inclined to think that the best solution is to have Tom> process_equivalence just reject any clauses that have equal() Tom> left and right sides, ie, throw them back to be processed as Tom> ordinary non-equivalence clauses. >> Hmm. Is it ever possible for mergejoinable operators to be >> non-strict? Does that matter? Tom> I'm not sure. ISTR that nodeMergejoin makes some effort to Tom> support such operators, but the btree code doesn't really. In Tom> any case, it doesn't matter. Leaving the clause out of the Tom> equivalence machinery is certainly safe; at worst we'll end up Tom> with a redundant test or two in the final plan. Yeah, and clearly leaving in that kind of redundant test is no big deal. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5087: Submitted bug reports not showing up in a timely manner (or at all)
The following bug has been logged online: Bug reference: 5087 Logged by: Andrew Gierth Email address: and...@tao11.riddles.org.uk PostgreSQL version: any Operating system: any Description:Submitted bug reports not showing up in a timely manner (or at all) Details: Bug reports from users who are non-subscribers to pgsql-bugs, or who use a different email address when filling in the bug report form, are not being processed in a reliable or timely manner. To pick a recent case, bug #5085 was submitted by an IRC user (at my suggestion) at 2009-09-28 22:12 +, or a bit over 22 hours ago as I write this; it has yet to appear. This isn't an isolated case; I regularly refer IRC users with bug reports to the reporting form, and I estimate that more than one-third of those reports never show up. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5087: Submitted bug reports not showing up in a timely manner (or at all)
>>>>> "Tom" == Tom Lane writes: >> They get processed in the moderator queue of -bugs along with all >> other posts there... We're probably just back in the situation >> where we need more moderators for it... Tom> A quick grep in my mail logs shows that since Jan 1, I have Tom> received 440 bug-reporter emails, bearing numbers from 4598 to Tom> 5087 (a range of 490 numbers). So Andrew's "one-third" is a Tom> large exaggeration, My "one-third" figure is out of those cases where I say to someone on IRC, "you need to submit this as a bug", they say "ok, I filled in the reporting form and it gave me number #". This sample is probably quite biased against people who would already have been subscribed to the -bugs list. (In most cases I encourage people to submit their own bugs rather than trying to own the issue for them. If it looks important, I do try and make sure that they subscribe to -bugs first; but I can't guarantee that they do, and nor am I in a position to track the issue to make sure it really does show up. The one-third figure is only an impression based on the number of cases in which I am later reminded of the bug and go back to look for it.) -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5087: Submitted bug reports not showing up in a timely manner (or at all)
>>>>> "Joshua" == Joshua Tolley writes: >> > To pick a recent case, bug #5085 was submitted by an IRC user (at my >> > suggestion) at 2009-09-28 22:12 +, or a bit over 22 hours ago as I >> > write Joshua> I am a -bugs moderator, and don't see that I ever got a Joshua> notice that I needed to approve #5085. I did get one for 5804 Joshua> and 5806, FWIW. That's what I was afraid of; it rather suggests that some submissions are going astray without any moderator ever seeing them. Someone should probably check the mail logs... -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5113: Postgres not scanning indexes
>>>>> "dan" == "dan" writes: dan> I expect the explain to say index scan; instead it says table scan. dan> The index has ALL the info I need It may have all the info _you_ need, but what it doesn't have is all the info that _postgres_ needs; specifically it doesn't contain enough row visibility info for index-only scans to be possible without consulting the table. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: BUG #5065: pg_ctl start fails as administrator, with "could not locate matching postgres executable"
Dave Page wrote: On Fri, Oct 16, 2009 at 7:03 PM, Jesse Morris wrote: -Original Message- From: Dave Page [mailto:dp...@pgadmin.org] Sent: Friday, October 16, 2009 2:14 AM To: Jesse Morris Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Re: BUG #5065: pg_ctl start fails as administrator, with "could not locate matching postgres executable" The patch: --begin patch-- :-(. Unfortunately inlining the patch in the email has munged it beyond usability. Can you resend it as an attachment please? Oops! Re-sent, as an attachment. Thanks. I've had a play with this, and it seems to work fine in 8.4.1 - at least, it doesn't seem to cause any regression that I can see when testing in Vista or XP. I cannot reproduce the problem since I wrote the original fix though, so I cannot confirm that this fixes any new cases; we'll have to take your word for that :-) The code around this has changed a little on -head. I don't have any more spare cycles at the moment - are you able to produce an updated patch for 8.5? Andrew/Magnus; we do still see occasional failures of this nature, so I believe there is still an issue here. Can we look at getting this backpatched for 8.3.whatever and 8.4.2, assuming it looks good to you as well? It looks OK to me (modulo the incorrect changing of "its" to "it's" in a comment - whoever did that was trying to make it consistent, but unfortunately made it consistently wrong). However, I'd like a bit more comment added on just why doing this is safe. Would it still be safe if someone granted some dangerous privilege directly to the Administrator user, if that's possible? cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Re: BUG #5065: pg_ctl start fails as administrator, with "could not locate matching postgres executable"
Magnus Hagander wrote: From a quick look, it looks fine to me. I don't have time to do a complete check right now, but I'll do that as soon as I can and then commit it - unless people feel it's more urgent than maybe a week worst case, in which case someone else has to pick it up :-) I'd rather wait till you can check it. cheers andrew -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5126: convert_to preventing index scan
>>>>> "Peter" == Peter Eisentraut writes: >> I have table with bytea column, which is indexed (1) >> I want to use index during pattern matching (eg. dir like >> someDirectoryName >> || '/%'), but concatenation of two strings cause error (2) >> So I have to use function convert_to (converting text to bytea), but >> this >> has awful explain plan (3) Peter> You haven't told us how the convert_to function is defined. convert_to is a builtin function. If there's a bug here, it's that convert_to is defined as stable rather than immutable. (Sure it depends on server_encoding, but that can't exactly change... if there's any other reason why it's not immutable, I can't think what it is.) Example (5) from the original message is the correct approach in any case; as long as either operand of the || is explicitly passed as, or cast to, a bytea, then it should work. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5126: convert_to preventing index scan
>>>>> "Tom" == Tom Lane writes: >> convert_to is a builtin function. If there's a bug here, it's that >> convert_to is defined as stable rather than immutable. (Sure it >> depends on server_encoding, but that can't exactly change... if >> there's any other reason why it's not immutable, I can't think >> what it is.) Tom> The conversion itself is dependent on changeable catalog Tom> entries, ie, pg_conversion. So "stable" seems the appropriate Tom> marking to me. That sounds like a bit of a stretch to me... we treat lots of stuff as immutable which is actually easier to change than pg_conversion entries (OS locale definitions for example). -- Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5126: convert_to preventing index scan
>>>>> "Tom" == Tom Lane writes: Tom> The conversion itself is dependent on changeable catalog Tom> entries, ie, pg_conversion. So "stable" seems the appropriate Tom> marking to me. >> That sounds like a bit of a stretch to me... we treat lots of >> stuff as immutable which is actually easier to change than >> pg_conversion entries (OS locale definitions for example). Tom> Um ... locale *is* fixed within a given database, or at least Tom> LC_COLLATE and LC_CTYPE are. If you see cases where we have Tom> this wrong, they may need to be revisited. The value of LC_CTYPE etc. is fixed, but the meaning that the OS assigns to that value can be changed (arguably more easily than changing pg_conversion, now that we don't allow builtin conversion funcs to be used for conversions other than the one they are coded for). Of course, changing the definition of a locale will break everything until you reindex, etc., but we put up with that because the alternatives are clearly silly. -- Andrew. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5154: ERROR: cannot assign non-composite value to a row variable
>>>>> "Pavel" == Pavel Stehule writes: >> As discussed on the irc. I had a problem with a utility function >> that was being passed a NEW row and a null for the OLD row. The >> error was created when it tries to store the row variable in the >> local variables. RhodiumToad on the list provided this simple >> test. >> >> create type foo1 as (a integer, b text); >> CREATE TYPE >> create type foo2 as (c integer, d foo1); >> CREATE TYPE >> >> create function foo() returns foo2 language plpgsql as $f$ declare v foo2; >> begin v := null; return v; end; $f$; >> CREATE FUNCTION Pavel> This isn't bug - it is just feature. No, it's a bug. Here's a clearer testcase: create type foo1 as (a integer, b text); create type foo2 as (c integer, d foo1); create or replace function foo1() returns foo1 language plpgsql as $f$ declare v foo1; begin v := null::foo1; return v; end; $f$; create or replace function foo2() returns foo2 language plpgsql as $f$ declare v foo2; begin v := null::foo2; return v; end; $f$; select foo1(); foo1 -- (,) (1 row) select foo2(); ERROR: cannot assign non-composite value to a row variable CONTEXT: PL/pgSQL function "foo2" line 1 at assignment Alternatively: create or replace function foo1(r foo1) returns foo1 language plpgsql as $f$ declare v foo1; begin v := r; return v; end; $f$; create or replace function foo2(r foo2) returns foo2 language plpgsql as $f$ declare v foo2; begin v := r; return v; end; $f$; select foo1(null); foo1 -- (,) (1 row) select foo2(null); ERROR: cannot assign non-composite value to a row variable CONTEXT: PL/pgSQL function "foo2" while storing call arguments into local variables These calls should either both work or both fail. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5200: Use of min suffix in autovacuum_naptime ignored
The following bug has been logged online: Bug reference: 5200 Logged by: Andrew Masterton Email address: a.j.master...@open.ac.uk PostgreSQL version: 8.3.8 Operating system: RedHat Enterprise 5.4 Description:Use of min suffix in autovacuum_naptime ignored Details: The default configuration of 8.3.8 has autovacuum_naptime = 1min. It would appear that the min is ignored as turning up debug show the autovacuum running every second. On my 8.3.8 installation with a large number of databases and tables this has the side effect of the stats collector process using up large amounts of CPU and I/O. Changing this setting to 60min causes the autovacuum process to have the correct 60 second naptime. I Haven't tried removing the min and setting it to s to see if any time suffix is ignored for this configuration option. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5235: Segmentation fault under high load through JDBC
>>>>> "Robert" == Robert Haas writes: Robert> How about (3) getrlimit(RLIMIT_STACK) lies through its teeth, Robert> by ignoring the existence of another and lower limit imposed Robert> elsewhere? Robert> A little Googling seems to reveal that FreeBSD has a Robert> parameter called MAXSSIZ (and possibly a variant for 64-bit Robert> builds). I kind find a lot of people talking about needing Robert> to raise it (for MySQL, among other things), but I haven't Robert> been able to determine for certain what the default is. Robert> Perhaps it is set to a really low value on the OP's system? The default is 64MB on i386, 512MB on amd64; that's where the getrlimit value comes from unless it's been explicitly reduced somewhere. The kernel MAXSSIZ sets the value of the hard limit for RLIMIT_STACK for proc0, and everything else inherits that. All setrlimit calls for RLIMIT_STACK are explicitly clamped to MAXSSIZ, so there's no way to set that value higher than the kernel limit, and no way for getrlimit to report a value higher than the real limit. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5235: Segmentation fault under high load through JDBC
>>>>> "Oleg" == Oleg Jurtšenko writes: Oleg> I tried to execute "select instr(ad_parent_tree(?,?),'|'||'?'||'|') AS Oleg> isItsOwnChild from dual;" query with psql terminal and got Oleg> segmentation fault as well. Oleg> The most interesting thing is that this function makes segmentation Oleg> fault also on FreeBSD 7.2 with Postgresql-8.3.7. What are the definitions of your instr() and ad_parent_tree() functions? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5235: Segmentation fault under high load through JDBC
>>>>> "Andrew" == Andrew Gierth writes: Andrew> What are the definitions of your instr() and ad_parent_tree() Andrew> functions? Well, there's so much wrong with that ad_parent_tree function - it's always going to recurse infinitely (with a new subxact per recursion level, even) regardless of the data, and the only thing that will stop it is when it throws an exception due to reaching the max stack depth - and it then CATCHES that exception and returns. Still, even though the code is preposterous, the result shouldn't be a segfault. I wasn't able to reproduce one myself (using 8.3.7 on freebsd 7.2) however. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5234: ALTER TABLE ... RENAME COLUMN change view definition incorrectly
>>>>> "Robert" == Robert Haas writes: > On Thu, Dec 10, 2009 at 1:46 AM, Tom Lane wrote: >> >> My reading of the spec is that USING (and therefore NATURAL) is >> defined to join identically named columns. Â Therefore, renaming >> one of the input columns as the OP did *should* indeed *must* >> break the view. Â The problem is not how to make it work, it's how >> to give an error message that doesn't look like an internal >> failure. Robert> That seems ugly and unnecessary. I think we might be able to Robert> define ourselves out of this problem. We don't guarantee Robert> (and have never guaranteed) that selecting from a stored view Robert> will produce the same results as re-executing the original Robert> query. For example, * refers the list of columns at Robert> definition-time, not execution-time, and if a column is Robert> renamed, the view still refers to the same column; it doesn't Robert> start crashing, nor would we want it to. Similarly, here, Robert> the USING is internally converted to an equality join on the Robert> two columns, and the ambiguous output column is, I think, Robert> resolved in favor of one of them. I think we can just say Robert> that that conversion happens in toto at parse-time, just as Robert> the *-to-column-list conversion and the Robert> column-name-to-column-reference conversions do. This seems Robert> like a significantly more useful behavior and as a fringe Robert> benefit it simplifies the code. There's another possible solution (albeit a somewhat nontrivial one) which came up when a bunch of us were talking about this one on IRC; which is to handle the problem in the view deparse: if a column used in a USING clause has been renamed, add an alias to the query that renames it back, e.g. select ... from table1 as table1(v,a) join ... using (v) This would have to affect all the other references to that same column in the query, so you'd need to do something like this: before deparsing, walk the query looking for offending USING clauses, and make a list of renamings to apply to column names. I haven't tried actually implementing this, but I believe it is possible. -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5240: Stable Functions that return a table type with a dropped column fail
>>>>> "David" == "David Gardner" writes: David> The following bug has been logged online: David> Bug reference: 5240 David> Logged by: David Gardner David> Email address: dgard...@creatureshop.com David> PostgreSQL version: 8.4.1 David> Operating system: Debian Linux, amd64 2.6.30 David> Description:Stable Functions that return a table type with a dropped David> column fail David> Details: David> SELECT foo(); works while SELECT * FROM foo(); fails. David> However redefining the function as volatile fixes the David> issue. Possibly related to BUG #4907. I don't think it's particularly closely related to #4907. I've confirmed this bug still exists in both 8.4.2 and HEAD; it's clearly a problem that affects only inlined SQL functions (making the function volatile defeats inlining, and thus avoids the bug). -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5240: Stable Functions that return a table type with a dropped column fail
>>>>> "Tom" == Tom Lane writes: > Andrew Gierth writes: >> I don't think it's particularly closely related to #4907. Tom> Yeah. BTW, did #4907 ever get fixed in the back branches? -- Andrew (irc:RhodiumToad) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5296: crash when two 'add column' diagrams are open
The following bug has been logged online: Bug reference: 5296 Logged by: andrew neill Email address: andrew.nei...@bbc.co.uk PostgreSQL version: 1.10 Operating system: windows xp Description:crash when two 'add column' diagrams are open Details: if you open two 'add column' dialogs and will in the second and click ok then try to fill in the second and click ok the program crashes. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Obscure bug
Here is an obscure bug I encountered. Note, this was running on: RedHat 6.2 (standard) DBD-Pg-0.93 postgresql-7.0.2 All built using gcc 2.95.2 Using the attached test program to insert into a table with the following definition: expr_idint4 not null line_noint4 not null line_text varchar(254) The output is as follows: perl t2 x 2: ERROR: Unterminated quoted string - Andrew BrownE-Mail: mailto:[EMAIL PROTECTED] Senior Systems Engineer Phone: +61 7 4928 1020 ADC/Saville Systems Fax:+61 7 4928 1082 Web:http://www.adc.com bug.tar.gz
[BUGS] Unnexpected results using to_number()
Is this supposed to happen? I discovered this when I was experimenting with
converting a string to a number.
# SELECT to_number('12,454.8-', '99G999D9S');
to_number
---
-12454.8
(1 row)
# SELECT to_number('12,454.8-', '');
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!#
I am running PostgreSQL 7.0.2 on FreeBSD 3.4-STABLE (x86). Thanks,
- Andrew.
[BUGS] Periodic freezing of backend processes
PostgreSQL 7.0.2
Debian 2.3 (woody)
Linux Kernel 2.2.15
Hi,
I am finding that I periodically have a backend process just 'freeze' on
me. It's not like it's doing something that all of a sudden get's
wildly inefficient because this can be when I'm repetitively processing
in a loop, and where responsiveness is normally sub-second I have waited
hours to see if these terminate and they don't.
What can I do to tickle the backend processes to get it to tell me where
it is at?
I have found that if I kill the backend process that is locked up, then
do exactly the same query, it locks up again. BUT if I shut down and
restart the postmaster and then do exactly the same query (reload my web
page, in fact) the response is immediate again.
A couple of other points to note:
- the webserver, database server and all are on my laptop - I am the
only user and there is only one request active at the time this happens
(although I have seen it happen on our production machine, running 6.5.3
as well).
- I have seen the freeze happening from PHP scripts as well as from
Perl scripts.
- A 'ps' does not show the process as 'waiting':
$ps flaxww | grep postgres | grep -v grep
00031 15629 1 0 0 5824 1152 select Spts/2 0:00
/usr/lib/postgresql/bin/postmaster -b /usr/lib/postgresql/bin/postgres
-B 256 -N 16 -D /var/lib/postgres/data -d 0 -o -F -S 4096
04031 15634 15629 0 0 6432 4380 select Spts/2 11:14 \_
/usr/lib/postgresql/bin/postgres localhost andrew newsfeed
UPDATE
That's right now, so it's frozen on an 'UPDATE' and looking at my (perl)
program the only 'UPDATE' is this one:
UPDATE story SET wcount=$count WHERE story_id=$story_id;
With story_id being the table's primary key, of course. Up until it
froze it was processing one of these UPDATE's every second or two
(amongst many other SQL statements). Earlier in the evening a similar
thing happened except the statement was an 'INSERT' and the program had
been running fine for about three hours before it locked up.
If I kill the backend process that has locked up I may get messages when
I next do a VACUUM that say I need to recreate the indexes on some table
too.
Sorry if this is a bit vague, but if there's some signal I can send to
the locked process to try and tell where it is or what it's trying to
do, perhaps I can find out more next time it happens. I've tried kill
-3 and kill -5 but don't seem to get any core files. I'd crank up the
logging except that whenever I do that I tend to run out of disk space
:-(
Thanks,
Andrew.
--
_
Andrew McMillan, e-mail: [EMAIL PROTECTED]
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
Re: [BUGS] Damn bug!
Bernie Huang wrote:
>
> I have a field using array (eg; col1 text[]) in Postgres, and it's a
> list of attributes. (eg; {"hi","hello","whatever","Empty",...})
>
> When I tried to update elements in the array via PHP script,
>
> $query = "update table
> set col1[1]='$var1',
> col1[2]='$var2',
> ...
> col1[4]='$var4'";
>
> it worked alright; however, when it came to the word 'Empty', it just
> wouldn't update. So, after a lot of struggle... )xp ... I finally
> replaced the word 'Empty' with 'None' or something alike, and it worked!
>
I think that there is something strange going on with assignment of
multiple array subscripts in PostgreSQL there...
It looks like a PostgreSQL limitation which is being detected on an
'insert' but is not being detected on an 'update' (and it probably
should be).
Look at the interesting log of various stuff from psql doing similar
things:
testing=# create table t1 ( c1 text[] );
CREATE
testing=# insert into t1 (c1[1], c1[2], c1[3] ) values('not',
'actually', 'empty' );
ERROR: Attribute 'c1' specified more than once
testing=# insert into t1 (c1[1], c1[2], c1[3] ) values('not',
'actually', 'empt' );
ERROR: Attribute 'c1' specified more than once
testing=# insert into t1 (c1 ) values('{"not", "actually", "empt"}' );
INSERT 373577 1
testing=# select * from t1;
c1
---
{"not","actually","empt"}
(1 row)
testing=# insert into t1 (c1 ) values('{"not", "actually", "empty"}' );
INSERT 373578 1
testing=# select * from t1;
c1
{"not","actually","empt"}
{"not","actually","empty"}
(2 rows)
testing=# update t1 set c1[2] = 'empty';
UPDATE 2
testing=# select * from t1;
c1
-
{"not","empty","empt"}
{"not","empty","empty"}
(2 rows)
testing=# update t1 set c1[2] = 'empty', c1[3] = 'full';
UPDATE 2
testing=# select * from t1;
c1
-
{"not","empty","full"}
{"not","empty","empty"}
(2 rows)
Now that was a bit strange, wasn't it?
testing=# update t1 set c1[2] = 'other', c1[3] = 'full';
UPDATE 2
testing=# select * from t1;
c1
-
{"not","other","full"}
{"not","other","empty"}
(2 rows)
testing=# update t1 set c1[3] = 'full';
UPDATE 2
testing=# select * from t1;
c1
{"not","other","full"}
{"not","other","full"}
(2 rows)
testing=# update t1 set c1[2] = 'strange', c1[3] = 'notfull';
UPDATE 2
testing=# select * from t1;
c1
--
{"not","strange","full"}
{"not","strange","full"}
(2 rows)
--
So it looks like UPDATE is silently ignoring second and subsequent
references to the same array variable. In most cases...
A good workaround muight be for you to use the '{"blah", "blah",
"blah"}' syntax for updating the array, although it's a pretty messy
syntax.
Cheers,
Andrew.
--
_
Andrew McMillan, e-mail: [EMAIL PROTECTED]
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
[BUGS] pg_dump 7.0.2 fails on linuxppc
Hi People, I have encountered the following problem with pg_dump from postgresql 7.0.2 on linuxppc: bash $ pg_dump template1 >tp.db getFuncs(): SELECT failed. Explanation from backend: 'ERROR: getattproperties: no attribute tuple 1255 -2'. CONFIGURATION machine: PowerMac Rev2 B/W G3 450, 256MB RAM, 2 x 9GB u2/w scsi kernel: LinuxPPC 2.2.17pre13 with RAID patches distribution: LinuxPPC 2000 Q1 postgresql: built from postgresql-7.0.2-2.src.rpm for target ppc compiler: gcc 2.95.2 built with --with-cpu=750 I encountered the same problem with postgresql built from the 7.0.2 tarball for linuxppc. I have also built postgresql 7.0.2 for i686 (RedHat 6.1) but the problem is not evident on that architecture. Cheers, Andrew
Re: [BUGS] Re: to_date problems (Re: Favor for Postgres User at WSI)
Thomas Lockhart wrote:
>
> Because of the common and documented cutoff date (1970 currently, 1950
> in some other apps) used to solve this problem.
Most database software I have seen uses some form of setting to control
the actual date used here, and that is the most long-term solution.
something like:
set CENTURY_WINDOW TO '1980';
Would be nicest.
Regards,
Andrew.
--
_____
Andrew McMillan, e-mail: [EMAIL PROTECTED]
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
[BUGS] Problem with BETWEEN and a view.
I just installed v7.0.3 release on a FreeBSD 4.x system. (Problem still happened in
7.0.2 too).
This is the problem I noticed:
# select * from mailredirs;
username |destination | start | stop |
reason
--++++---
als | [EMAIL PROTECTED] | 2000-10-31 17:26:52+11 | 2000-11-25 16:29:01+11 |
Just because.
(1 row)
# select * from mailredirs where start < CURRENT_TIMESTAMP and stop >
CURRENT_TIMESTAMP;
ERROR: Bad timestamp external representation 'Just because.'
Why is it even looking at the 'reason' field??
Unfortunately it gets more complicated here, as I am going to dump you with a load of
table
and view definitions.
CREATE VIEW MailRedirs AS
SELECT u.Name AS Username, v1.Value AS Destination, v2.Value::timestamp AS Start,
v3.Value::timestamp AS Stop, v4.Value AS Reason
FROM Values v1, Values v2, Values v3, Values v4, Users u
WHERE v1.AttributeID = get_attributeid('MailRedir', 'Dest')
AND v2.AttributeID = get_attributeid('MailRedir','Start')
AND v3.AttributeID = get_attributeid('MailRedir','End')
AND v4.AttributeID = get_attributeid('MailRedir','Reason')
AND u.ID=v1.ThingID AND u.ID=v2.ThingID AND u.ID=v3.ThingID AND u.ID=v4.ThingID;
The table "Values" joins an Attribute to a Thing with a text value. "Users" is a
view on "Things", pulling out only "Things" of type User...
CREATE TABLE Values (
ID serial PRIMARY KEY,
AttributeID int4 NOT NULL REFERENCES Attributes,
ThingID int4 NOT NULL REFERENCES Things ON DELETE CASCADE,
Valuetext NOT NULL
);
CREATE TABLE Attributes (
ID serial PRIMARY KEY,
Name text NOT NULL,
Subname text NOT NULL,
Format text NOT NULL,
UNIQUE(Name, Subname)
);
CREATE TABLE Things (
IDserial PRIMARY KEY,
Name text NOT NULL,
TypeIDint4 NOT NULL REFERENCES Types,
ParentID int4 REFERENCES Things DEFAULT NULL
);
CREATE VIEW Users AS
SELECT th.ID, th.Name, th2.Name AS ParentName, th2.ID AS ParentID
FROM Things th, Things th2
WHERE th2.ID=th.ParentID AND Types.Name='User' AND th.TypeID=Types.ID;
CREATE FUNCTION get_attributeid(text, text) returns int4 AS 'SELECT ID FROM Attributes
WHERE (Name,Subname)=($1,$2)'
LANGUAGE 'sql' WITH (iscachable);
Re: [BUGS] Problem with BETWEEN and a view.
Further to this, I wish you to note the following works correctly: # select start, stop from mailredirs where start < CURRENT_TIMESTAMP; start | stop + 2000-10-31 17:26:52+11 | 2000-11-25 16:29:01+11 (1 row) # select start, stop from mailredirs where stop > CURRENT_TIMESTAMP; start | stop + 2000-10-31 17:26:52+11 | 2000-11-25 16:29:01+11 (1 row) Also, there is definitely only one row in the entire "Values" table that contains a value of "Just because." # select * from values where value LIKE 'Just because.'; id | attributeid | thingid | value ---+-+-+--- 13525 | 46 |1246 | Just because. (1 row) Regards, Andrew. On Wed, 15 Nov 2000, I wrote: > > I just installed v7.0.3 release on a FreeBSD 4.x system. (Problem still happened in >7.0.2 too). > > This is the problem I noticed: > > # select * from mailredirs; > username |destination | start | stop | > reason > >--++++--- > als | [EMAIL PROTECTED] | 2000-10-31 17:26:52+11 | 2000-11-25 16:29:01+11 | >Just because. > (1 row) > > # select * from mailredirs where start < CURRENT_TIMESTAMP and stop > >CURRENT_TIMESTAMP; > ERROR: Bad timestamp external representation 'Just because.' > > Why is it even looking at the 'reason' field??
Re: [BUGS] Problem with BETWEEN and a view.
> Looks like a bug to me, but I'd like not to have to reverse-engineer the
> test case before I can look at it. Could you provide some sample data,
> as well as the missing "Types" table declaration? Ideally a psql script
> file to load everything up from scratch and trigger the error ;-)
Well, I dont blame you!! I am going insane with this database over here...
arguably the 'bug' is that I'm doing something which shouldn't be done by a
normal sane person ;-)
Here's a simpler script which reproduces the bug:
CREATE TABLE Happy (
x int4 PRIMARY KEY,
y text
);
CREATE FUNCTION get_happyx(text) RETURNS int4 AS
'SELECT x FROM Happy WHERE y = $1' LANGUAGE 'sql' WITH (iscachable);
CREATE TABLE Joy (
happyx int4 REFERENCES Happy,
z text
);
INSERT INTO Happy (x,y) VALUES (1, 'One');
INSERT INTO Happy (x,y) VALUES (2, 'Two');
INSERT INTO Happy (x,y) VALUES (3, 'Three');
INSERT INTO Happy (x,y) VALUES (4, 'Four');
INSERT INTO Joy (happyx,z) VALUES (1, 'i love postgresql');
INSERT INTO Joy (happyx,z) VALUES (2, CURRENT_TIMESTAMP - '5 days'::interval);
INSERT INTO Joy (happyx,z) VALUES (3, CURRENT_TIMESTAMP + '5 days'::interval);
INSERT INTO Joy (happyx,z) VALUES (4, 'Tom Lane r0x0rs');
-- This view is the centre of the problem:
CREATE VIEW Depressed AS
SELECT j1.z AS Text1, j2.z::timestamp AS Start,
j3.z::timestamp AS Stop, j4.z AS Text2
FROM Joy j1, Joy j2, Joy j3, Joy j4
WHERE j1.happyx = get_happyx('One')
AND j2.happyx = get_happyx('Two')
AND j3.happyx = get_happyx('Three')
AND j4.happyx = get_happyx('Four');
Now to test it:
foo=# SELECT * FROM Depressed;
text1 | start | stop | text2
---+++-
i love postgresql | 2000-11-10 17:25:45+11 | 2000-11-20 17:25:45+11 | Tom Lane r0x0rs
(1 row)
foo=# SELECT * FROM Depressed WHERE Start < CURRENT_TIMESTAMP AND Stop >
CURRENT_TIMESTAMP;
ERROR: Bad timestamp external representation 'i love postgresql'
Bingo!
Hope that helps,
Andrew.
Re: [BUGS] NT Binary V7.0 - postgres fails start cause PG_VERSION
[EMAIL PROTECTED] wrote:
>
> Elian Carsenat ([EMAIL PROTECTED]) reports a bug with a severity
>of 2
> The lower the number the more severe it is.
>
> Short Description
> NT Binary V7.0 - postgres fails start cause PG_VERSION
>
> Long Description
> NT Binary V7.0 - postgres fails to start because PG_VERSION not recognized properly
>(windows char encoding ?)
>
> See example code.
>
> Thanks guys for your great database!
>
> Sample Code
> C:\pgsql\bin>postgres.exe 1>postgres.log
> DEBUG: Data Base System is starting up at Tue Nov 14 09:34:39 2000
> DEBUG: Data Base System was interrupted being in production at Tue Nov 14 09:34
> :14 2000
> DEBUG: Data Base System is in production state at Tue Nov 14 09:34:39 2000
> FATAL 1: Version number in file 'C:\pgsql\data/PG_VERSION' should be 7.0
> , not 7.0
>
> No file was uploaded with this report
>From the line break in the "should be 7.0
, not 7.0" I wonder if it isn't a CRLF vs LF problem?
Regards,
Andrew.
--
_
Andrew McMillan, e-mail: [EMAIL PROTECTED]
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
Re: [BUGS] subselects doesn't work in v7.0.3
[EMAIL PROTECTED] wrote: > > jose ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > subselects doesn't work in v7.0.3 > > Long Description > Version: PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.95.2 > > - I'm trying the following query in a table with 1973093 rows: > > EXPLAIN select count(*) >from marche >where ristampa = 'S' >and marca in >( >select marca from marche where ristampa is null and >data_lotto between '1998/07/01' and '1999/01/31' >); > > NOTICE: QUERY PLAN: > Aggregate (cost=98854229180.08..98854229180.08 rows=1 width=4) > -> Seq Scan on marche (cost=0.00..98854229130.75 rows=19731 width=4) > SubPlan > -> Materialize (cost=50101.13..50101.13 rows=6577 width=12) > -> Seq Scan on marche (cost=0.00..50101.13 rows=6577 width=12) > EXPLAIN > > - but it takes to many time: (after about 16 hours I interrupt the query) This is a known bug with IN ( ... ) and the use of indexes - you would get better results using EXISTS. Cheers, Andrew. -- _ Andrew McMillan, e-mail: [EMAIL PROTECTED] Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
RE: [BUGS] Concat error in PL/pgsql
Simple add lines as shown: > for r in select * from tconcattest loop IF r.str IS NOT NULL THEN > output := output || r.str; END IF; > end loop; - Andrew
RE: [BUGS] Concat error in PL/pgsql
A few hours ago, I wrote: > > Simple add lines as shown: > > > for r in select * from tconcattest loop > IF r.str IS NOT NULL THEN > > output := output || r.str; > END IF; > > end loop; > This would probably be better: for r in select * from tconcattest where str is not null loop output := output || r.str; end loop;
Re: [BUGS] Cannot Create plpqsql function!
> asreddy wrote:
>
> Using postgresql 6.5.2 on RedHat linux 6.1. Getting the following error while
> creating function:
>
> ERROR: Procedures cannot take more than 8 arguments
>
> Any pointers? Do not tell me to go for version 7. I may not have that time to go
> for a change.
Make one of your arguments a text string containing multiple of your real
arguments. Inside your function split it up into it's original constituents.
You should be on 7.x though. Really.
Cheers,
Andrew.
--
_____
Andrew McMillan, e-mail: [EMAIL PROTECTED]
Catalyst IT Ltd, PO Box 10-225, Level 22, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [BUGS] the index on INTEGER field does not work (PG 7.1.2)
Please see FAQ 4.9 http://postgresql.bteg.net/docs/faq-english.html#4.9 On Fri, 15 Jun 2001, Alexandr S. wrote: > > Bug: the index on INTEGER field does not work (PG 7.1.2). > > Test 1: > > 1) create table test_int(id int primary key); > > 2) insert 1 records in table test_int with perl program (values > 1,2,3,...,1). > > 3) 500 times execute query > >SELECT * FROM test_int WHERE id = random number > >(random number puts with perl program) > > 4) 500 queries executes for 30 seconds > > Test 2: > > 1) create table test_int1(id int); (i.e. without primary key) > > 2) insert 1 records in table test_int1 with perl program (values > 1,2,3,...,1). > > 3) 500 times execute query > >SELECT * FROM test_int1 WHERE id = random number > >(random number puts with perl program) > > 4) 500 queries executes for 30 seconds too :~-( ... > > > P.S. For TEXT field the same operations executes for 30 and 1 seconds > correspondingly. > > > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] problem with \d {tablename}
Hi I'm have problems checking the descripton of the table when using \d with the tablename. I've correctly created the database and can insert/query the tables so they are definetly there. The error message I get for \d kids; is Did not find any relation named "kids;". The version of postgreSQL I'm using is 7.0.2 cheers andy ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] non-standard string literals
POSTGRESQL BUG REPORT TEMPLATE
Your name : Andrew Pimlott
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) :
Operating System (example: Linux 2.0.26 ELF) :
PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3
Compiler used (example: gcc 2.95.2) :
Please enter a FULL description of your problem:
As documented at
http://www.ca.postgresql.org/users-lounge/docs/7.1/user/sql-syntax.html#SQL-SYNTAX-CONSTANTS
Postgres supports some non-standard extensions to string literals.
One of the reasons I love Postgres is for its support of standard
SQL, and this violation is an uncharacteristic annoyance.
Normally, this isn't an issue, because when making SQL calls from
programs, I use placeholders instead of string literals. However, I
have queries like:
select * from t where c like ? escape '\'
(because even with placeholders, you have to escape "LIKE"
metacharacters) which works as expected on SQL Server and Oracle.
For Postgres, I need
select * from t where c like ? escape '\\'
Or, I can use a placeholder for the literal backslash, but ... ugh.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
Enter in psql:
create table t (c varchar(10));
insert into t values ('hello');
select * from t where c like 'h%' escape '\'; -- FAILS
select * from t where c like 'h%' escape '\\'; -- WORKS
Or in Perl DBI:
...
$sth = $dbh->prepare(<execute; # (\\ is one character above) FAILS
$sth = $dbh->prepare(<execute("\\"); # ("\\" is one character) WORKS
If you know how this problem might be fixed, list the solution below:
-
I don't know how this type of preference is usually controlled in
Postgres, but an option to enable strict SQL compliance would be
nice.
Thanks.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[BUGS] Strange pg_oid problem.
Hello.
I'm using debian on i386 with postgresql 7.1.3.
I'm writing an interface libary to postgresql which uses libpq, and
I've stumbled across a weird problem and i'm having problems tracking
down.
Oh and sorry about bad code formating, evolution an't giving me as much
room as i want.
main()
{
gint err;
PGresult *res;
res = PQexec(globaldbconn->conn, "SELECT *,oid FROM programme WHERE
id='2131'");
err = PQresultStatus(res);
if (err == PGRES_BAD_RESPONSE || err == PGRES_NONFATAL_ERROR || err ==
PGRES_FATAL_ERROR)
{
printf("Result failed with %s\n", PQresultErrorMessage(res));
}
printf("%s returned for oid",PQgetvalue(res, 0, 16));
}
oid is at position 16 in the result set, what i'm basically getting is
the oid for the record where id=2131.
The returned value is 3249697. If I run the sql statement into pgsql i
get:
SELECT *,oid FROM programme WHERE id='2131';
id | programmegroupid | name | director | amount
| enrollimit | waitinglistlimit | startdate | enddate |
imembershiplength | membershiplengthtype | concession | programmetype |
history | quickadd | oneoff | oid
--+--+---+-+++--+++---+--++---+-+--++-
2131 |9 | L The Dream Team 9/99 | Ariana Sour | 0
| 0 |0 | 1999-09-20 | 1999-11-01
| 0 |1 | 0 | 2
| f | f| f | 3249697
(1 row)
Which seems fine,
Now this is all what behave should be, but if i insert the exact same
code into my libary at a low level point, ie everytime i do a PQexec, i
get the result 2729675. Everything else seems to work fine execpt this
which is why it took me ages to pick up. Would having serveral
resultsets open at one time effect the oid values?. This could be
something in my libary screwing up, but i dont know. And if it is a bug
it could be hard to replicate, I'll keep working on it to see if i can
find something more definate that always causes it.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] Bug #605: timestamp(timestamp('a timestamp)) no longer works
On Sat, 2002-03-02 at 04:16, Thomas Lockhart wrote:
> > timestamp(timestamp('a timestamp)) no longer works
> > I do this reasonably often in my code by way of being paranoid
> > that I might have a date, or a time, where I for sure _really_
> > want it to be a timestamp...
> > pcnz=# select timestamp('2002-03-01'::timestamp);
> > ERROR: parser: parse error at or near "'"
>
> You *can* coerce timestamps to be timestamps, but in 7.2 non-standard
> syntax no longer works to do this. The reason is that "timestamp(p)" now
> follows the SQL9x usage of defining a timestamp type with precision "p".
> So trying to call a function "timestamp()" no longer works as it did.
>
> You can use SQL9x syntax for the type coersion:
>
> select cast('2002-03-01'::timestamp as timestamp);
>
> or (not recommended) you can cheat and force the call to the function by
> surrounding it in double-quotes:
>
> select "timestamp"('2002-03-01'::timestamp);
Thanks Thomas,
I wasn't aware of that SQL9x timestamp precision, which was why it
seemed like a strange change to me.
Sorry to have not read the migration issues before filing this - I
thought from following these mailing lists that I knew them already :-)
Cheers,
Andrew.
--
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201MOB: +64(21)635-694OFFICE: +64(4)499-2267
Are you enrolled at http://schoolreunions.co.nz/ yet?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] double insert on inherited table with where constraint based on sequence
Perhaps I'm missing something here, but it looks like I'm getting an
insert into both the parent and child tables when my RULE's where
clause is based on a DEFAULT generated from a sequence. It looks like
nextval on the sequence is called 3 times for every insert.
I don't know if this is properly a bug or just un-expected behaviour.
It seems very counter-intuitive since the rule says DO INSTEAD so ISTM
that either one or the other insert should happen.
ahammond=# \d t2
Table "public.t2"
Column | Type |Modifiers
+-+-
id | integer | not null default nextval('t2_id_seq'::regclass)
name | text| not null
Indexes:
"t2_pkey" PRIMARY KEY, btree (id)
"t2_name_key" UNIQUE, btree (name)
"t2_test" btree ((name::integer)) WHERE is_number(name)
Rules:
t2_part AS
ON INSERT TO t2
WHERE new.id > 10 DO INSTEAD INSERT INTO t2_child (id, name)
VALUES (new.id, new.name)
ahammond=# SELECT * FROM t2;
id | name
+---
1 | one
2 | two
3 | three
4 | 4
5 | 5
(5 rows)
ahammond=# CREATE TABLE t2_child (CHECK (id > 10)) INHERITS (t2);
CREATE TABLE
ahammond=# CREATE RULE t2_part AS ON INSERT TO t2 WHERE id > 10 DO
INSTEAD INSERT INTO t2_child VALUES (NEW.id, NEW.name);
CREATE RULE
ahammond=# INSERT INTO t2 (name) VALUES ('six');
INSERT 0 1
ahammond=# INSERT INTO t2 (name) VALUES ('seven');
INSERT 0 1
ahammond=# INSERT INTO t2 (name) VALUES ('eight');
INSERT 0 0
ahammond=# INSERT INTO t2 (name) VALUES ('9');
INSERT 0 0
ahammond=# INSERT INTO t2 (name) VALUES ('ten');
INSERT 0 0
ahammond=# INSERT INTO t2 (name) VALUES ('11');
INSERT 0 0
ahammond=# INSERT INTO t2 (name) VALUES ('12');
INSERT 0 0
ahammond=# SELECT * FROM t2;
id | name
+---
1 | one
2 | two
3 | three
4 | 4
5 | 5
7 | six
10 | seven
12 | seven ?
15 | eight
18 | 9
21 | ten
24 | 11
27 | 12
(13 rows)
ahammond=# SELECT * FROM ONLY t2 ;
id | name
+---
1 | one
2 | two
3 | three
4 | 4
5 | 5
7 | six
10 | seven
(7 rows)
ahammond=# SELECT * FROM t2_child ;
id | name
+---
12 | seven
15 | eight
18 | 9
21 | ten
24 | 11
27 | 12
(6 rows)
Note that the "seven" entry appears twice.
Drew
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in
On 2006-09-03, Bruce Momjian <[EMAIL PROTECTED]> wrote: >> Nice report. The attached patch fixes it, and will be in 8.2. I am not >> backpatching because someone might be relying on this behavior. The bug appears to have been introduced just before the 8.1 betas; since it causes the AM/PM indicator simply to never work except at the end of the string, I see no possible justification for not backpatching the fix. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [BUGS] BUG #2683: spi_exec_query in plperl returns
Tom Lane wrote: > I wrote: >> It looks to me like basically everywhere in plperl.c that does newSVpv() >> should follow it with >> >> #if PERL_BCDVERSION >= 0x5006000L >> if (GetDatabaseEncoding() == PG_UTF8) >> SvUTF8_on(sv); >> #endif > > Experimentation proved that this was insufficient to fix Vitali's > problem --- the string he's unhappy about is actually a hash key entry, > and there's no documented way to mark the second argument of hv_store() > as being a UTF-8 string. Some digging in the Perl source code found > that since at least Perl 5.8.0, hv_fetch and hv_store recognize a > negative key length as meaning a UTF-8 key (ick!!), so I used that hack. > I am not sure there is any reasonable fix available in Perl 5.6.x. > > Attached patch applied to HEAD, but I'm not going to risk back-patching > it without some field testing. > Hmm. That negative pointer hack is mighty ugly. I am also wondering, now that it's been raised, if we need to issue a "use utf8;" in the startup code, so that literals in the code get the right encoding. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2645: pg_restore crashes
I observed this symptom with a 4Mb .backup file (details of commands issued below). The restore always failed at the same rogue table. On going back to the source DB, I experienced trouble on that table: vacuum worked, but vacuum FREEZE hung after which SELECT count(*) hung! In my case, the "workaround" was to stop the source DB server and redo the backup. My (somewhat speculative) conclusion is that there may be a problem with performing hot-backups on a live database. Andrew. BACKUP: pg_dump.exe -i -h localhost -p 5432 -U Administrator -F c -b -v -f "D:\dbname.backup" dbname Windows Server 2003, postgres 8.1.5, pgAdmin3 v1.4.3 RESTORE: Windows XP SP2, postgres 8.1.1 pgAdmin3 v1.4.1: C:\Program Files\PostgreSQL\8.1\bin\pg_restore.exe -i -h localhost -p 5432 -U postgres -d dbname -v "Z:\dbname.backup" - All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: [HACKERS] [BUGS] BUG #2873: Function that returns an empty set
Tom Lane wrote: > This is closely related to the discussion a couple weeks ago about how > a LEFT JOIN could produce nulls in an output column that was labeled as > having a non-null-domain type. We haven't figured out what is a sane > behavior for that case, either. I'm beginning to think that domains > constrained not null are just fundamentally a bad idea. > I think we just expect left joins to produce nulls regardless of constraints on the underlying cols, don't we? Concluding that not null in domains is bad seems a bit drastic. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #3089: View/Table Creation/Ownership Bug
The following bug has been logged online: Bug reference: 3089 Logged by: Andrew White Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.3 Operating system: SuSE Linux 9 Description:View/Table Creation/Ownership Bug Details: To Whom It May Concern, I came across an interesting issue regarding views and ownership that I think may be a bug in PG. I am using PG 8.2.3 on SuSE Linux. In short: The problem I am having is that I can create a table that is owned by one role (role A), then create a view owned by another role (role B) that selects from the table I just created, grant rights to that view to role A and get an error trying to select from it (ERROR: permission denied for relation table_a SQL state: 42501) In long: Here are a set of steps one can take to reproduce what I am seeing 0) Create 2 roles as such: CREATE ROLE view_ownership_test_A NOSUPERUSER NOINHERIT CREATEDB NOCREATEROLE; CREATE ROLE view_ownership_test_B NOSUPERUSER NOINHERIT CREATEDB NOCREATEROLE; 1) Create a user and grant them view_ownership_test_A 2) Create a new database as such: CREATE DATABASE view_ownership_test WITH OWNER = view_ownership_test_A ENCODING = 'UTF8' TABLESPACE = pg_default; GRANT ALL ON DATABASE view_ownership_test TO view_ownership_test_A; GRANT ALL ON DATABASE view_ownership_test TO view_ownership_test_B; 3) Connect to view_ownership_test as SU 4) Create a table, set it's ownership to view_ownership_test_A and fill in some test data as such: create table table_A (mykey serial, myname varchar(50), myage int4); ALTER TABLE table_A OWNER TO view_ownership_test_A; GRANT ALL ON TABLE table_A TO view_ownership_test_A; insert into table_A (myname, myage) select 'Homer Simpson', 42; insert into table_A (myname, myage) select 'Peter Griffin', 43; insert into table_A (myname, myage) select 'Phillip J. Fry', 27; 5) Create a view selecting from that table as such: CREATE OR REPLACE VIEW lkup_table_A AS SELECT * FROM ONLY table_A; 6) Set ownership of this view and rights as such: ALTER TABLE lkup_table_A OWNER TO view_ownership_test_B; GRANT SELECT, UPDATE, INSERT, DELETE, REFERENCES, TRIGGER ON TABLE lkup_table_A TO view_ownership_test_B; GRANT SELECT, UPDATE, INSERT, DELETE ON TABLE lkup_table_A TO view_ownership_test_A; 7) Connect to view_ownership_test as connect as someone in group view_ownership_test_A 8) Test selecting from the table created in step 4: select * from table_A; --Notice it succeeds as expected 9) Test selecting from the view created in step 5: select * from lkup_table_A; --(ERROR: permission denied for relation table_a SQL state: 42501) --Notice it fails despite that fact that by being in the role of view_ownership_test_A you own the table, have full rights to the table and have full rights to the view What I think is happening: It appears that PG allows you to create a view selecting from a table you do not have rights to. When someone who does have rights to both the table and your view uses the view it fails. I am not sure if the creation of the view should not be allowed (or warned) or if the person selecting from it should be where in the program the rights are evaluated but the current way seems to be a bug to me. Thanks, Andrew White ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #3092: character varying and integer cannot be matched
The following bug has been logged online: Bug reference: 3092 Logged by: Andrew Rass Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.3 Operating system: FreeBSD 6.2 Description:character varying and integer cannot be matched Details: Hello the following problem has occured, SELECT T055.MESOPRIM,T051.MESOPRIM FROM T055 T055,T051 T051 WHERE T055.MESOYEAR = 1278 AND T055.MESOCOMP = '1ZAP' AND T051.MESOYEAR = 1278 AND T051.MESOCOMP = '1ZAP' AND ( T055.C002 = T051.C001 AND T055.C004 IN (2,3) AND lower(t051.c052) LIKE '%frankfurt%' )ORDER BY T055.C002 ERROR: IN types character varying and integer cannot be matched SQL Status:42804 mesoprim character varying(34); mesoyear integer; mesocomp character varying(4); c002 character varying(20); c001 character varying(20); postgresql 7.4.7 did this and now it did this problem like describe thank you ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Re: [BUGS] BUG #3242: FATAL: could not unlock semaphore: error code 298
Magnus Hagander wrote: The effective max count on Unixen is typically in the thousands, and I'd suggest the same on Windows unless there's some efficiency reason to keep it small (in which case, maybe ten would do). AFAIK there's no problem with huge numbers (it takes an int32, and the documentation says nothing about a limit - I'm sure it's just a 32-bit counter in the kernel). I'll give that a shot. Linux manpage suggests local max is 32767, so that's probably a good value to try. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Problem With Case Statement and Aggregate Functions
The following works as expected: select (SELECT CASE WHEN (1=2) THEN 0 ELSE sum(count) END) from ( select 1 as count union select 2 union select 3 ) as "temp"; The result is "6". The following also works as expected: select count(*) from ( select 1 as count union select 2 union select 3 ) as "temp"; The results is "3". However the following code doesn't work even though it is very similar to the first query (that is, and aggregate function within a case statement): select (SELECT CASE WHEN (1=2) THEN 0 ELSE COUNT(*) END) from ( select 1 as count union select 2 union select 3 ) as "temp"; The result is three rows of "1". So why does the "count" aggregate function within a case statement execute on a per row basis whereas the "sum" aggregate within a case statement will first group the rows? ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] strange problem with ip6
On Mon, May 14, 2007 at 08:32:21PM -0600, Brian Hirt wrote: > I have postgresql installed on a mac, and I'm connecting from another > mac on the network using ip6. When I try to select out of > pg_stat_activity i get this error. I suspect the %en0 has something > to do with the problem, but I'm no IP6 expert. That would indeed be a problem. "%" is not a valid character in an IPv6 text representation of the address (see RFC 4291, <http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=4291&type=ftp&file_format=txt>). Whether this is a bug for postgres seems to depend on whether that reading is coming from the OS or postgres itself. (I don't know the answer to that.) A -- Andrew Sullivan | [EMAIL PROTECTED] In the future this spectacle of the middle classes shocking the avant- garde will probably become the textbook definition of Postmodernism. --Brad Holland ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] strange problem with ip6
On Thu, May 17, 2007 at 06:42:39PM +0200, Christian Kratzer wrote: > of a specific interface. This is why bsd based oprating systems append > %ifname to the address so that they know which Interface this address Oh, I forgot about that wart in RFC4007. Thanks for the cluestick. > There is propbaly not much point in using link local addreses for postgres. I think that's not quite right. For instance, JDBC can't use UNIX domain sockets last I checked, and I can imagine using it in a disconnected context where you'd want to emulate multiple connection points. Link local addresses would be perfect for this. So I think it might be a bug, because Postgres isn't accepting the address specification for scoped addresses. (In the local 8.1.x version I have installed here, the inet type doesn't accept it either.) Now that I re-read it, RFC4007 seems to be pretty clear that the scope info is a necessary part of the addressing, so I don't think it can be thrown away before looking at the address. A -- Andrew Sullivan | [EMAIL PROTECTED] I remember when computers were frustrating because they *did* exactly what you told them to. That actually seems sort of quaint now. --J.D. Baldwin ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] strange problem with ip6
On Thu, May 17, 2007 at 07:29:47PM +0200, Christian Kratzer wrote: > supporting scoped addresses could have their uses but then again > theres nothing stopping you to bind multiple global ipv6 addresses > to your loopback interface which would work fine for disconnected > setups and it might be a bit cleaner. True, but there's no unscoped private-use address space in IPv6 the way there is in v4 (i.e. no 1918-style addresses for v6). Which means that unless you want to use addresses that ought to be scoped (like link-local) without a scope, you have to use real addresses instead. Hmm. Well, I guess you could use 2001:DB8::/32, which is reserved for documentation. I'm just worried that, because we don't support scoped addresses, people are going to configure things with _real_ addresses they haven't been allocated, and then accidentally connect such a configuration to the Internet. All my experience tells me that such things eventually always leak, and I'd hate for Postgres to be the source of that sort of damage. A -- Andrew Sullivan | [EMAIL PROTECTED] The whole tendency of modern prose is away from concreteness. --George Orwell ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
