Re: [HACKERS] 2-phase commit
Here is a sourceforge version of the same thing http://openorb.sourceforge.net/ > -Original Message- > From: Dann Corbit > Sent: Friday, October 10, 2003 9:38 PM > To: Christopher Browne; [EMAIL PROTECTED] > Subject: Re: [HACKERS] 2-phase commit > > > Why not apply the effort to something already done and > compatibly licensed? > > This: > http://dog.intalio.com/ots.html > > Appears to be a Berkeley style licensed: > http://dog.intalio.com/license.html > > Transaction monitor. > > "Overview > The OpenORB Transaction Service is a very scalable > transaction monitor which also provides several extensions > like XA management, a management interface to control all > transaction processes and a high reliable recovery system. > > By coordinating OpenORB and OpenORB Transaction Service, you > provide a reliable and powerful foundation for building large > scalable distributed applications. > > Datasheet > The OpenORB Transaction Service is a fully compliant > implementation of the OMG Transaction Service specification. > The OpenORB Transaction Service features are : > Management of distributed transactions with a two phase > commit protocol > Sub Transactions management ( nested transactions ) > Propagation of the transaction context between CORBA objects > Management of distributed transactions propagation through > databases with the XA protocol > Automatic logs to be able to make recovery in case of failures > Can be used as a transaction initiator or subordinate > High-performance, multiple thread architecture > Developed with POA > Provides a management interface to control all transactions > Full support of JTA > JDBC pooling and automatic resource enlistment > > > Download > To download the OpenORB Transaction Service, do one of the > following : > CVS : you can use CVS to grab the sources directly. > FTP : you get either a CVS snapshot or a prebuilt version > To use one of these possibilities, go to the Download Services page. > > ChangeLog > August 15th 2001. Version 1.2.0. > Changed the transaction client side to support late binding > to the transaction monitor. > Bug fixed in the transactional client interceptor. This bug > was due to a change in the OpenORB behavior concerning the slot > > > To get previous change log, please refer to the CHANGELOG > file available within this service distribution." > > ---(end of > broadcast)--- > TIP 5: Have you checked our extensive FAQ? > http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 2-phase commit
Why not apply the effort to something already done and compatibly licensed? This: http://dog.intalio.com/ots.html Appears to be a Berkeley style licensed: http://dog.intalio.com/license.html Transaction monitor. "Overview The OpenORB Transaction Service is a very scalable transaction monitor which also provides several extensions like XA management, a management interface to control all transaction processes and a high reliable recovery system. By coordinating OpenORB and OpenORB Transaction Service, you provide a reliable and powerful foundation for building large scalable distributed applications. Datasheet The OpenORB Transaction Service is a fully compliant implementation of the OMG Transaction Service specification. The OpenORB Transaction Service features are : Management of distributed transactions with a two phase commit protocol Sub Transactions management ( nested transactions ) Propagation of the transaction context between CORBA objects Management of distributed transactions propagation through databases with the XA protocol Automatic logs to be able to make recovery in case of failures Can be used as a transaction initiator or subordinate High-performance, multiple thread architecture Developed with POA Provides a management interface to control all transactions Full support of JTA JDBC pooling and automatic resource enlistment Download To download the OpenORB Transaction Service, do one of the following : CVS : you can use CVS to grab the sources directly. FTP : you get either a CVS snapshot or a prebuilt version To use one of these possibilities, go to the Download Services page. ChangeLog August 15th 2001. Version 1.2.0. Changed the transaction client side to support late binding to the transaction monitor. Bug fixed in the transactional client interceptor. This bug was due to a change in the OpenORB behavior concerning the slot To get previous change log, please refer to the CHANGELOG file available within this service distribution." ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 2-phase commit
Martha Stewart called it a Good Thing [EMAIL PROTECTED] ("Dann Corbit")wrote:
>> I can't see a grave overhead from this comparison.
>
> 2PC is absolutely essential when you have to have both parts of the
> transaction complete for a logical unit of work. For a project that
> needs it, if you don't have it you will be forced to go to another
> tool, or perform lots of custom programming to work around it.
>
> If you have 2PC and it is ten times slower than without it, you will
> still need it for projects requiring that capability.
Just so.
I would be completely unsurprised if an attempt to use 2PC to support
generalized "multimaster replication" would involve 10-fold slowdowns
as compared to having all the activity take place on one database.
Which would imply that 2PC is not a tool that may be appropriately
used to naively do replication. But that should not come as any grand
surprise.
To each tool the right job, and to each job the right tool...
There seems to be enough room for there to be evidence both of 2PC
being useful for improving performance, and for it to cut
performance:
- TPC benchmarks often specify the inclusion of Tuxedo as a
component; the combination of vendors would surely NOT put it
on the list if it were not an aid to performance;
- There is also indication that there can be a cost, notably in the
form of the concerns of deadlock, but it should also be obvious
that slow network links would lead to _hideous_ increases in
latency.
As you say, even if there is a substantial cost, it's still worthwhile
if a project needs it.
> Now, a good model to start with is a very good idea. So some
> discussion and analysis is a good thing. From the looks of it,
> Satoshi Nagayasu has done a very good job. Having a functional 2PC
> would be a huge feather in the cap of PostgreSQL.
It would seem so. I look forward to seeing how this progresses.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://cbbrowne.com/info/linuxdistributions.html
"XFS might (or might not) come out before the year 3000. As far as
kernel patches go, SGI are brilliant. As far as graphics, especially
OpenGL, go, SGI is untouchable. As far as filing systems go, a
concussed doormouse in a tarpit would move faster." -- jd on Slashdot
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[HACKERS] pg_ctl reload - is it safe?
Env: Postgres 7.3.4 on Unix I have a script to create a new database user and update pg_hba.conf. I was wondering whether I need to restart server, or simply run pg_ctl reload. The question is what happens to all active clients when all backends get the signal. I ran such client process which was very busy querying and updating database. At the same time I kept executing "pg_ctl reload". Soon after client reported database error. Here's the excerpt from the database log: ... ... 2003-10-10 22:33:12 LOG: Received SIGHUP, reloading configuration files <25 successful SIGHUPs, about 2 seconds apart from each other> ... ... 2003-10-10 22:37:05 ERROR: cannot read block 0 of s_noteimportlinks: Interrupted system call ... >From the client log I see that problem occured while trying to SELECT nextval from sequence s_noteimportlinks We are going to pass this script to the customers and we have to know what to recommend: reload or shut down/restart. I hope they won't do reload 25 times... but they may have 25 or more active client processes at any time. Thanks in advance, Mike. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 2-phase commit
> -Original Message- > From: Satoshi Nagayasu [mailto:[EMAIL PROTECTED] > Sent: Friday, October 10, 2003 12:26 PM > To: Andrew Sullivan > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] 2-phase commit > > Andrew Sullivan <[EMAIL PROTECTED]> wrote: > > On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote: > > > Satoshi, the only guy who made a trial implementation of 2PC for > > > PostgreSQL, has already showed that 2PC is not that slow. > > > > If someone has a fast implementation, so much the better. I'm not > > opposed to fast implementations! > > The pgbench results of my experimental 2PC implementation > and plain postgresql are available. > > PostgreSQL 7.3 > http://snaga.org/pgsql/pgbench/pgbench-REL7_3.log > > Experimental 2PC in PostgreSQL 7.3 > http://snaga.org/pgsql/pgbench/pgbench-TPC0_0_2.log > > I can't see a grave overhead from this comparison. 2PC is absolutely essential when you have to have both parts of the transaction complete for a logical unit of work. For a project that needs it, if you don't have it you will be forced to go to another tool, or perform lots of custom programming to work around it. If you have 2PC and it is ten times slower than without it, you will still need it for projects requiring that capability. Now, a good model to start with is a very good idea. So some discussion and analysis is a good thing. From the looks of it, Satoshi Nagayasu has done a very good job. Having a functional 2PC would be a huge feather in the cap of PostgreSQL. IMO-YMMV ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Foreign Key bug -- 7.4b4
May have posted this earlier... It would seem that caching the plans for foreign keys has some unwanted side effects. test=# select version(); version PostgreSQL 7.4beta4 on i386-portbld-freebsd4.8, compiled by GCC 2.95.4 (1 row) test=# test=# create table a (col integer primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "a_pkey" for table "a" CREATE TABLE test=# test=# create table b (col integer primary key references a on update cascade on delete cascade); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "b_pkey" for table "b" CREATE TABLE test=# test=# test=# insert into a values (1); INSERT 687978 1 test=# insert into b values (1); INSERT 687979 1 test=# test=# insert into a values (2); INSERT 687980 1 test=# insert into b values (2); INSERT 687981 1 test=# test=# delete from a where col = 1; DELETE 1 test=# test=# alter table b drop constraint b_pkey; ALTER TABLE test=# test=# delete from a where col = 2; ERROR: could not open relation with OID 687972 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] compile warning
Andrew Dunstan wrote:
Bruce Momjian wrote:
This seems to be a bug in gcc-3.3.1. -fstrict-aliasing is enabled by
-O2 or higher optimization in gcc 3.3.1.
According to the C standard, it's illegal to access a data with a
pointer of the wrong type. The only exception is "char *".
This can be used by compilers to pipeline loops, or to reorder instructions.
For example
void dummy(double *out, int *in, int len)
{
int j;
for (j=0;j
Can be pipelined if a compiler relies on strict aliasing: it's
guaranteed that writing to out[5] won't overwrite in[6].
I think MemSet violates strict aliasing: it writes to the given address
with (int32*). gcc might move the instructions around.
I would disable strict aliasing with -fno-strict-aliasing.
In the Linux kernel, you can see this in include/linux/tcp.h:
/*
* The union cast uses a gcc extension to avoid aliasing problems
* (union is compatible to any of its members)
* This means this part of the code is -fstrict-aliasing safe now.
*/
The kernel is still compiled with -fno-strict-aliasing - I'm not sure if
there are outstanding problems, or if it's just a safety precaution.
--
Manfred
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [Fwd: [Python-Dev] HP Test Drive systems]
Robert Treat wrote: > On Thu, 2003-10-09 at 19:54, Bruce Momjian wrote: > > > > I signed up for an account, and it has already been helpful. I wish I > > had known about this years ago. I will probably put together a little > > sourceforge project so I can get access to their Solaris and OS X > > machines so I will have even better hardware access. Those are the only > > two OS's missing from the Test Drive site. > > > > I have a project you could join if you want :-) > http://sourceforge.net/projects/pgsql/ OK, can you make me an admin so I can access the compile farm. My sourceforge username is 'bmomjian'. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [Fwd: [BUGS] pg_autovacuum segv]
OK, I committed a fix so it will not segfault on root starting it.
---
Christopher Browne wrote:
> In the last exciting episode, [EMAIL PROTECTED] (Markus Bertheau) wrote:
> > Forwarding to -hackers as per README
> >
> > -?? ??-
> >
> > From: Markus Bertheau <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: [BUGS] pg_autovacuum segv
> > Date: 09 Oct 2003 17:30:48 +0200
> >
> > (gdb) run
> > Starting program:
> > /root/src/postgresql-7.4beta4/contrib/pg_autovacuum/pg_autovacuum
> > [2003-10-09 05:28:13 PM] Failed connection to database template1 with error:
> > FATAL: user "root" does not exist
>
> It should probably have died more gracefully, but what happened here
> should be clear enough.
>
> You ran the program as root, and so it assumed that it should connect
> as PostgreSQL user "root." That user does not exist, so the
> connection failed.
>
> You'll need to specify a user, or establish "root" as a superuser.
> --
> wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
> http://www3.sympatico.ca/cbbrowne/spreadsheets.html
> "Bother," said Pooh as he struggled with sendmail.cf.
> "It never does quite what I want."
> "I wish Christopher Robin were here.".
>
> ---(end of broadcast)---
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 2-phase commit
Andrew Sullivan <[EMAIL PROTECTED]> wrote: > On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote: > > Satoshi, the only guy who made a trial implementation of 2PC for > > PostgreSQL, has already showed that 2PC is not that slow. > > If someone has a fast implementation, so much the better. I'm not > opposed to fast implementations! The pgbench results of my experimental 2PC implementation and plain postgresql are available. PostgreSQL 7.3 http://snaga.org/pgsql/pgbench/pgbench-REL7_3.log Experimental 2PC in PostgreSQL 7.3 http://snaga.org/pgsql/pgbench/pgbench-TPC0_0_2.log I can't see a grave overhead from this comparison. > > A > > -- > > Andrew Sullivan 204-4141 Yonge Street > Afilias CanadaToronto, Ontario Canada > <[EMAIL PROTECTED]> M2P 2A8 > +1 416 646 3304 x110 > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend > -- NAGAYASU Satoshi <[EMAIL PROTECTED]> ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile warning
Bruce Momjian wrote:
This seems to be a bug in gcc-3.3.1. -fstrict-aliasing is enabled by
-O2 or higher optimization in gcc 3.3.1.
Now that I think of it, they might be talking about an optimization
called register aliasing, where they are taking the structure and
mapping it to a CPU register for some optimization, and what we are
doing is to store a different structure in there that will not fit in a
register. A Node will fit in a register (it is only an enum) but the
TriggerData structure will not, meaning the code has to spill the
register to memory, then access the full structure, or something like
that.
Did you mean register renaming? If so, it is only turned on by -O3. But I can see that strict aliasing does help the compiler make the right guess as to which registers to use for what, even without register renaming.
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Optimize-Options.html#Optimize%20Options
says:
|-O|
|-O1|
Optimize. Optimizing compilation takes somewhat more time, and a lot
more memory for a large function.
With |-O|, the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal of
compilation time.
|-O| turns on the following optimization flags:
-fdefer-pop
-fmerge-constants
-fthread-jumps
-floop-optimize
-fcrossjumping
-fif-conversion
-fif-conversion2
-fdelayed-branch
-fguess-branch-probability
-fcprop-registers
|-O| also turns on |-fomit-frame-pointer| on machines where doing so
does not interfere with debugging.
|-O2|
Optimize even more. GCC performs nearly all supported optimizations
that do not involve a space-speed tradeoff. The compiler does not
perform loop unrolling or function inlining when you specify |-O2|.
As compared to |-O|, this option increases both compilation time and
the performance of the generated code.
|-O2| turns on all optimization flags specified by |-O|. It also
turns on the following optimization flags:
-fforce-mem
-foptimize-sibling-calls
-fstrength-reduce
-fcse-follow-jumps -fcse-skip-blocks
-frerun-cse-after-loop -frerun-loop-opt
-fgcse -fgcse-lm -fgcse-sm
-fdelete-null-pointer-checks
-fexpensive-optimizations
-fregmove
-fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec
-fcaller-saves
-fpeephole2
-freorder-blocks -freorder-functions
-fstrict-aliasing
-falign-functions -falign-jumps
-falign-loops -falign-labels
Please note the warning under |-fgcse| about invoking |-O2| on
programs that use computed gotos.
|-O3|
Optimize yet more. |-O3| turns on all optimizations specified by
|-O2| and also turns on the |-finline-functions| and
|-frename-registers| options.
In the Linux kernel, you can see this in include/linux/tcp.h:
/*
* The union cast uses a gcc extension to avoid aliasing problems
* (union is compatible to any of its members)
* This means this part of the code is -fstrict-aliasing safe now.
*/
union tcp_word_hdr {
struct tcphdr hdr;
__u32 words[5];
};
#define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))->words [3])
Maybe this gives us a clue.
cheers
andrew
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] 2-phase commit
On Thu, Oct 09, 2003 at 11:53:46PM -0400, Christopher Browne wrote: > > If 2PC gets implemented, that simply means that there will be another > module that some will be interested in, and which many people won't > bother using. Which shouldn't seem to be a particularly big deal. I think the reason this is controversial, however, is that while PL/R (e.g.) doesn't make big changes to the internals, 2PC certainly will touch the fundamentals. A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 2-phase commit
On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote: > Satoshi, the only guy who made a trial implementation of 2PC for > PostgreSQL, has already showed that 2PC is not that slow. If someone has a fast implementation, so much the better. I'm not opposed to fast implementations! A -- Andrew Sullivan 204-4141 Yonge Street Afilias CanadaToronto, Ontario Canada <[EMAIL PROTECTED]> M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] rt_sigprocmask
Hi all, I'm importing on Postgres 7.3.4 a dump and after one hour the process is still there to perform a COPY of a table with about ~1.5M rows. I did an strace on it and I had a lot of rt_sigprocmask comparing to read and write operations. What is going on? # strace -p 6370 read(33, "\n\0\0\0|-l\3146\0\0\0\254\1\270\1\0 \1 \264\237\230\0"..., 8192) = 8192 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 _llseek(22, 0, [3268608], SEEK_END) = 0 write(22, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 _llseek(21, 0, [3358720], SEEK_END) = 0 write(21, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 ( here the Load average is 25% because the box have 4 processors ) # iostat 1 Linux 2.4.20-13.9smp (dell-01) 10/10/2003 avg-cpu: %user %nice%sys %idle 6.980.022.26 90.74 Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev8-0 11.39 167.16 151.52 493154000 447007536 avg-cpu: %user %nice%sys %idle 27.000.001.25 71.75 Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev8-00.00 0.00 0.00 0 0 avg-cpu: %user %nice%sys %idle 27.750.000.75 71.50 Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev8-00.00 0.00 0.00 0 0 avg-cpu: %user %nice%sys %idle 25.500.001.75 72.75 Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev8-00.00 0.00 0.00 0 0 avg-cpu: %user %nice%sys %idle 26.250.006.25 67.50 Device:tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev8-0 10.00 0.00 200.00 0200 # vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 407940 21588 125596 47096811 3 10 0 0 2 0 1 0 0 407940 21588 125596 47096800 0 0 531 480 30 1 69 1 0 0 407940 21588 125624 47096400 0 116 549 494 26 6 68 1 0 0 407940 21588 125624 47096400 0 0 582 499 29 1 70 1 0 0 407940 21588 125624 47096400 0 0 561 517 29 1 69 1 0 0 407940 21588 125624 47096400 0 0 531 537 27 1 71 1 0 0 407940 21588 125624 47096400 0 0 542 470 26 1 73 1 0 0 407940 21584 125636 47096400 052 553 493 23 7 71 1 0 0 407940 21584 125636 47097200 0 0 548 491 23 9 68 1 0 0 407940 21584 125636 47097200 0 0 542 498 10 19 71 1 0 0 407940 21584 125636 47097200 0 0 547 472 22 8 70 1 0 0 407940 21584 125636 47097200 0 0 576 512 29 2 69 1 0 0 407940 21584 125640 47096800 056 564 510 30 2 68 2 0 0 407940 21584 125640 47097600 0 0 524 509 29 2 69 1 0 0 407940 21584 125640 47097640 4 0 630 634 30 1 69 Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile warning
Alvaro Herrera wrote:
> On Thu, Oct 09, 2003 at 11:51:09PM -0400, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > I'm seeing this compile warning on today's CVS tip:
> > >
> > > $ make src/backend/commands/tablecmds.o
> > > gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I./src/include
> > > -D_GNU_SOURCE -c -o src/backend/commands/tablecmds.o
> > > src/backend/commands/tablecmds.c
> > > src/backend/commands/tablecmds.c: In function `validateForeignKeyConstraint':
> > > src/backend/commands/tablecmds.c:3528: warning: dereferencing type-punned
> > > pointer will break strict-aliasing rules
> >
> > If you change the offending line to:
> >
> > fcinfo.context = (struct Node *) &trigdata;
> >
> > I know it shouldn't make a difference, but it is worth a try.
>
> Nope, same warning. I don't know what it means though. I tried some
> other things to correct it, but I can't find exactly what it's
> complaining about. What is a "type-punned pointer"?
>
> Looking in Google finds this thread first:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg58957.html
> which is full of a very ugly kernel macro (I'm happy to stay away from
> that):
>
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg58957.html
>
>
> This other guy actually posted an useful excerpt from the GCC manpage:
> http://www.ethereal.com/lists/ethereal-dev/200309/msg00342.html
>
> So, I still don't understand what's the noise about. However I think
> there's no way to silence the warning without uglifying the structs a
> lot by means of some union.
I am still confused. I understand the example listed in the last URL:
union a_union {
int i;
double d;
};
int f() {
a_union t;
t.d = 3.0;
return t.i;
}
will work fine because you are accessing the values through the union.
However in this example, also from that URL:
int f() {
a_union t;
int* ip;
t.d = 3.0;
ip = &t.i;
return *ip;
}
there is a problem because it assumes that the int and double _start_
at the same address in the structure. It is probabably a bad idea to be
taking passing pointers out of a union.
However, we aren't using unions in the query being complainted about.
In our code mentioned above, we have:
> > fcinfo.context = (Node *) &trigdata;
We are taking the address of a structure (not a union), but we are
assuming that a "struct TriggerData" pointer can be accessed through a
"struct Node" pointer. Now, both structures begin with a NodeTag
element, so it should be OK, but I guess the compiler guys don't know
that. However, I thought the cast shouldn't cause a problem at all.
Can someone with gcc 3.3.1 make up a little test program to illustrate
the bug? Does taking the adddress of any structure an casting it cause
this warning? I would think not because we must do that lots of places
in our code.
This seems to be a bug in gcc-3.3.1. -fstrict-aliasing is enabled by
-O2 or higher optimization in gcc 3.3.1.
Now that I think of it, they might be talking about an optimization
called register aliasing, where they are taking the structure and
mapping it to a CPU register for some optimization, and what we are
doing is to store a different structure in there that will not fit in a
register. A Node will fit in a register (it is only an enum) but the
TriggerData structure will not, meaning the code has to spill the
register to memory, then access the full structure, or something like
that.
Here are the places reported to generated warnings in our code by the
Cygwin guys:
tablecmds.c:3528: warning: dereferencing type-punned pointer will break
strict-aliasing rules
execQual.c:749: warning: dereferencing type-punned pointer will break
strict-aliasing rules
execQual.c:995: warning: dereferencing type-punned pointer will break
strict-aliasing rules
pg_shmem.c:368: warning: passing arg 1 of `shmdt' from incompatible pointer
type
proc.c:1016: warning: dereferencing type-punned pointer will break
strict-aliasing rules
proc.c:1057: warning: dereferencing type-punned pointer will break
strict-aliasing rules
proc.c:1123: warning: dereferencing type-punned pointer will break
strict-aliasing rules
command.c:1283: warning: dereferencing type-punned pointer will break
strict-aliasing rules
Looking at the proc.c cases, we have:
MemSet(&timeval, 0, sizeof(struct itimerval));
MemSet is passing struct itimerval * to an *int32, again a case of passing
a structure pointer to something to a data type that will fit in a
register.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please s
Re: [HACKERS] last beta version to require initdb
Robert Treat writes: > What's the last beta version that required initdb? According to this http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/catalog/catversion.h it was the transition from beta1 to beta2. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CREATE USER bug
Neil Conway wrote: > On Mon, 2003-10-06 at 16:21, Joshua D. Drake wrote: > > postgres=# create user with encrypted password '98wq7912a'; > > CREATE USER > > postgres=# create user with encrypted password '98wq7912a'; > > ERROR: CREATE USER: user name "with" already exists > > So, what are we doing about this? If we're considering it a bug, one way > to fix it is to move WITH from unreserved_keywords to reserved_keywords. > Any other suggestions? I think the code is fine as it is now, seeing how WITH is optional: CREATE USER username [ [ WITH ] option [ ... ] ] I don't see a huge problem with allowing "with" as a user name. Of course, we could require them to write: CREATE USER with WITH ... but then WITH isn't optional anymore, at least for a user named 'with'. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] last beta version to require initdb
What's the last beta version that required initdb?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [Fwd: [BUGS] pg_autovacuum segv]
In the last exciting episode, [EMAIL PROTECTED] (Markus Bertheau) wrote:
> Forwarding to -hackers as per README
>
> -Пересланное сообщение-
>
> From: Markus Bertheau <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [BUGS] pg_autovacuum segv
> Date: 09 Oct 2003 17:30:48 +0200
>
> (gdb) run
> Starting program: /root/src/postgresql-7.4beta4/contrib/pg_autovacuum/pg_autovacuum
> [2003-10-09 05:28:13 PM] Failed connection to database template1 with error: FATAL:
> user "root" does not exist
It should probably have died more gracefully, but what happened here
should be clear enough.
You ran the program as root, and so it assumed that it should connect
as PostgreSQL user "root." That user does not exist, so the
connection failed.
You'll need to specify a user, or establish "root" as a superuser.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
"Bother," said Pooh as he struggled with sendmail.cf.
"It never does quite what I want."
"I wish Christopher Robin were here.".
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] [Fwd: [Python-Dev] HP Test Drive systems]
On Thu, 2003-10-09 at 19:54, Bruce Momjian wrote:
>
> I signed up for an account, and it has already been helpful. I wish I
> had known about this years ago. I will probably put together a little
> sourceforge project so I can get access to their Solaris and OS X
> machines so I will have even better hardware access. Those are the only
> two OS's missing from the Test Drive site.
>
I have a project you could join if you want :-)
http://sourceforge.net/projects/pgsql/
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4beta4 compile failure on NetBSD
On Fri, Oct 10, 2003 at 16:36:56 +0900, Curt Sampson <[EMAIL PROTECTED]> wrote: > I just happened to try to compile 7.4beta4 on a two-month-old NetBSD-current > system, and I get the following: > > In file included from timestamp.c:14: > ../../../../src/interfaces/ecpg/include/datetime.h:7: conflicting types for `dtime_t' > /usr/include/sys/types.h:186: previous declaration of `dtime_t' > > Basically, the "typedef timestamp dtime_t;" (timestamp is a double) > conflicts with > > typedef int32_t dtime_t;/* on-disk time_t */ > > in . These appear to me to be completely unrelated typedefs > that just happen to have the same name. > > This is when compiling src/interfaces/ecpg/pgtypeslib/timestamp.c, BTW. > > Any thoughts? I'm prepared to pull down a CVS checkout and recompile > to test fixes, if that will help. I had a problem with timestamp.c in beta4 and it got fixed in CVS. I don't think the error message was the same though, so your problem might be different. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] compile warnings on cygwin - make check fails
Andrew, On Fri, Oct 10, 2003 at 08:56:51AM -0400, Andrew Dunstan wrote: > Jason Tishler wrote: > >Are you getting hangs or connection refused errors. The Cygwin > >PostgreSQL README documents the following issue: > >[snip] > > hangs - I have to kill the psql process to continue. This could mean it will hang on NT and 2000 too. Sigh... Can you attach to the hung psql to determine where it's hanging? > >Can you try make installcheck instead? > > will do tonight after work. Thanks! Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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: [HACKERS] compile warnings on cygwin - make check fails
Jason Tishler wrote: Andrew, On Fri, Oct 10, 2003 at 12:25:01AM -0400, Andrew Dunstan wrote: WinXP/cygwin/gcc version 3.3.1 (cygming special) XP Home or Pro? What version of Cygwin? XP-HE. I ran a cygwin upgrade last night (to pick up the latest bison and get cygutils - it picked up gcc along the way). Then I installed the ipc-daemon2 as a service and started it, and ran make check. gives these tablecmds.c:3528: warning: dereferencing type-punned pointer will break strict-aliasing rules [snip] FWIW, I saw warnings I never saw before when compiling Python under Cygwin gcc 3.3.1 yesterday. I presume gcc 3.3.1 is pickier or more "chatty" than it was before. Anyway, Python still passed its full regression test. Right. It's been sen on other platforms with the latest gcc too, I believe. As I understand the latest versions of gcc turn this on with -O2, so perhaps we need to add -fno-strict-aliasing as a short term measure if we are using gcc. But it should be fixed - IIRC the Linux kernel folks went through some agony over this and eventually made almost the whole kernel type-pun safe. After all, this enables better optimisation. make check fails (hangs) consistently on parallel tests Are you getting hangs or connection refused errors. The Cygwin PostgreSQL README documents the following issue: hangs - I have to kill the psql process to continue. 1. make check can generate spurious regression test failures due to overflowing the the listen() backlog queue which generates connection refused errors. Note that make installcheck does not have this problem since it runs all tests sequentially instead of in large concurrent groups. max_connections set to 100, shared_buffers set to 1000 by initdb (CVS version, not mine). The above will not have any affects under Cygwin. IIRC, the listen() backlog is 200 under server versions of Windows (e.g., 2000 Advanced Server) and 5 on all other versions (e.g., XP Pro). Can you try make installcheck instead? will do tonight after work. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] [Fwd: [BUGS] pg_autovacuum segv]
Forwarding to -hackers as per README
-Пересланное сообщение-
From: Markus Bertheau <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [BUGS] pg_autovacuum segv
Date: 09 Oct 2003 17:30:48 +0200
(gdb) run
Starting program: /root/src/postgresql-7.4beta4/contrib/pg_autovacuum/pg_autovacuum
[2003-10-09 05:28:13 PM] Failed connection to database template1 with error: FATAL:
user "root" does not exist
.
Program received signal SIGSEGV, Segmentation fault.
0x0804a132 in check_stats_enabled (dbi=0x804e2f0) at pg_autovacuum.c:739
739 strcmp("on", PQgetvalue(res, 0, PQfnumber(res,
"stats_row_level")));
(gdb) bt
#0 0x0804a132 in check_stats_enabled (dbi=0x804e2f0) at pg_autovacuum.c:739
#1 0x0804a9b3 in main (argc=1, argv=0xbfffdf64) at pg_autovacuum.c:1004
#2 0x40103657 in __libc_start_main (main=0x804a8e4 , argc=1, ubp_av=0xbfffdf64,
init=0x8048b30 <_init>,
fini=0x804afd0 <_fini>, rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbfffdf5c) at
../sysdeps/generic/libc-start.c:129
(gdb)
This is on a i386 Redhat 7.2 with pg7.3.4 installed.
--
Markus Bertheau <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] compile warnings on cygwin - make check fails
Andrew, On Fri, Oct 10, 2003 at 12:25:01AM -0400, Andrew Dunstan wrote: > WinXP/cygwin/gcc version 3.3.1 (cygming special) XP Home or Pro? What version of Cygwin? > gives these > > tablecmds.c:3528: warning: dereferencing type-punned pointer will break > strict-aliasing rules > [snip] FWIW, I saw warnings I never saw before when compiling Python under Cygwin gcc 3.3.1 yesterday. I presume gcc 3.3.1 is pickier or more "chatty" than it was before. Anyway, Python still passed its full regression test. > make check fails (hangs) consistently on parallel tests Are you getting hangs or connection refused errors. The Cygwin PostgreSQL README documents the following issue: 1. make check can generate spurious regression test failures due to overflowing the the listen() backlog queue which generates connection refused errors. Note that make installcheck does not have this problem since it runs all tests sequentially instead of in large concurrent groups. > max_connections set to 100, shared_buffers set to 1000 by initdb (CVS > version, not mine). The above will not have any affects under Cygwin. IIRC, the listen() backlog is 200 under server versions of Windows (e.g., 2000 Advanced Server) and 5 on all other versions (e.g., XP Pro). Can you try make installcheck instead? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [pgsql-hackers-win32] [HACKERS] initdb
There's a new version available at http://www.dunslane.net/~andrew/Initdb_In_C.html - I think it takes care of all of Peter's comments. I removed initdb-scripts.h - the smaller scripts were moved into initdb.c with SQL comments turned into C comments, and the large script to set up system views becomes its own file, which is now passed to postgres with single line mode turned off. I have just realised that I seem to have skipped the bki file version check. I will fix that in the next version. cheers andrew - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Andrew Dunstan" <[EMAIL PROTECTED]> Cc: "Postgresql Hackers" <[EMAIL PROTECTED]>; "pgsql-hackers-win32" <[EMAIL PROTECTED]> Sent: Thursday, October 09, 2003 10:07 PM Subject: Re: [pgsql-hackers-win32] [HACKERS] initdb > Andrew Dunstan wrote: > > There will be a new version out there soon. When I am happy with it I will > > let you know - right now I am dealing with 2 issues - setlocale(LC_ALL,"") > > doesn't read from the environment on Windows, and the program is possibly > > not picking up the buffers/connections properly. > > > > Please don't put the version currently out there in CVS - the files won't > > even be the same - initdb-scripts.h will disappear and there will be a new > > file called "system_views.sql". > > > > There is no urgency about this - until we have a working postgres executable > > on Windows initdb is useless anyway. My aim has been to have initdb ready > > when postgres is ready. Of course, I test against Unix all the time to make > > sure nothing gets broken. > > Fine. We have the URL on the win32 web site, and that's all we need. > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 359-1001 > + If your life is a hard drive, | 13 Roberts Road > + Christ can be your backup.| Newtown Square, Pennsylvania 19073 > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 2-phase commit
I was wondering whether we need to keep WAL online for 2PC, or whether only something like clog is sufficient. What if: 1. phase 1 commit must pass the slave xid that will be used for 2nd phase (it needs to return some sort of identification anyway) 2. the coordinator must keep a list of slave xid's along with corresponding (commit/rollback) info Is that not sufficient ? Why would WAL be needed in the first place ? This is not replication, the slave has it's own WAL anyway. I also don't buy the argument with the lockup. Iff today somebody connects with psql starts a transaction modifies something and then never commits or aborts there is also no automatism builtin that will eventually kill it automatically. 2PC will simply need to have means for the administrator to rollback/commit an in doubt transaction manually. Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Broken Constraint Checking in Functions
So it seems I got bitten today by this to-do list item: Have AFTER triggers execute after the appropriate SQL statement in a function, not at the end of the function Under normal circumstances, delaying this stuff until the end of the function doesn't bother me; in fact I've even used it to get around the fact that SET CONSTRAINTS won't let you delay non-referential constraint checks. However, it seems that cascading deletes are also delayed, which leads to a pretty serious problem. The following code: INSERT INTO master (master_id) VALUES (400); INSERT INTO dependent (master_id) VALUES (400); DELETE FROM master WHERE master_id = 400; works just fine outside a function, but inside a function it fails with ERROR: $1 referential integrity violation - key referenced from dependent not found in master It seems that the integrity check for the dependent is happening before the cascaded delete, but the check is operating not on the data at the time of the statement, but the data as it stands after the statement following the one that triggered the check. Ouch! Having spent the better part of a day tracking down this problem (because of course, as always, it only decides to appear in one's own code after it's gotten quite complex), I think for a start it would be a really, really good idea to put something about this in the documentation for the 7.4 release. Probably the SET CONSTRAINTS page would be a good place to have it, or at least a pointer to it. In the long run, of course, I'd like to see a fix, but preferably after we fix the system to allow delay of non-referential constraints as well, since I am use this "bug" now in production code to delay constraint checking for non-referential constraints. (You might even document that workaround in the SET CONSTRAINTS manual page, with an appropriate warning, if one seems necessary.) I've attached a short shell script that will demonstrate the problem. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org Don't you know, in this new Dark Age, we're all light. --XTC#!/bin/sh schema="pfcb_test" cat < ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] 7.4beta4 compile failure on NetBSD
I just happened to try to compile 7.4beta4 on a two-month-old NetBSD-current system, and I get the following: In file included from timestamp.c:14: ../../../../src/interfaces/ecpg/include/datetime.h:7: conflicting types for `dtime_t' /usr/include/sys/types.h:186: previous declaration of `dtime_t' Basically, the "typedef timestamp dtime_t;" (timestamp is a double) conflicts with typedef int32_t dtime_t;/* on-disk time_t */ in . These appear to me to be completely unrelated typedefs that just happen to have the same name. This is when compiling src/interfaces/ecpg/pgtypeslib/timestamp.c, BTW. Any thoughts? I'm prepared to pull down a CVS checkout and recompile to test fixes, if that will help. cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.NetBSD.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
