[BUGS] BUG #6318: pg_dump for non-template languages is broken

[laurenz . albe]

The following bug has been logged on the website:

Bug reference:  6318
Logged by:  Laurenz Albe
Email address:  laurenz.a...@wien.gv.at
PostgreSQL version: 9.1.1
Operating system:   Linux (RHEL 3)
Description:

How to reproduce:

postgres=# CREATE DATABASE dumpme;
postgres=# \c dumpme postgres
dumpme=# CREATE LANGUAGE mylang HANDLER plpgsql_call_handler INLINE
plpgsql_inline_handler VALIDATOR plpgsql_validator;
dumpme=# \q

$ pg_dump -C -F p -f dumpme.sql dumpme

$ psql -c 'DROP DATABASE dumpme'

$ psql -f dumpme.sql
[...]
psql:dumpme.sql:32: ERROR:  unsupported language "mylang"
HINT:  The supported languages are listed in the pg_pltemplate system
catalog.
psql:dumpme.sql:35: ERROR:  language "mylang" does not exist
[...]

The reason is that the dump contains:

--
-- Name: mylang; Type: PROCEDURAL LANGUAGE; Schema: -; Owner: advpg
--

CREATE OR REPLACE PROCEDURAL LANGUAGE mylang;


ALTER PROCEDURAL LANGUAGE mylang OWNER TO advpg;

Yours,
Laurenz Albe


-- 
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 #6308: Problem w. encoding in client

[Thomas Goerner]

Hello Craig,

 

it seems as if there were illegal chars in the originally dumped database,
so the dump/restore problem might be due to this. At the moment we are doing
further investigation on this issue. 

 

But the problem regarding message output from the client applications still
persists. We are now setting up another set of 32/64-bit (virtual) Windows 7
machines to verify that the problem occurs only on 64 bit windows.

 

I will keep you informed.

 

 

Regards

Thomas

 

 

===
click:ware Informationstechnik GmbH
Thomas Goerner
Geschäftsführer
fon: 0221 - 13 99 88-0
fax: 0221 - 13 99 88-79
Kamekestraße 19
50672 Köln
  t...@clickware.de
  www.clickware.de
===
Kennen Sie schon unser GasDataWarehouse - 
Die kostengünstige Lösung für den Austausch 
von Gasmessdaten?
  www.gasdatawarehouse.de

  _  

Von: Craig Ringer [mailto:ring...@ringerc.id.au] 
Gesendet: Dienstag, 29. November 2011 03:33
An: Thomas Goerner
Cc: pgsql-bugs@postgresql.org
Betreff: Re: [BUGS] BUG #6308: Problem w. encoding in client

 

On 11/28/2011 08:26 PM, Thomas Goerner wrote: 

Hello Craig,

 

thanks for your answer.

 

 

> Restore using PgAdmin III or using a unicode console. 

> This is a limitation of using a Win1252 client encoding when restoring 

> data that isn't restricted to Win1252 and cannot be fixed directly.

 

That's new to me. AFAIK pg_restore looks into the dump file and sets the
client encoding accordingly (In fact the dump contains the statement SET
client_encoding = 'UTF8';). Is this overridden by PGCLIENTENCODING? And if
so, should it be?


Nope, pg_restore should be using UTF8 as the client encoding in that case.
If there are any errors or notices it won't be able to emit them correctly
on the terminal though, as win1252 can't represent everything in UTF8 (and
IIRC pg_restore doesn't recode from client_encoding to terminal encoding
anyway).

If the restore its self is failing then I agree that something's not working
properly, because you should be able to use a client_encoding different to
your terminal encoding. I wonder if recent changes intended to get psql to
pick up the terminal encoding automatically have had the unintended
side-effect of overriding pg_restore's attempt to set the client_encoding?

I'm rather surprised you only see this on x64. You're using the same Windows
and Pg version for both x64 and x64 but only the x64 test fails?

--
Craig Ringer

[BUGS] BUG #6317: sequence error for pg_dump

[hmf]

The following bug has been logged on the website:

Bug reference:  6317
Logged by:  hua ming fei 
Email address:  h...@alkheme.com
PostgreSQL version: 9.0.1
Operating system:   Centos 5.5
Description:

