Re: [GENERAL] cloning postgres-xc

void a lot of duplicates and can also quickly do a "git diff" between files of these two projects. I find that very convenient at times. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-general mailing list (pgsql-general@postgresql.

Re: [GENERAL] Order of granting with many waiting on one lock

int. */ Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- 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] REINDEX deadlock - Postgresql -9.1

e causing this kind of deadlock (or livelock, not sure what is a better term to describe this situation) Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.p

Re: [GENERAL] REINDEX deadlock - Postgresql -9.1

involved in the deadlock to gdb and print the call stack. That may or may not be useful, but given your situation I wonder if you have a deadlock at LWLock level. Do you have any external module installed ? Or any triggers written in C ? Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/i

Re: [GENERAL] Unusually high IO for autovacuum worker

blem and reduce the frequency of auto-analyze on the table or see if you can completely avoid insert/delete on the parent table. ALTER TABLE vehicle_position SET (autovacuum_analyze_threshold = 20); Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee

Re: [GENERAL] Unusually high IO for autovacuum worker

them are HOT updates, so your tables should not bloat too much. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee

Re: [GENERAL] Unusually high IO for autovacuum worker

that you're seeing. Did you change any other parameters like checkpoint timeout/segments etc ? It might be worthwhile to log checkpoint activities as well to be doubly sure. Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee -- Sent via pgsql-general mailing list (pgsql-ge

Re: [GENERAL] Revoke "drop database" even for superusers?

omething else... > > While I haven't looked at the code, the error message looks very similar to what you will see while building contrib modules. So try this: $ export USE_PGXS=1 $ export PATH=$path_to_your_pg_config$:$PATH Set the PATH so that the correct pg_config command is used. It must come from the same installation that your server is running. $ make clean $ make $ make install Thanks, Pavan -- Pavan Deolasee http://www.linkedin.com/in/pavandeolasee

Re: [GENERAL] ERROR: volatile EquivalenceClass has no sortref

On Thu, Nov 22, 2012 at 11:08 AM, Ranjeet Dhumal wrote: > Hi Tom , > > Sorry but i didn't understand that If this is a bug from postgres version > then how the same query will be worked if i recreated the tables and with > same version of postgres. > > This could be related to the plans that are

Re: [GENERAL] values from txid_current()

On Wed, Sep 5, 2012 at 10:53 PM, Sahagian, David wrote: > > > Why are the Messages displayed by my pgAdmin sql window like this . . . > INFO: 7902 > INFO: 7903 > INFO: 7904 > instead of what I expected . . . > INFO: 7902 > INFO: 7904 > INFO: 7906 > ??? > > Are you sure those ALTER TABLE com

Re: [GENERAL] Where is the char and varchar length in pg_catalog for function input variables

On Wed, Sep 5, 2012 at 9:10 PM, jam3 wrote: > I have searched and searched and just cannot find the maximum lengths for > input variables in a function > > i.e. > > CREATE FUNCTION test(input1 char(5), input2 varchar(50)) > RETURNS void AS > $$RAISE NOTICE('%,%'), $1, $2;$$ > LANGUAGE plpgsql; >

Re: [GENERAL] Databas has no Object Identifier Types & Functions

On Tue, Sep 4, 2012 at 3:58 PM, Rebecca Clarke wrote: > Hi there, > > I'm running postgresql 8.4 on a debian system. I have a database that has > no object identifier types and functions in the pg_catalog, > e.g. regclass, regclassout. > > Are you sure you don't have them ? I thought regclass is

[GENERAL] Re: [GENERAL] UPDATE RULE to be invoked when UPDATE .. WHERE fails the WHERE predicate ?‏

On Thu, Aug 30, 2012 at 6:31 PM, John Lumby wrote: > > I would like to use an UPDATE RULE to modify the action performed > when any UPDATE is attempted on a certain table, > *including* an UPDATE which would fail because of no rows matching the > WHERE. > > Is this at all possible?I have trie

Re: [GENERAL] Vacuum as "easily obtained" locks

taken and the table is compacted, but remember that it will block out your select queries until the command completes. Thanks, Pavan -- Pavan Deolasee EnterpriseDB     http://www.enterprisedb.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] RCA for MemoryContextAlloc: invalid request size(Known Issue)

. If you are willing, you could read the release notes of those missing releases to check if there was any fix related to data corruption. I think the best thing to upgrade to the latest point release as soon as possible. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.c

Re: [GENERAL] RCA for MemoryContextAlloc: invalid request size(Known Issue)

