Re: [BUGS] Problem with RULE to update tables
On Mon, Mar 17, 2003 at 02:41:29PM -0500, Tom Lane wrote: >Yup. A rule is invoked once per query, not once per operated-on record. >You'll find that a trigger acts more like what you are expecting. Ah, yeah, that seems to work exactly as expected. At least, my tests now pass successfully after converting from a rule to a trigger. It was a pain that trigger functions can't be SQL. I just wanted to run some SQL after the delete/insert/update, and ended up having to wrap it in a pl/python function... Thanks, Sean -- "Isn't having a smoking section in a restaurant kind of like having a peeing section in a swimming pool?" -- David Broadfoot Sean Reifschneider, Inimitably Superfluous <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Bug on solaris 8,
My conditions : Solaris 8, Postgresql 7.3.2, gcc 3.2 I try to compile with option 64 bits ( -m64 ) I obtain the error : make[3]: Entering directory `/usr/local/sources/pgsql/postgresql-7.3.2/src/backend/utils/mb/conversion_procs/ascii_and_mic' gcc -shared -h libascii_and_mic.so.0 ascii_and_mic.o -L../../../../../../src/port -o libascii_and_mic.so.0.0 ld: fatal: file ascii_and_mic.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to libascii_and_mic.so.0.0 collect2: ld returned 1 exit status make[3]: *** [libascii_and_mic.so.0.0] Error 1 make[3]: Leaving directory `/usr/local/sources/pgsql/postgresql-7.3.2/src/backend/utils/mb/conversion_procs/ascii_and_mic' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/sources/pgsql/postgresql-7.3.2/src/backend/utils/mb/conversion_procs' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/sources/pgsql/postgresql-7.3.2/src' make: *** [all] Error 2 I think, the makefile is without "-m64" Thank's - Michel GALLOU Administrateur Systèmes et Réseaux C.N.R.S. Délegation Bretagne et Pays de la Loire Centre d'affaires Oberthur 74E, Rue de Paris 35069 Rennes Cedex téléphone: (33) 2 99 28 68 05 télécopie: (33) 2 99 28 68 01 visioconférence: (33) 2 99 28 68 00 courriel: [EMAIL PROTECTED] , http://www.dr17.cnrs.fr -- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] Bugs or Error?
Hello, I just want to know if this is a bug or just an error to my postgrsql. What i did is i install the postgresql 7.2.1mlx for libs, posgresql, and server using Linux Red Hat 8.0. Then i created a "postgres" and do the following; su postgres psql template1 then i try to create database "inventory" in template1=# then this message appear. "NOTICE: write error may be permanent: cannot write block 10 for 22892/1249 ERROR: cannot write block 10 of 22892/1249 blind: No such file or directory" How this happen? Thanks in advance. -=Nard=- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] ERROR: Invalid EUC_CN character sequence found (0x8000)
I met ERROR when I try to make a search using like 'Z%' with EUC_CN database. The next is the snapshot. Could any help me? Thanks. palo=> \l List of databases Name | Owner | Encoding ---+--+--- palo | palouser | EUC_CN palo=> select * from sysuser where userid like 'Z%';ERROR: Invalid EUC_CN character sequence found (0x8000) [EMAIL PROTECTED] leon]$ psql -V psql (PostgreSQL) 7.2.2contains support for: readline, history, multibytePortions Copyright (c) 1996-2001, PostgreSQL Global Development GroupPortions Copyright (c) 1996, Regents of the University of CaliforniaRead the file COPYRIGHT or use the command \copyright to see theusage and distribution terms. B.R.LEONJUST DO IT! NOW!
[BUGS] libpq PQexec not thread-safe
Author note:
I am not in any of the pg mailing lists. Please contact me directly for
further information, or invite me to an appropriate mailing list.
Summary:
libpq PQexec is not thread safe with respec to the async signal handler
SIGPIPE. This can result in problems ranging from an app signal handler
being reset to the app exitting inside libpq as a result of a default
signal handler. (The issue is a race condition, to results are varied.)
Environment:
- RedHat Linux using pthreads (redhat 6.2 and 8), SMP 4-way, intel
- libpq 7.3.2
Steps:
- The application sets sigaction SIGPIPE to something other than SIG_IGN
or leaves SIG_DFL
- Open two threads
- Each thread creates its own connection
- Each thread performs independant access to the database in an
unsynchronized way
- Join the two threads
- Check the final signal handler
Actual Results:
- The SIGPIPE handler changes when two PQexecs occur 'at the same time'
- The SIGPIPE handler will tend towards SIG_IGN
- Sometimes a PQexec will be operating with SIG_DFL as the SIGPIPE handler
(if the app leaves the default SIG_DFL SIGPIPE handler)
- The final signal handler is SIG_IGN most of the time
Expected Results:
- While at least one PQexec is running, the SIGPIPE handler will be
SIG_IGN even though the application has a different SIGPIPE handler
- While no PQexecs are running, the SIGPIPE handler will be whatever
the app set it to
- PQexec will never be left with a SIG_IGN SIGPIPE handler
- The final signal handler is whatever the app set it to initially
Additional notes:
- While sigaction provides flags, they are not being stored or restored
Suggestions:
- As a hack, make all applications that use libpq first set SIGPIPE's
sigaction to SIG_IGN (this clears up all problems)
- Use an internal mutex to prevent sigaction from being called from
two different threads between set and reset calls (an internal counter)
- Allow the application to tell libpq not to touch sigactions
- Allow the appliaction to provide a signal handler callback
- Restore the entire sigaction structure rather than just the sa_handler
Example of failure:
#include
#include
#include
#include
#include
#include
#include
static int parse_args ( int argc, char * argv [] );
static int set_sigpipe ( void );
static int start_thread ( pthread_t * thread_id );
static int join_thread ( pthread_t thread_id );
static void pipe_sighandler ( int signum );
static void * pg_thread ( void * notused );
static void check_pipe_handler ( int count );
static int g_pipe_count;
static const char * g_db_name;
static const char * g_db_host;
static const char * g_db_port;
static const char * g_db_user;
static const char * g_db_pass;
int main ( int argc, char * argv [] )
{
pthread_t thread1;
pthread_t thread2;
if ( parse_args( argc, argv ) < 0 ) return( 2 );
if ( set_sigpipe()< 0 ) return( 2 );
if ( start_thread( &thread1 ) < 0 ) return( 2 );
if ( start_thread( &thread2 ) < 0 ) return( 2 );
if ( join_thread( thread1 ) < 0 ) return( 2 );
if ( join_thread( thread2 ) < 0 ) return( 2 );
check_pipe_handler( -1 );
return( 0 );
}
static int parse_args ( int argc, char * argv [] )
{
extern char * optarg;
extern intoptind;
extern intopterr;
extern intoptopt;
int res;
opterr = 0;
while ( (res = getopt( argc, argv, "d:h:p:U:W:" )) != -1 ) {
switch ( res ) {
case 'd':
g_db_name = strdup( optarg );
break;
case 'h':
g_db_host = strdup( optarg );
break;
case 'p':
g_db_port = strdup( optarg );
break;
case 'U':
g_db_user = strdup( optarg );
break;
case 'W':
g_db_pass = strdup( optarg );
break;
default:
fprintf( stderr, "%s [-d ] [-h ] [-p
]"
"[-U ] [-W ]\n", argv[ 0 ] );
return( -1 );
}
}
return( 0 );
}
static int set_sigpipe ( void )
{
struct sigaction new_act;
struct sigaction old_act;
g_pipe_count = 0;
memset( &new_act, 0, sizeof( new_act ) );
memset( &old_act, 0, sizeof( old_act ) );
new_act.sa_handler = pipe_sighandler;
if ( sigaction( SIGPIPE, &new_act, &old_act ) ) {
fprintf( stderr, "sigaction( SIGPIPE, ... ):%s(%d)\n",
strerror( errno ), errno );
return( -1 );
}
return( 0 );
}
static void pipe_sighandler ( int signum )
{
g_pipe_count++;
}
static int start_thread ( pthread_t * thread_id )
{
int result;
*thread_id = 0;
result = pthread_create( thread_id, NULL, pg_thread
[BUGS] Bug #914: Possible bug with regards to multiple persistant connections
Philippe Hajjar ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description Possible bug with regards to multiple persistant connections Long Description The operating environment in which this occurred is: Apache 1.3.27 PHP 4.2.3 PostgreSQL 7.3.2 Redhat Linux 7.2 ADODB for PHP version 3.10 I have a database with a single associated user account that owns the database. I connect using a to this database and begin a transaction and start doing inserts and updates. However, I want to commit some other data to the same database in a table (unrelated to those being modified through the first connection) outside of the transaction so I open a second persistant connection under the same user account and I write this information using an INSERT. In the first connection, I roll back the transaction and the insert I did under the second connection also gets rolled back. Is this supposed to occur? Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #914: Possible bug with regards to multiple persistant connections
[EMAIL PROTECTED] writes: > I have a database with a single associated user account that owns the database. I > connect using a to this database and begin a transaction and start doing inserts and > updates. However, I want to commit some other data to the same database in a table > (unrelated to those being modified through the first connection) outside of the > transaction so I open a second persistant connection under the same user account and > I write this information using an INSERT. In the first connection, I roll back the > transaction and the insert I did under the second connection also gets rolled back. > Is this supposed to occur? Sounds to me like your "second persistent connection" is the same connection. Better re-read the PHP docs ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] Bug #890: only one user per process in libpq with krb5 auth
> OK, please let me know. Thanks. I haven't taken the time to check the current state of the authentication code and am relying on my old work on it. Would it be worth me taking the time to try to rework it in a better manner? >>>--> -- +-+---+---+ | Ed Schaller | Dark Mist Networking | psuedoshroom | +-+---+---+ pgp0.pgp Description: PGP signature
Re: [BUGS] Bug #890: only one user per process in libpq with krb5 auth
> Is this ready to be applied. It looks fine to me. I want to remove the > part of the patch that keeps the old structure definitions at the top, > but other than that, it looks good. Is there something that needs > improving about it? I've been working with it a little and it appears that something as canged and it will need to be redone. I'm fairly busy, but I'll try to take a look at it this week as this makes some of my systems inoperable. >>>--> -- +-+---+---+ | Ed Schaller | Dark Mist Networking | psuedoshroom | +-+---+---+ pgp0.pgp Description: PGP signature
Re: [BUGS] Bugs or Error?
Ninonard Policarpio <[EMAIL PROTECTED]> writes: > What i did is i install the postgresql 7.2.1mlx for libs, posgresql, and > server What in the world is "postgresql 7.2.1mlx" ? > "NOTICE: write error may be permanent: cannot write block 10 for 22892/1249 > ERROR: cannot write block 10 of 22892/1249 blind: No such file or > directory" This seems pretty broken, indeed, but I can't help wondering what it is that you have installed. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