use pg_dump when didn't close the application , weird things occured . the
current value of one sequence is more slower than the max number of one
primary key base on the sequence . So, I looked into the dump file , found
command"
SELECT pg_catalog.setval('attrnamemaster_attrnameid_seq', 3009, 
true);" to
set sequence values number , but the import data, there are many lines with
number larger than the sequence value :
301238  2147483647  t   10041   materialmaterial
   material1004.10041  4.1 f
301338  2147483647  t   10042   disable 
   1004.10042  4.2 f 


-- 
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] 9.1.1 hot standby startup gets sigbus

[Josh Kupershmidt]

[Moving back on-list. Tom generously offered to look at the server in
question, since it seemed likely that a testcase would be difficult or
impossible to reproduce in this case]

On Fri, Dec 2, 2011 at 12:07 AM, Tom Lane  wrote:
>
> Well, poking around in the process at the moment of SIGBUS, I find that
> it's computed a buffer address of
>
>        (gdb) p bufBlock
>        $12 = (Block) 0xb6c49060
>
> which appears to be perfectly reasonable: it's working with buffer
> header number 15514 and that's equal to BufferBlocks + (15514 * 8192).
> However, trying to dump that 8K area out stops before it gets to the
> end:
>
>        0xb6c4afc0:     0       0       0       0
>        0xb6c4afd0:     0       0       0       0
>        0xb6c4afe0:     0       0       0       0
>        0xb6c4aff0:     0       0       0       0
>        0xb6c4b000:     Cannot access memory at address 0xb6c4b000
>
>        (gdb) p 0xb6c4b000 - 0xb6c49060
>        $13 = 8096
>
> that is, there isn't any memory mapped beyond 0xb6c4b000, which is why
> we're getting SIGBUS.  So a significant fraction of the intended shared
> buffer array (16384 buffers) simply Ain't There.  The reason it crashes
> at this exact spot seems to be simply that this is where we've used up
> enough of the buffers to need one that's not (all) there.
>
> So the question is, has Postgres gone nuts about how big it needs its
> shared memory to be?  I don't think so.  Looking into the memory map
> for the process, we've got
>
> postgres@S04001011820ASA:~$ cat /proc/11187/maps
> 0011-00112000 r-xp  fd:04 412754092                          
> /lib/i386-linux-gnu/libdl-2.13.so
> 00112000-00113000 r--p 1000 fd:04 412754092                          
> /lib/i386-linux-gnu/libdl-2.13.so
> 00113000-00114000 rw-p 2000 fd:04 412754092                          
> /lib/i386-linux-gnu/libdl-2.13.so
> 00247000-0026b000 r-xp  fd:04 412754075                          
> /lib/i386-linux-gnu/libm-2.13.so
> 0026b000-0026c000 r--p 00023000 fd:04 412754075                          
> /lib/i386-linux-gnu/libm-2.13.so
> 0026c000-0026d000 rw-p 00024000 fd:04 412754075                          
> /lib/i386-linux-gnu/libm-2.13.so
> 0026d000-003c7000 r-xp  fd:04 412754120                          
> /lib/i386-linux-gnu/libc-2.13.so
> 003c7000-003c8000 ---p 0015a000 fd:04 412754120                          
> /lib/i386-linux-gnu/libc-2.13.so
> 003c8000-003ca000 r--p 0015a000 fd:04 412754120                          
> /lib/i386-linux-gnu/libc-2.13.so
> 003ca000-003cb000 rw-p 0015c000 fd:04 412754120                          
> /lib/i386-linux-gnu/libc-2.13.so
> 003cb000-003ce000 rw-p  00:00 0
> 00611000-0062d000 r-xp  fd:04 412754069                          
> /lib/i386-linux-gnu/ld-2.13.so
> 0062d000-0062e000 r--p 0001b000 fd:04 412754069                          
> /lib/i386-linux-gnu/ld-2.13.so
> 0062e000-0062f000 rw-p 0001c000 fd:04 412754069                          
> /lib/i386-linux-gnu/ld-2.13.so
> 00995000-0099f000 r-xp  fd:04 412754174                          
> /lib/i386-linux-gnu/libnss_files-2.13.so
> 0099f000-009a r--p 9000 fd:04 412754174                          
> /lib/i386-linux-gnu/libnss_files-2.13.so
> 009a-009a1000 rw-p a000 fd:04 412754174                          
> /lib/i386-linux-gnu/libnss_files-2.13.so
> 00e57000-00e58000 r-xp  00:00 0                                  
> [vdso]
> 08048000-08548000 r-xp  fd:04 419563409                          
> /home/postgres/runtime/bin/postgres
> 08548000-08549000 r--p 004ff000 fd:04 419563409                          
> /home/postgres/runtime/bin/postgres
> 08549000-08551000 rw-p 0050 fd:04 419563409                          
> /home/postgres/runtime/bin/postgres
> 08551000-08591000 rw-p  00:00 0
> 08c03000-08c5d000 rw-p  00:00 0                                  
> [heap]
> aed2f000-b7503000 rw-s  91:8f 1212416
> b7503000-b7703000 r--p  fd:04 412486363                          
> /usr/lib/locale/locale-archive
> b7703000-b7705000 rw-p  00:00 0
> b7709000-b770a000 r--p 002dd000 fd:04 412486363                          
> /usr/lib/locale/locale-archive
> b770a000-b770c000 rw-p  00:00 0
> bff75000-bff97000 rw-p  00:00 0                                  
> [stack]
> postgres@S04001011820ASA:~$
>
> ie, there's alleged to be shared memory from 0xaed2f000 up to
> 0xb7503000, and that squares exactly with where PG thinks its
> shared memory is:
>
> (gdb) p UsedShmemSegAddr
> $34 = (void *) 0xaed2f000
> (gdb) p *(PGShmemHeader *) UsedShmemSegAddr
> $35 = {magic = 679834894, creatorPID = 11185, totalsize = 142426112, 
> freeoffset = 142125504, index = 0xaedafb48,
>  device = 37259, inode = 414974343}
> (gdb) p 0xb7503000 - 0xaed2f000
> $36 = 142426112
> (gdb)
>
> So basically, you've got a broken kernel here: it claimed to give PG
> circa 135MB of memory, but what's actually there i