data and do further operations which leads to failure. For example, the tuple length may be corrupted and you try to copy that tuple to memory. That's when the palloc can fail with the error. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via

Re: [GENERAL] tune postgres for UPDATE

l free up the space used by the old (now DEAD) tuples and the second update will reuse that, at least for for the most common cases. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [GENERAL]transaction isolation level in plpgsql function

. You are already inside a transaction when plpgsql function is called and there is no way to commit and start new transaction inside plpgsql. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [GENERAL] Default fill factor for tables?

has undergone many changes and the current implementation does not have any restriction about the row length changes. But a necessary condition is to have enough free space in the block (and of course not changing any index columns). You can find the latest README in the source code under src/ba

Re: [GENERAL] Need for help!

ot; is the size of the buffer pool which Postgres uses to cache the data blocks. "effective_cache_size" is usually size of the shared buffer plus estimate of whatever data OS can cache. Planner uses this approximation to choose right plan for execution. http://www.postgresql.org/docs/8.3

Re: [GENERAL] Non completing Vacuumdb

before ending. Is > there a debugging or diagnostic facility available? Did you try vacuumdb -v ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.po

Re: [GENERAL] Need for help!

hmmax to 3GB and share buffer to 2GB, it > runs. Don't know why, can you explain? That doesn't make sense. I am guessing that you are running a 32 bit OS. 4GB of shmmax won't work on a 32 bit OS. Thanks, Pavan Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent

Re: [GENERAL] Problem with transaction isolation level

at transaction commits before the second UPDATE comes out of wait, then the second UPDATE would execute successfully. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.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] Need to update all my 60 million rows at once without transactional integrity

ot performed, but the changes are permanently recorded on the old tuple. In case of crash or transaction abort, the updates can not be rolled back. Also, you may want to take an exclusive lock on the relation before you start the update. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.ent

Re: [GENERAL] Need to update all my 60 million rows at once without transactional integrity

one of the previous batches. But if the updates are happening sequential, then the blocks which were updated previously would never be touched again and hence no space will be freed. If you are updating one row at a time (in a separate transaction) or if the batch updates are kind of scattered,

Re: [GENERAL] How is statement level read consistency implemented?

er/transactions.pdf Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.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] Postgres on shared network drive

known implementation of such a set up would be Oracle RAC, where > you have a shared storage and N machines using it. > Oracle RAC is a multi-master kind of architecture where each node has access to the shared storage and can directly read/write data. Thanks, Pavan -- Pavan Deolasee

Re: [GENERAL] begin transaction locks out other connections

e. Triggers that are declared as "constraint triggers" are also affected." Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.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] Postgres on shared network drive

t; I wonder if it would make sense to add support to mount database in *read-only* mode from multiple servers though. I am thinking about data warehouse kind of operations where multiple servers can be used answer read-only queries. Is there a use case for such applications in real world ? Than

Re: [GENERAL] begin transaction locks out other connections

ed constraint checks. They are checked at the execution time, instead of commit time. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.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] Problem after VACUUM ANALYZE

e entire > process. > I believe plan-invalidation in 8.3 should address this. Isn't it ? Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.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: [HACKERS] [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

On Fri, Apr 4, 2008 at 11:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > The > policy of this project is that we only put nontrivial bug fixes into > back branches, and I don't think this item qualifies ... > Got it. I will submit a patch for HEAD. Thanks, Pav

Re: [HACKERS] [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

On Thu, Apr 3, 2008 at 10:39 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Pavan Deolasee" <[EMAIL PROTECTED]> writes: > > > Thanks. I had another concern about VACUUM not reporting DEAD line > > pointers (please see up thread). Any comments on that ? > &

Re: [HACKERS] [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

On Thu, Apr 3, 2008 at 10:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > > I've applied a modified/extended form of this patch for 8.3.2. > Thanks. I had another concern about VACUUM not reporting DEAD line pointers (please see up thread). Any comments on that ? Thanks, Pavan

Re: [HACKERS] [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

can make heap_page_prune() to only return number of HOT tuples pruned and then explicitly count the DEAD line pointers in tups_vacuumed. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com Analyze-fix.patch.gz Description: GNU Zip compressed data -- Sent via

Re: [HACKERS] [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

h anyway --- it always examines all line pointers > on each selected page, so we might as well rewrite it to use a simple > loop more like vacuum uses. > I agree. I would write a patch on these lines, unless you are already on to it. Thanks, Pavan -- Pavan Deolasee Enterpris

Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

so update the FSM information of a page when its pruned/defragged so that the page can also be used for subsequent INSERTs or non-HOT UPDATEs in other pages. This might be easier said than done. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-g

Re: [GENERAL] Table size

On Fri, Mar 21, 2008 at 10:25 PM, Pavan Deolasee <[EMAIL PROTECTED]> wrote: > > Oh cool.. I did not such facility exists. > I meant, "I did not know such facility exists" Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via p

Re: [GENERAL] Table size

On Fri, Mar 21, 2008 at 10:12 PM, Andreas Kretschmer <[EMAIL PROTECTED]> wrote: > > Comments on objects can set by: > > comment on ... is 'comment'; > Oh cool.. I did not such facility exists. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enter

Re: [GENERAL] Table size

elation_size('mytable'); Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.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] Row size overhead

gnment in the tuple itself. Try moving booleans and char(3) at the end. There is not much you can do with other overheads. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

Re: [GENERAL] 8.3.0 upgrade

columns, HOT update is feasible. So even if the UPDATE statement sets value to one of the index columns, HOT update is possible as long as the old and the new value is same. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-

Re: [GENERAL] pgbench not setting scale size correctly?

g somewhere? You must have initialized pgbench with scale 1. While running the tests, it will pick up the scale factor with which it was initialized Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.

Re: [GENERAL] Reindex does not finish 8.2.6

is holding a lock on the table ? Note that REINDEX would block even some other transaction is inserting/deleting/updating the table. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make chan

Re: [GENERAL] autovacuum not freeing up unused space on 8.3.0

; doesn't recover the space. Regular external VACUUMs keep the table at > around 10MB but if I use autovacuum and it grows to 40MB, a VACUUM FULL > will only get it down to 35MB. Is it possible that a canceled autovacuum > could result in permanently lost space? > AFAIK it

Re: [GENERAL] Postgres 8.3 HOT and non-persistent xids

t an update with redundant > information, e.g. > > update T set A=2,B=4 where A=2; > > The value of A hasn't changed, does postgres still write the value? > Yes. Every update generates a new version of the row. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.

Re: [GENERAL] Problem with autovacuum and pg_autovacuum

pg_autovacuum table ? A very small value can trigger XID wraparound related VACUUMs in every run. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com

Re: [GENERAL] Vacuuming

On 5/8/07, Tom Lane <[EMAIL PROTECTED]> wrote: SnapshotAny is a no-op, but HeapTupleSatisfiesVacuum isn't. Oh yes. My apologies for forgetting IndexBuildHeapScan() Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com

Re: [GENERAL] Vacuuming

On 5/8/07, Tom Lane <[EMAIL PROTECTED]> wrote: I forgot to mention that any other operation that examines every table row will fix all the hint bits as well. In particular a CREATE INDEX would do that --- I might be missing something, but I think CREATE INDEX work on SnapshotAny and hence m

Re: [GENERAL] Strange result using transactions

On 3/27/07, Tom Lane <[EMAIL PROTECTED]> wrote: "Matthijs Melissen" <[EMAIL PROTECTED]> writes: > I am executing the following queries (id has a unique key): > 1) begin; > 1) delete from forum where id = 20; > 1) insert into forum (id, name) values (20, 'test'); > 2) delete from forum where id =

Re: [GENERAL] [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)

On 2/24/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote: Pavan Deolasee: HOT ( never met him ) I am working on it with the target of 8.3. I am posting WIP patches since couple of weeks. One of the objectives of publishing WIP patches, even though they are not well tested (for correctn

Re: [GENERAL] Dumb question - how to tell if autovacuum is doing its job in 8.2.x

On 2/13/07, Walter Vaughan <[EMAIL PROTECTED]> wrote: select last_autovacuum, last_autoanalyze from pg_stat_all_tables; last_autovacuum | last_autoanalyze -+-- | ...snip lots of identically blank lines... |

Re: [GENERAL] Autovacuum Improvements

Simon Riggs wrote: > On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote: >> Christopher Browne wrote: >> >>> Seems to me that you could get ~80% of the way by having the simplest >>> "2 queue" implementation, where tables with size < some threshold get >>> thrown at the "little table" queue,

Re: [GENERAL] Autovacuum Improvements

Simon Riggs wrote: On Fri, 2006-12-29 at 20:25 -0300, Alvaro Herrera wrote: Christopher Browne wrote: Seems to me that you could get ~80% of the way by having the simplest "2 queue" implementation, where tables with size < some threshold get thrown at the "little table" queue, and tables above