[HACKERS] datistemplate of pg_database does not behave as per description in documentation

code change. After modification, result will be as follows: postgres=# create database newtempdb template postgres; ERROR: DB name "postgres" given as template is not a template database Please provide your feedback. Thanks and Regards, Kumar Rajeev Rastogi datistemplate_i

Re: [HACKERS] datistemplate of pg_database does not behave as per description in documentation

On 27 March 2014 17:16, Tom Lane Wrote: > I agree we need to make the docs match the code, but changing behavior > that's been like that for ten or fifteen years isn't the answer. Sounds good. Please find the attached patch with only documentation change. Thanks and Regar

[HACKERS] Observed an issue in CREATE TABLE syntax

attached patch with the fix. Thanks and Regards, Kumar Rajeev Rastogi multiconstissuev1.patch Description: multiconstissuev1.patch -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [review] PostgreSQL Service on Windows does not start if data directory given is relative path

On 05 April 2014 04:14, Tom Lane > > [ pgctl_win32service_rel_dbpath_v6.patch ] > > Committed with minor corrections, mostly but not all cosmetic. Thanks a lot... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.

Re: [HACKERS] Autonomous Transaction (WIP)

to finish this feature in multiple rounds i.e. first patch, we can try to support autonomous transaction from standalone SQL-command only, which will set-up infrastructure for future work in this area. Using the WIP patch sent, I have done basic testing and it works fine. Any comments? Tha

Re: [HACKERS] Autonomous Transaction (WIP)

are right. I am not planning to support only using plpgsql. Initially we can support this Using the standalone SQL-commands and then later we can enhance based on this infrastructure to be used using plpgsql, triggers. Thanks and Regards, Kumar Rajeev Rastogi

Re: [HACKERS] Proposal: COUNT(*) (and related) speedup

equivalent to iterative count(*), which might degrade performance for VACUUM. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Autonomous Transaction (WIP)

s transaction 107 will be as below: Xmin: 100 Xmax: 109 Snapshot->xip[]: 100, 101, 102, 103, 105, 106 Snapshot->subxip[]: 104 Thanks and Regards, Kumar Rajeev Rastogi

Re: [HACKERS] Autonomous Transaction (WIP)

Yes I am changing both. But no specific changes were required. During commit and assignment of autonomous transaction, it is automatically taken care. Any comment/feedback/doubt are welcome? Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] Autonomous Transaction (WIP)

issue. Thanks and Regards, Kumar Rajeev Rastogi

[HACKERS]

state at AT >start/commit/rollback. Sorry, I haven't looked at your WIP patch yet. For some of the resources, I have already written AtATStart/AtATEOX kind of routines in WIP patch. Comments/feedbacks/doubts are welcome. Thanks and Regards, Kumar Rajeev Rastogi

Re: [HACKERS] Autonomous Transaction (WIP)

state at AT >start/commit/rollback. Sorry, I haven't looked at your WIP patch yet. For some of the resources, I have already written AtATStart/AtATEOX kind of routines in WIP patch. Comments/feedbacks/doubts are welcome. Thanks and Regards, Kumar Rajeev Rastogi

Re: [HACKERS] Autonomous Transaction (WIP)

to keep it less impacting incase it is not configured. An autonomous transaction can also conflict with main transaction, so in order to check conflict between them, I am distinguishing at this level. Please correct me If I am wrong anywhere and also please provide your thought on this and on ove

Re: [HACKERS] Autonomous Transaction (WIP)

e re-used along with your new design. Also if possible you can share your design (even rough is OK), I will see if I can contribute to that in some-way. Thanks and Regards, Kumar Rajeev Rastogi

Re: [HACKERS] So why is EXPLAIN printing only *plan* time?

ime" for the same query with same statistics will become variable depending on the amount of time it had to wait to acquire lock, which will be bit confusing for users. May be if we really have to print other time (i.e. parsing + analyzing + rewrite), then IMHO we can print with some d

Re: [HACKERS] Allowing empty target list in SELECT (1b4f7f93b4693858cb983af3cd557f6097dab67b)

_table(); IMO, this might be useful for dynamic use of table (later column might be added using 'ALTER') or to use as abstract ancestor in class hierarchy. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal for CSN based snapshots

On 12 May 2014 19:27, Heikki Linnakangas Wrote: > On 01/24/2014 02:10 PM, Rajeev rastogi wrote: > > We are also planning to implement CSN based snapshot. > > So I am curious to know whether any further development is happening > on this. > > I started looking into this,

Re: [HACKERS] Proposal for CSN based snapshots

ow-stopper. This can be optimized later by method as you mentioned and also by some cut-off technique based on which we can decide that a XID beyond a certain range will be always visible, and thereby avoiding look-up in pg_clog. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

<    1   2