Re: [BUGS] BUG #6314: The like command does not handle a long string of special chars

[Magnus Hagander]

On Thursday, December 1, 2011, Tom Lane wrote:

> d.reri...@healthcareoss.com  writes:
> > Simply set a varchar field in your db to the following string:
> > !"#$%'()*+,-/:;=?@[\]^_`{|}~&<>
>
> > I know, I know, who would do this, right? Well, its for a certification.
> > The like command works fine up with escapes up to:
> > !"#$%''()*+,-/:;=?@[%
>
> Doesn't match for me, rather unsurprisingly since this string contains
> two occurrences of "'" not one.
>
> > Notice, I added the % to the end. However, if you go any further - no
> > matches:
> > !"#$%''()*+,-/:;=?@[\\%
> > Strangely, this works and shouldn't:
> > !"#$%''()*+,-/:;=?@[\%
>
> It's hard to tell for sure, since you've presented a garbled
> interpretation of what you did rather than showing us exactly what you
>

A fair amount of that garbling is unfortunately the fault of a bug in the
new website code that applied HTML escapes to plaintext emails, which in
the end caused double escaping. I've just pushed a fix for this, so from
now on bugreports won't do that.




-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

Re: [BUGS] BUG #6318: pg_dump for non-template languages is broken

[Tom Lane]

laurenz.a...@wien.gv.at writes:
> dumpme=# CREATE LANGUAGE mylang HANDLER plpgsql_call_handler INLINE
> plpgsql_inline_handler VALIDATOR plpgsql_validator;

I don't think this is a particularly interesting use-case.  The reason
it doesn't work for you is that it's depending on support functions
that are in pg_catalog, and as the comment in pg_dump.c says:

/*
 * Try to find the support function(s).  It is not an error if we don't
 * find them --- if the functions are in the pg_catalog schema, as is
 * standard in 8.1 and up, then we won't have loaded them. (In this case
 * we will emit a parameterless CREATE LANGUAGE command, which will
 * require PL template knowledge in the backend to reload.)
 */

An actual add-on procedural language would not fall foul of this.

regards, tom lane

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs