[GENERAL] Instangram is powered by PostgreSQL
just wanna to share that Instagram use PostgreSQL. excellent ! this company worth for 1 billion is powered by PostgreSQL Click link below http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html http://instagram-engineering.tumblr.com/post/20541814340/keeping-instagram-up-with-over-a-million-new-users-in
Re: [GENERAL] Resize numeric column without changing data?
On Mon, Apr 9, 2012 at 5:16 PM, Jeff Davis wrote: > On Mon, 2012-04-09 at 16:06 -0400, Lukas Eklund wrote: >> Ah. I must have not noticed that the typmod for views is not inherited >> automatically. I'm okay with developing a script to recreate the 15 or >> so views the depend on that table. What I'm trying to avoid is locking >> that table for a substantial amount of time. Thanks for the advice! > > FYI, later versions of postgres try to avoid rewrites of the table when > possible for simple ALTERs like the one you're talking about. > > Are you using PostgreSQL 9.1? Try it out in a simple test case... maybe > the lock is only held for an instant anyway. Some of these optimizations > went in 9.2 (not released yet) but I think the one you need is in 9.1. nope -- see link upthread. numeric is 9.2+ merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Resize numeric column without changing data?
On Mon, 2012-04-09 at 16:06 -0400, Lukas Eklund wrote: > Ah. I must have not noticed that the typmod for views is not inherited > automatically. I'm okay with developing a script to recreate the 15 or > so views the depend on that table. What I'm trying to avoid is locking > that table for a substantial amount of time. Thanks for the advice! FYI, later versions of postgres try to avoid rewrites of the table when possible for simple ALTERs like the one you're talking about. Are you using PostgreSQL 9.1? Try it out in a simple test case... maybe the lock is only held for an instant anyway. Some of these optimizations went in 9.2 (not released yet) but I think the one you need is in 9.1. Regards, Jeff Davis -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Resize numeric column without changing data?
On Mon, Apr 9, 2012 at 3:06 PM, Lukas Eklund wrote: > On Mon, Apr 9, 2012 at 2:51 PM, Merlin Moncure wrote: >> On Mon, Apr 9, 2012 at 9:57 AM, Lukas Eklund wrote: >>> Is it safe to resize a numeric column using in pg_attribute without >>> altering the table? >>> >> >> One thing that's pretty weird is that dependent view columns keep the >> old typmod. That might cause some issues with things that depend on >> that value, for example client side tools. But you can always change >> those as well. >> >> I think this might work because the numeric storage doesn't change for >> this case. But it's still quite dangerous and avoiding view >> re-recreation is a pretty weak justification to go be updating system >> catalogs. You'd be better off spending some time developing a script >> to recreate views. The only reason why I would personally be >> considering this would be to avoid issues stemming from having to take >> out a lock on the table and I would be testing very, very carefully if >> I did so. >> >> merlin > > Ah. I must have not noticed that the typmod for views is not inherited > automatically. I'm okay with developing a script to recreate the 15 or > so views the depend on that table. What I'm trying to avoid is locking > that table for a substantial amount of time. Thanks for the advice! np -- note 9.2 will be much smarter about this: http://archives.postgresql.org/message-id/20120101003619.ga4...@tornado.leadboat.com merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Resize numeric column without changing data?
On Mon, Apr 9, 2012 at 2:51 PM, Merlin Moncure wrote: > On Mon, Apr 9, 2012 at 9:57 AM, Lukas Eklund wrote: >> Is it safe to resize a numeric column using in pg_attribute without >> altering the table? >> > > One thing that's pretty weird is that dependent view columns keep the > old typmod. That might cause some issues with things that depend on > that value, for example client side tools. But you can always change > those as well. > > I think this might work because the numeric storage doesn't change for > this case. But it's still quite dangerous and avoiding view > re-recreation is a pretty weak justification to go be updating system > catalogs. You'd be better off spending some time developing a script > to recreate views. The only reason why I would personally be > considering this would be to avoid issues stemming from having to take > out a lock on the table and I would be testing very, very carefully if > I did so. > > merlin Ah. I must have not noticed that the typmod for views is not inherited automatically. I'm okay with developing a script to recreate the 15 or so views the depend on that table. What I'm trying to avoid is locking that table for a substantial amount of time. Thanks for the advice! Lukas -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Help needed to mount a dmp file
On 04/09/12 12:40 PM, François Beausoleil wrote: It depends on whether you have a SQL dump file or a custom archive type. I believe pg_restore can restore both kinds. no, pg_restore can only restore from custom archives (made with pg_dump -Fc) . straight SQL dumps are fed to psql -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Help needed to mount a dmp file
Le lundi 9 avril 2012 à 12:47, Lux a écrit : > Hi, > I am new to Postgresql and have no clue. The first task given to me was to > try to mount this dmp file on Postgresql which has been downloaded from Jive. > I am not sure how to go about and where to start. Can someone please help me. > Thanks & Regards, > Lux. You'll need either http://www.postgresql.org/docs/9.1/static/app-psql.html or http://www.postgresql.org/docs/9.1/static/app-pgrestore.html It depends on whether you have a SQL dump file or a custom archive type. I believe pg_restore can restore both kinds. You should also determine what version of PostgreSQL you're using, since that will help you with the manual links. I liked to the 9.1 versions above. Welcome to PostgreSQL. Hope that helps! François -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Help needed to mount a dmp file
Hi, I am new to Postgresql and have no clue. The first task given to me was to try to mount this dmp file on Postgresql which has been downloaded from Jive. I am not sure how to go about and where to start. Can someone please help me. Thanks & Regards, Lux.
Re: [GENERAL] Resize numeric column without changing data?
On Mon, Apr 9, 2012 at 9:57 AM, Lukas Eklund wrote: > Is it safe to resize a numeric column using in pg_attribute without > altering the table? > > I have a large table (over 900 million rows) that, due to some poor > design choices years ago, has a column numeric(8,2) that needs to > modified to numeric(12,2). I would like to avoid running an ALTER > TABLE statement on the table because of the time involved and the > number of views I would have to drop and recreate. I'm running 8.3. > > I know that for varchar, it's possible to change the size of the > column by updating atttypmod in pg_attribute for the column. What I'm > wondering is if I can do the same thing for a numeric column? My > understanding is that numeric is stored without any null padding so I > was thinking this might work. There are no indexes on the column in > question and the table is not partitioned. > > I've done some testing with a test table to see what happens and > everything seems to work okay but I wanted to make sure I'm not > missing something fundamental. > > This is a test table with a million rows: > > \d tester > Table "public.tester" > Column | Type | Modifiers > +--+--- > num | numeric(8,2) | > > select min(num), max(num) from tester; > min | max > --+--- > -8000.00 | 99.99 > > UPDATE pg_attribute SET atttypmod = 786438 > WHERE attrelid = 'tester'::regclass > AND attname = 'num'; > UPDATE 1 > Time: 32.895 ms > > \d tester > Table "public.tester" > Column | Type | Modifiers > +---+--- > num | numeric(12,2) | > > Selects, inserts, and updates on the table all seem to work fine. I > created some test views that rely on the test table and they seem to > work fine as well. Are there any caveats I'm missing? Is there > something about how numeric is stored on disk that I need be concerned > about when altering the column in this method? Is it safe to just > alter the metadata? One thing that's pretty weird is that dependent view columns keep the old typmod. That might cause some issues with things that depend on that value, for example client side tools. But you can always change those as well. I think this might work because the numeric storage doesn't change for this case. But it's still quite dangerous and avoiding view re-recreation is a pretty weak justification to go be updating system catalogs. You'd be better off spending some time developing a script to recreate views. The only reason why I would personally be considering this would be to avoid issues stemming from having to take out a lock on the table and I would be testing very, very carefully if I did so. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GROUP BY or alternative means to group
On Mon, Apr 09, 2012 at 13:55:04 -0400, Michael Gould wrote: Thanks that is a help. I would be nice if any key could be used as those are normally the things I would do group by's This is what the 9.1 documentation says: "When GROUP BY is present, it is not valid for the SELECT list expressions to refer to ungrouped columns except within aggregate functions or if the ungrouped column is functionally dependent on the grouped columns, since there would otherwise be more than one possible value to return for an ungrouped column. A functional dependency exists if the grouped columns (or a subset thereof) are the primary key of the table containing the ungrouped column." That implies you need to group by a primary key. I haven't tested if that (other keys can't provide this) is actually the case. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] GROUP BY or alternative means to group
Thanks that is a help. I would be nice if any key could be used as those are normally the things I would do group by's Regards Mike Gould From my Samsung Android tablet on T-Mobile. The first nationwide 4G networkBruno Wolff III wrote:On Mon, Mar 12, 2012 at 16:18:05 -0400, Michael Gould wrote: >You need to include all columns that are not aggregrative columns in the group >by. Even though that is the standard it is a pain to list all columns even if >you don't need them In later versions of postgres this is relaxed a bit. If you are grouping by a primary key, you don't need to group by columns that are fixed by that key. For example the following query is accepted in 9.1 as gameid is a key for games and hence we don't need to also group by ga,es.title. SELECT games.gameid, games.title FROM games, crate WHERE games.gameid = crate.gameid AND games.contact = 'BOB' AND crate.touched >= current_timestamp + '4 year ago' GROUP BY games.gameid HAVING count(1) < 30 ORDER BY games.gameid ;
Re: [GENERAL] My main/base/pgsql_tmp directory has over 5.7 millions files
Francois Lacoursiere writes: > Is there any reason why these files aren't cleaned-up ? We have just > installed postgresql-9.1.3 and it seems we have this problem since this > update. They're certainly supposed to be cleaned up. Can you provide a test case that causes one to be created and not cleaned up? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] My main/base/pgsql_tmp directory has over 5.7 millions files
Is there any reason why these files aren't cleaned-up ? We have just installed postgresql-9.1.3 and it seems we have this problem since this update. I haven't checked the ratio (ls takes more than 5 minutes to return) but most of these files seems to be empty. It causes me problem when I try to tar/untar my data directory to have SR on a slave machine. Would it be safe to have a cron script cleaining up these files once a day ? Better yet, any idea why those files are not automatically deleted when they are no longer needed ? Francois L. Montreal, Canada
Re: [GENERAL] GROUP BY or alternative means to group
On Mon, Mar 12, 2012 at 16:18:05 -0400, Michael Gould wrote: You need to include all columns that are not aggregrative columns in the group by. Even though that is the standard it is a pain to list all columns even if you don't need them In later versions of postgres this is relaxed a bit. If you are grouping by a primary key, you don't need to group by columns that are fixed by that key. For example the following query is accepted in 9.1 as gameid is a key for games and hence we don't need to also group by ga,es.title. SELECT games.gameid, games.title FROM games, crate WHERE games.gameid = crate.gameid AND games.contact = 'BOB' AND crate.touched >= current_timestamp + '4 year ago' GROUP BY games.gameid HAVING count(1) < 30 ORDER BY games.gameid ; -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Resize numeric column without changing data?
Is it safe to resize a numeric column using in pg_attribute without altering the table? I have a large table (over 900 million rows) that, due to some poor design choices years ago, has a column numeric(8,2) that needs to modified to numeric(12,2). I would like to avoid running an ALTER TABLE statement on the table because of the time involved and the number of views I would have to drop and recreate. I'm running 8.3. I know that for varchar, it's possible to change the size of the column by updating atttypmod in pg_attribute for the column. What I'm wondering is if I can do the same thing for a numeric column? My understanding is that numeric is stored without any null padding so I was thinking this might work. There are no indexes on the column in question and the table is not partitioned. I've done some testing with a test table to see what happens and everything seems to work okay but I wanted to make sure I'm not missing something fundamental. This is a test table with a million rows: \d tester Table "public.tester" Column | Type | Modifiers +--+--- num| numeric(8,2) | select min(num), max(num) from tester; min|max --+--- -8000.00 | 99.99 UPDATE pg_attribute SET atttypmod = 786438 WHERE attrelid = 'tester'::regclass AND attname = 'num'; UPDATE 1 Time: 32.895 ms \d tester Table "public.tester" Column | Type | Modifiers +---+--- num| numeric(12,2) | Selects, inserts, and updates on the table all seem to work fine. I created some test views that rely on the test table and they seem to work fine as well. Are there any caveats I'm missing? Is there something about how numeric is stored on disk that I need be concerned about when altering the column in this method? Is it safe to just alter the metadata? Thanks, -- Lukas Eklund lu...@eklund.io -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Regarding NOTIFY
On Mon, 2012-04-09 at 09:03 +, Jasen Betts wrote: > On 2012-03-09, Bret Stern wrote: > > We have a concrete batching application composed of two parts. > > 1. The Monitor. > > The Monitor cycles every 60 seconds, and looks into a Postgresql table > > for jobs to run. Primarily these jobs update Postgresql tables with > > data from external applications. > > > > 2. The Client. > > The client schedules orders etc. > > > > When a new product or customer is added to the Accounting or Batching > > Controller (both external applications; and databases) the Client user > > clicks a button and adds a job to run on the Monitor. > > > > Is it possible use the NOTIFY event to serve more like an interrupt, > > and trigger the Monitor to run immediately. > > Reasonably immediately. > > > Can it be used with VB? or Should I use LibPQ? > > I used libpq with VB6 when I needed this feature 3 years ago. > > I had to write a little DLL to wrap the libpq calls so that VB could > call them (actually I repackaged the wrapper that the main application uses) > > > If this is the wrong list for these questions, let me know? > > what language are you really using? VB is kind of vague it could mean > .net (lots of people say VB when they mean .net, makes it hard to get > questions about VB answered) > Was referring VB6 (I still prefer the IDE), but I can write in most languages; (codeblocks for the libpq project). > -- > ⚂⚃ 100% natural > > Thanks for the comments. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: Questions of the privileges to use the pg_cancel_backend and pg_terminate_backend function. Thanks.
Thanks Guys. I wrote this function in a specific schema and granted to the dba users only. Thanks. Problem solved. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Questions-of-the-privileges-to-use-the-pg-cancel-backend-and-pg-terminate-backend-function-Thanks-tp5618129p5627387.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?
On 04/09/2012 03:33 AM, 乔志强 wrote: But after some minutes the master output: requested WAL segment XXX has already been removed the standby output: FATAL: could not receive data from WAL stream: FATAL: requested WAL segment XXX has already been removed Question: Why the master deletes the WAL segment before send to standby in synchronous mode? It is a streaming replication bug ? master server output: LOG: database system was interrupted; last known up at 2012-03-30 15:37:03 HKT LOG: database system was not properly shut down; automatic recovery in progress My question would be, what happened above? In other words what does the log prior to this one show just before the database shutdown? -- Adrian Klaver adrian.kla...@gmail.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [streaming replication] 9.1.3 streaming replication bug ?
On 09.04.2012 13:33, 乔志强 wrote: I use postgresql-9.1.3-1-windows-x64.exe on windows 2008 R2 x64. 1 master and 1 standby. The standby is a synchronous standby use streaming replication (synchronous_standby_names = '*', archive_mode = off), the master output: standby "walreceiver" is now the synchronous standby with priority 1 the standby output: LOG: streaming replication successfully connected to primary Then run the test program to write and commit large blob(10 to 1000 MB bytes rand size) to master server use 40 threads(40 sessions) in loop, The Master and standby is run on the same machine, and the client run on another machine with 100 mbps network. But after some minutes the master output: requested WAL segment XXX has already been removed the standby output: FATAL: could not receive data from WAL stream: FATAL: requested WAL segment XXX has already been removed Question: Why the master deletes the WAL segment before send to standby in synchronous mode? It is a streaming replication bug ? I see if no standby connect to master when synchronous_standby_names = '*', all commit will delay to standby connect to master. It is good. Use a bigger wal_keep_segments? But I think the master should keep all WAL segments not sent to online standby (sync or async). wal_keep_segments shoud be only for offline standby. If use synchronous_standby_names for sync standby, if no online standby, all commit will delay to standby connect to master, So wal_keep_segments is only for offline async standby actually. master server output: LOG: database system was interrupted; last known up at 2012-03-30 15:37:03 HKT LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/136077B0 LOG: record with zero length at 0/17DF1E10 LOG: redo done at 0/17DF1D98 LOG: last completed transaction was at log time 2012-03-30 15:37:03.148+08 FATAL: the database system is starting up LOG: database system is ready to accept connections LOG: autovacuum launcher started / the standby is a synchronous standby LOG: standby "walreceiver" is now the synchronous standby with priority 1 / LOG: checkpoints are occurring too frequently (16 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (23 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (24 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (20 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (22 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". FATAL: requested WAL segment 00010032 has already been removed FATAL: requested WAL segment 00010032 has already been removed FATAL: requested WAL segment 00010032 has already been removed LOG: checkpoints are occurring too frequently (8 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". FATAL: requested WAL segment 00010032 has already been removed standby server output: LOG: database system was interrupted while in recovery at log time 2012-03-30 1 4:44:31 HKT HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. LOG: entering standby mode LOG: redo starts at 0/16E4760 LOG: consistent recovery state reached at 0/12D984D8 LOG: database system is ready to accept read only connections LOG: record with zero length at 0/17DF1E68 LOG: invalid magic number in log file 0, segment 50, offset 6946816 LOG: streaming replication successfully connected to primary FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 00 010032 has already been removed Well, that is not a bug, just activate archive_mode = on on the master server and set also wal_keep_segments = 1000 for example to avoid that situation. I had the same situation, after digging on search engines that was recomended settings. Well I forgot real reason why, may be was too slow sending / receiving data from master / sleave, but this fix the problem. Regards, Condor -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] [streaming replication] 9.1.3 streaming replication bug ?
I use postgresql-9.1.3-1-windows-x64.exe on windows 2008 R2 x64. 1 master and 1 standby. The standby is a synchronous standby use streaming replication (synchronous_standby_names = '*', archive_mode = off), the master output: standby "walreceiver" is now the synchronous standby with priority 1 the standby output: LOG: streaming replication successfully connected to primary Then run the test program to write and commit large blob(10 to 1000 MB bytes rand size) to master server use 40 threads(40 sessions) in loop, The Master and standby is run on the same machine, and the client run on another machine with 100 mbps network. But after some minutes the master output: requested WAL segment XXX has already been removed the standby output: FATAL: could not receive data from WAL stream: FATAL: requested WAL segment XXX has already been removed Question: Why the master deletes the WAL segment before send to standby in synchronous mode? It is a streaming replication bug ? I see if no standby connect to master when synchronous_standby_names = '*', all commit will delay to standby connect to master. It is good. Use a bigger wal_keep_segments? But I think the master should keep all WAL segments not sent to online standby (sync or async). wal_keep_segments shoud be only for offline standby. If use synchronous_standby_names for sync standby, if no online standby, all commit will delay to standby connect to master, So wal_keep_segments is only for offline async standby actually. master server output: LOG: database system was interrupted; last known up at 2012-03-30 15:37:03 HKT LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/136077B0 LOG: record with zero length at 0/17DF1E10 LOG: redo done at 0/17DF1D98 LOG: last completed transaction was at log time 2012-03-30 15:37:03.148+08 FATAL: the database system is starting up LOG: database system is ready to accept connections LOG: autovacuum launcher started / the standby is a synchronous standby LOG: standby "walreceiver" is now the synchronous standby with priority 1 / LOG: checkpoints are occurring too frequently (16 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (23 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (24 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (20 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". LOG: checkpoints are occurring too frequently (22 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". FATAL: requested WAL segment 00010032 has already been removed FATAL: requested WAL segment 00010032 has already been removed FATAL: requested WAL segment 00010032 has already been removed LOG: checkpoints are occurring too frequently (8 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". FATAL: requested WAL segment 00010032 has already been removed standby server output: LOG: database system was interrupted while in recovery at log time 2012-03-30 1 4:44:31 HKT HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. LOG: entering standby mode LOG: redo starts at 0/16E4760 LOG: consistent recovery state reached at 0/12D984D8 LOG: database system is ready to accept read only connections LOG: record with zero length at 0/17DF1E68 LOG: invalid magic number in log file 0, segment 50, offset 6946816 LOG: streaming replication successfully connected to primary FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 00 010032 has already been removed -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Regarding NOTIFY
On 2012-03-09, Bret Stern wrote: > We have a concrete batching application composed of two parts. > 1. The Monitor. > The Monitor cycles every 60 seconds, and looks into a Postgresql table > for jobs to run. Primarily these jobs update Postgresql tables with > data from external applications. > > 2. The Client. > The client schedules orders etc. > > When a new product or customer is added to the Accounting or Batching > Controller (both external applications; and databases) the Client user > clicks a button and adds a job to run on the Monitor. > > Is it possible use the NOTIFY event to serve more like an interrupt, > and trigger the Monitor to run immediately. Reasonably immediately. > Can it be used with VB? or Should I use LibPQ? I used libpq with VB6 when I needed this feature 3 years ago. I had to write a little DLL to wrap the libpq calls so that VB could call them (actually I repackaged the wrapper that the main application uses) > If this is the wrong list for these questions, let me know? what language are you really using? VB is kind of vague it could mean .net (lots of people say VB when they mean .net, makes it hard to get questions about VB answered) -- ⚂⚃ 100% natural -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: Questions of the privileges to use the pg_cancel_backend and pg_terminate_backend function. Thanks.
On 2012-04-04, leaf_yxj wrote: > Hi Aaron: thanks. I tried the security definer. it works well as follows : > > CREATE FUNCTION kill_process(integer) RETURNS boolean AS 'select > pg_cancel_backend($1);' LANGUAGE SQL SECURITY DEFINER; > > One more question about this function : if non-super user get the > execute this function, he/her will have privilege to kill all the processes > which belong to the postgresql process. How can we avoid that happing. revoke execute on function kill_process(integer) from public; grant execute on function kill_process(integer) to db_admin; assuming db_admin is a role granted to all those who you want to have access, you can instead grans execute to each individual (or some combination of those two) -- ⚂⚃ 100% natural -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
