Re: [BUGS] pg_dump or hardware?
Thanks for the quick reply
Tom Lane wrote:
andrea suisani <[EMAIL PROTECTED]> writes:
[cut]
Hmm ... what do you get from
select oid from pg_class where relname = 'nominativi';
oid
561644
(1 row)
afaics it seems weird does this mean that another postgresql
object screw up? this is the "\d nominativi" output:
Table "public.nominativi"
Column | Type | Modifiers
+--+---
nome_cogno | character(70)|
indirizzo | character(40)|
cap| character(5) |
citta | character(35)|
prov | character(2) |
prefisso | character(4) |
telefono1 | character(13)|
telefono2 | character(13)|
note | character(100) |
idpersona | integer |
estrazione | date |
num_estra | integer |
occupato | boolean |
cod_prov | integer |
cod_com| integer |
cod_reg| integer |
capoluo| integer |
rand | double precision |
Indexes:
"citta1_idx" btree (prov, citta) WHERE (((prov = 'BL'::bpchar) OR (prov =
'PD'::bpchar) OR (prov = 'RO'::bpchar) OR (prov = 'VE'::bpchar) OR (prov = 'TV'::bpchar)
OR (prov = 'VR'::bpchar)) AND (cod_com IS NULL))
"cod_com_ndx1" btree (cod_com)
"codprov_capo_rand1" btree (cod_prov, capoluo, rand)
"pre_tel_index1" btree (prefisso, telefono1)
and none of nominativi's indexes has an oid like 201327173
select oid
from pg_class
where relname in
('citta1_idx','cod_com_ndx1','codprov_capo_rand1','pre_tel_index1');
oid
--
46788374
40916657
40916656
40916658
(4 rows)
select relname from pg_class where oid = 201327173;
relname
-
(0 rows)
while if I "ask" for oid 561644 this is what I get:
select relname from pg_class where oid = 561644;
relname
nominativi
(1 row)
If the first returns 201327173 while the second doesn't return anything,
then I'd wonder about corruption of pg_class's OID index. REINDEXing it
might help.
I don't remember whether 7.4 makes you use a standalone
backend to reindex system catalogs --- see its REINDEX man page for
details.
from what I can see from REINDEX man page, I can reindex shared system catalogs
in stand-alone mode
[cut]
Regards,
Andrea
---(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 #2401: spinlocks not available on amd64
Theo Schlossnagle wrote: > >> Compiling 8.1.3 on solaris 10 x86 with Sun Studio 11 for amd64 target > >> architecture leads us to an error resulting from no available "tas" > >> assembly. > >> > >> The tas.s file doesn't look like valid assembly for the shipped Sun > >> assembler. > > > > Yes. We will have a fix for it in 8.2, but it was too risky for > > 8.1.X. > > You can try a snapshot tarball from our FTP server and see if that > > works. > > I reviewed the code there. I think it can be better. The issue is > that s_lock chooses to implement the lock in an unsigned char which > isn't optimal on sparc or x86. An over arching issue is that the tas > instruction is a less functional cas function, so it seems that the > tas should be cas and the spinlocks should be implemented that way. > By using cas, you can can actually know the locker by cas'ing the > lock to the process id instead of 1 -- we use that trick to see who > is holding the spinlock between threads (we obviously use thread ids > in that case). Great. > So... I changed the s_lock.h to merge the sparc and x86 sections thusly: > > - > #if defined(__sun) && (defined(__i386) || defined(__amd64) || defined > (__sparc) | > | defined(__sparc__)) > /* > * Solaris/386 (we only get here for non-gcc case) > */ > #define HAS_TEST_AND_SET > typedef unsigned int slock_t; > > extern volatile slock_t > pg_atomic_cas(volatile slock_t *lock, slock_t with, slock_t cmp); > > #define TAS(a) (pg_atomic_cas((a), 1, 0) != 0) > > #endif > - > > And then replaced solaris_sparc.s and solaris_i386.s (BTW there is no > reason to have these files seprately as you can #ifdef them correctly > in the assembly -- I didn't do that as I didn't want to disturb the > make system). OK, this is a great help. If you think it should be just one file we can do that, but since the are separate instructions sets, separate files I think still makes sense. No one at Sun is helping us (after repeated requests), so we do need someone to help clear up this mess and improve it. Let me merge in what you have done and I will let you know when you can test another snapshot. --- > solaris_sparc.s > - > / > > = > / tas.s -- compare and swap for solaris_sparc > / > > = > > #if defined(__sparcv9) || defined(__sparc) > > .section".text" > .align 8 > .skip 24 > .align 4 > > .global pg_atomic_cas > pg_atomic_cas: > cas [%o0],%o2,%o1 > mov %o1,%o0 > retl > nop > .type pg_atomic_cas,2 > .size pg_atomic_cas,(.-pg_atomic_cas) > #endif > - > > solaris_i386.s > - > / > > = > / tas.s -- compare and swap for solaris_i386 > / > > = > > .file "tas.s" > > #if defined(__amd64) > .code64 > #endif > > .globl pg_atomic_cas > .type pg_atomic_cas, @function > > .section .text, "ax" > .align 16 > pg_atomic_cas: > #if defined(__amd64) > movl %edx,%eax > lock > cmpxchgl %esi,(%rdi) > #else > movl4(%esp), %edx > movl8(%esp), %ecx > movl12(%esp), %eax > lock > cmpxchgl %ecx, (%edx) > #endif > ret > .size pg_atomic_cas, . - pg_atomic_cas > - > > > // Theo Schlossnagle > // CTO -- http://www.omniti.com/~jesus/ > // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ > // Ecelerity: Run with it. > > -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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
Re: [BUGS] PGSTAT: bind(2): Can't assign requested address
Bjoern A. Zeeb wrote:
> On Fri, 7 Jun 2002, Bruce Momjian wrote:
>
> Hi,
>
> it's been some months so I left the fullquote attached.
>
> > Well, you are the first to report that 127.0.0.1 doesn't work for stats.
> > Unless someone else has a problem, I think we will leave it unchanged.
>
>
> The last years this problem was disucced several times (mostly on
> FreeBSD lists) for the reason of FreeBSD jails. I thought that we
> had another mail in 2002 about that but couldn't find it anymore.
>
> Anyway binding to 127.0.0.1 in a jail binds to the (usually public) IP
> address of that jail which means the stats socket is basically open to
> world (from the socket point of view).
Yes, but we need an interface that will drop packets on heavy load, and
a local IP is the only way we know to do that.
> Another problem (which is not a postgresql problem per se) is that if
> the system is built without inet6 support or does not support inet6
> (as in jails) but there is a ::1 localhost in /etc/hosts the error
> messages gives a warning like:
> could not create socket for statistics collector:
> Protocol not supported
> which sound annoying in first places until you find out that it worked
> anyway and remember what cuases the warning.
Yes, that is confusing. The following patch adds a message after the
error:
trying another address for the statistics collector
which should help reduce confusion. It will appear in 8.2.
> Is there any reason why you explicitly disallow a posix local socket
> at that point in backend/postmaster/pgstat.c:pgstat_init:
>
> ...
> for (addr = addrs; addr; addr = addr->ai_next)
> {
> #ifdef HAVE_UNIX_SOCKETS
> /* Ignore AF_UNIX sockets, if any are returned. */
> if (addr->ai_family == AF_UNIX)
> continue;
> #endif
> ...
>
>
> Couldn't you use/allow (if possible or configured) a posix local socket
> or even use pipes for that?
Yes, because it can't drop packets, I think.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/postmaster/pgstat.c
===
RCS file: /cvsroot/pgsql/src/backend/postmaster/pgstat.c,v
retrieving revision 1.122
diff -c -c -r1.122 pgstat.c
*** src/backend/postmaster/pgstat.c 6 Apr 2006 20:38:00 - 1.122
--- src/backend/postmaster/pgstat.c 20 Apr 2006 10:43:16 -
***
*** 216,222
struct timeval tv;
chartest_byte;
int sel_res;
!
#define TESTBYTEVAL ((char) 199)
/*
--- 216,223
struct timeval tv;
chartest_byte;
int sel_res;
! int tries = 0;
!
#define TESTBYTEVAL ((char) 199)
/*
***
*** 276,281
--- 277,286
continue;
#endif
+ if (++tries > 1)
+ ereport(LOG,
+ (errmsg("trying another address for the
statistics collector")));
+
/*
* Create the socket.
*/
---(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] NLS vs error processing, again
Peter Eisentraut wrote: > Tom Lane wrote: > > I'm far from an expert on this, but the gettext documentation > > indicates that it tries to translate the .po file contents into > > whatever encoding is implied by LC_CTYPE. > > Correct. That is just one more reason to have server encoding, > LC_COLLATE, and LC_CTYPE matching. In practice, there is hardly a > reason to have LC_COLLATE and LC_CTYPE be different, so the problem > should not be that big. Is there any TODO here? -- Bruce Momjian http://candle.pha.pa.us EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2400: 'Ã' considered invalid UTF-8 character
Am Mittwoch, 19. April 2006 01:34 schrieb Yusuf Siddiqui: > The character 'Ã' is rejected as an invalid UTF-8 character. Please show the output of $ psql -c 'show client_encoding' $ locale -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2401: spinlocks not available on amd64
Bruce Momjian writes: > OK, this is a great help. If you think it should be just one file we > can do that, but since the are separate instructions sets, separate > files I think still makes sense. There is no reason for the i386 or AMD64 code to be different from what's already tested on Linux --- the hardware's the same and the OS surely doesn't make a difference at this level. Does Solaris' assembler really support C-style "#if defined()" constructs in .s files? That seems moderately unlikely. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] set up on flash drive
On Tue, Apr 11, 2006 at 09:04:49AM -0700, Richard Dunne wrote: > I have installed PostGreSql on a flash memory drive. How do I start the > shell command? Uhm... psql? -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
