Re: [HACKERS] keepalive in libpq using

On Wed, Jul 7, 2010 at 10:04 PM, Robert Haas wrote: > On Tue, Jul 6, 2010 at 1:08 PM, Pavel Golub wrote: >> While I'm very excited about enabling keepalives in libpq, I want to >> know how can I use this functionality in my application? >> >> Let's imagine that I connect to a server with keepaliv

Re: [HACKERS] ALTER TABLE SET STATISTICS requires AccessExclusiveLock

On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote: > Rereading the thread, I'm a bit confused by why we're proposing to use > a SHARE lock; it seems to me that a self-conflicting lock type would > simplify things. There's a bunch of discussion on the thread about > how to handle pg_class updat

Re: [HACKERS] bitmap indexes - performance

Are these improvements (index creation time, index size) worth enough to keep on working on this? I mean: given that bitmaps don't give any benefits in query times, but only benefits related to disk size and bulk index creation times, and will have horrible performance for insertions/deletions:

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

> Having said that, I do think we urgently need some high-level design > discussion on how sync rep is actually going to handle this issue > (perhaps on a new thread).  If we can't resolve this issue, sync rep > is going to be really slow; but there are no easy solutions to this > problem in sight,

Re: [HACKERS] patch: preload dictionary new version

Pavel Stehule wrote: > this version has enhanced AllocSet allocator - it can use a mmap API. I review your patch and will report some comments. However, I don't have test cases for the patch because there is no large dictionaries in the default postgres installation. I'd like to ask you to sup

Re: [HACKERS] ALTER TABLE SET STATISTICS requires AccessExclusiveLock

On Wed, Jul 7, 2010 at 9:04 PM, Cédric Villemain wrote: >>> > I assume this did not get done for 9.0.  Do we want a TODO item? >>> >>> Yes. >> >> Added: >> >>        Reduce locking required for ALTER commands > > I just faced production issue where it is impossible to alter table to > adjust autov

Re: [HACKERS] ALTER TABLE SET STATISTICS requires AccessExclusiveLock

2010/3/3 Bruce Momjian : > Peter Eisentraut wrote: >> On m?n, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote: >> > Simon Riggs wrote: >> > > On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote: >> > > > Simon Riggs wrote: >> > > > > >> > > > > On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera w

Re: [HACKERS] pg_dump and join aliases (was Re: [BUGS] ERROR: cannot handle unplanned sub-select)

On Wed, Jul 7, 2010 at 7:43 PM, Tom Lane wrote: > Anyway, the way it works is that the parser generates "alias Vars" that > refer to the join RTE, mainly because this makes life simpler for > ruleutils.  But the planner prefers to work with the "real" underlying > columns whenever those are semant

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.

2010/7/8 Josh Berkus : > On 7/6/10 8:06 AM, Tom Lane wrote: >> It might be that nobody's using any values other than 0 and -1 ... >> in which case it wouldn't matter anyway.  I agree that the lack of >> bug reports is notable.  But still, don't we try to avoid behavioral >> changes in stable branch

Re: [HACKERS] Bug? Concurrent COMMENT ON and DROP object

Robert Haas writes: > On Tue, Jul 6, 2010 at 10:59 PM, Alvaro Herrera > wrote: >> Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010: >>> Hmm... so, maybe ShareUpdateExclusiveLock? >> >> So COMMENT ON will conflict with (auto)vacuum?  Seems a bit weird ... > Well, I'm open to

Re: [HACKERS] pg_dump and join aliases (was Re: [BUGS] ERROR: cannot handle unplanned sub-select)

Robert Haas writes: > I'm lost. What's a join alias var? Suppose we have t1 with columns a,b,c and t2 with columns d,e,f, then consider select a from t1 join t2 on (whatever) select t1.a from t1 join t2 on (whatever) In the first case the parser generates a Var that references

Re: [HACKERS] [RRR] Reviewfest 2010-06 Plans and Call for Reviewers

On Mon, Jun 14, 2010 at 12:25 PM, Kevin Grittner wrote: > The PostgreSQL 9.1 Development Plan: > > http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan > > calls for a ReviewFest to run from the 15th of June (tomorrow) until > the start of the first CommitFest for the 9.1 release.  The

Re: [HACKERS] pg_dump and join aliases (was Re: [BUGS] ERROR: cannot handle unplanned sub-select)

On Wed, Jul 7, 2010 at 6:55 PM, Tom Lane wrote: > After some investigation I was able to simplify it to the following > example using the regression database: > > select >  (select sq1) as qq1 > from >  (select exists(select 1 from int4_tbl where f1 = q2) as sq1, 42 as dummy >   from int8_tbl) sq0

[HACKERS] pg_dump and join aliases (was Re: [BUGS] ERROR: cannot handle unplanned sub-select)

Merlin sent me a test case off-list for the problem mentioned here: http://archives.postgresql.org/pgsql-bugs/2010-07/msg00025.php After some investigation I was able to simplify it to the following example using the regression database: select (select sq1) as qq1 from (select exists(select 1

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

On Wed, Jul 7, 2010 at 6:44 PM, Josh Berkus wrote: > On 7/6/10 4:44 PM, Robert Haas wrote: >> To recap the previous discussion on this thread, we ended up changing >> the behavior of 9.0 so that it only sends WAL which has been written >> to the OS *and flushed*, because sending unflushed WAL to t

Re: [HACKERS] Bug? Concurrent COMMENT ON and DROP object

On Tue, Jul 6, 2010 at 10:59 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010: >> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane wrote: >> > Robert Haas writes: >> >> Obviously not.  We don't need to acquire an AccessExclusiveLock to >> >> comment on a

Re: [HACKERS] Re: [COMMITTERS] pgsql: Fix log_temp_files docs and comments to say bytes not kilobytes.

On 7/6/10 8:06 AM, Tom Lane wrote: > It might be that nobody's using any values other than 0 and -1 ... > in which case it wouldn't matter anyway. I agree that the lack of > bug reports is notable. But still, don't we try to avoid behavioral > changes in stable branches? I think most people are

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

On 7/6/10 4:44 PM, Robert Haas wrote: > To recap the previous discussion on this thread, we ended up changing > the behavior of 9.0 so that it only sends WAL which has been written > to the OS *and flushed*, because sending unflushed WAL to the standby > is unsafe. The standby can get ahead of the

Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will

Peter Eisentraut writes: > On tis, 2010-07-06 at 18:15 -0400, Tom Lane wrote: >> At this point it seems clear to me that we've not adequately thought >> through the implications of having two python versions in one >> application namespace, and I'm not sure the Python people have either. >> I thin

Re: [HACKERS] Why is vacuum_defer_cleanup_age PGC_USERSET?

On 7/3/10 10:07 AM, Tom Lane wrote: > It seems to me it ought to be PGC_SIGHUP. +1 I believe it's userset because the other vacuum parameters are, and that nobody thought about it much. -- -- Josh Berkus PostgreSQL Experts

Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will

On tis, 2010-07-06 at 18:15 -0400, Tom Lane wrote: > At this point it seems clear to me that we've not adequately thought > through the implications of having two python versions in one > application namespace, and I'm not sure the Python people have either. > I think we need to do something to blo

Re: [HACKERS] t_self as system column

On Wed, Jul 7, 2010 at 1:29 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mar jul 06 17:24:21 -0400 2010: >> On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote: > >> > In any case, having a mutable logical column >> > position is the feature that's been most requested. >> >

Re: [HACKERS] Python Interface Hacking

On Jul 7, 2010, at 12:07 AM, Peter Froehlich wrote: > I joined this list under the mis-impression that it was about hacking > the Python interfaces to pgsql. Is there possibly another list for > that? Or is the Python stuff just mixed in with all the rest? Sorry > for the meta-question... For BSD/

Re: [HACKERS] cvs to git migration - keywords

On Wed, Jul 7, 2010 at 16:40, Tom Lane wrote: > Dave Page writes: >> On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander wrote: >>> 1) We can migrate the repository with the keywords, and then make one big >>> commit just after (or before, that doesn't make a difference) removing >>> them. In this

Re: [HACKERS] cvs to git migration - keywords

On Wed, Jul 7, 2010 at 20:31, Andrew Dunstan wrote: > > > Robert Haas wrote: >> >> So what happens right now using the existing git repository is that >> the $PostgeSQL$ tags are there, but they're unexpanded.  They just say >> $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$.  I'm all in >> f

Re: [HACKERS] cvs to git migration - keywords

Robert Haas wrote: So what happens right now using the existing git repository is that the $PostgeSQL$ tags are there, but they're unexpanded. They just say $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. I'm all in favor of removing them, but it would be nice if we could avoid clutteri

Re: [HACKERS] t_self as system column

Excerpts from Robert Haas's message of mar jul 06 17:24:21 -0400 2010: > On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote: > > In any case, having a mutable logical column > > position is the feature that's been most requested. > > I think that's true. But the physical storage position woul

Re: [HACKERS] cvs to git migration - keywords

On Wed, Jul 7, 2010 at 10:57 AM, Tom Lane wrote: > Robert Haas writes: >> So what happens right now using the existing git repository is that >> the $PostgeSQL$ tags are there, but they're unexpanded.  They just say >> $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. > > Really?  All of them

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

Excerpts from Takahiro Itagaki's message of mié jul 07 04:39:38 -0400 2010: > BTW, we could have LogicalTapeReadExact() as an alias of > LogicalTapeRead() and checking the result because we have > many duplicated codes for "unexpected end of data" errors. I'd just add a boolean "exact required" t

Re: [HACKERS] Python Interface Hacking

On 07/07/10 17:19, Peter Froehlich wrote: On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut wrote: If you want to hack PL/Python, which is a Python interpreter embedded into the PostgreSQL server, then this is the right place. (Yes, it's mixed with all the rest.) If you want to hack a Python c

[PATCH] Re: [HACKERS] Issue: Deprecation of the XML2 module 'xml_is_well_formed' function

Peter Eisentraut wrote: On lör, 2010-07-03 at 09:26 +0100, Mike Fowler wrote: What I will do instead is implement the xml_is_well_formed function and get a patch out in the next day or two. That sounds very useful. Here's the patch to add the 'xml_is_well_formed' function. Parap

Re: [HACKERS] cvs to git migration - keywords

Tom Lane wrote: >>> 1) We can migrate the repository with the keywords, and then make one big >>> commit just after (or before, that doesn't make a difference) removing >>> them. In this case, backbranches and tags look exactly like they do >>> now, but it also means if you do "git diff" between

Re: [HACKERS] Python Interface Hacking

On Wed, Jul 7, 2010 at 8:49 AM, Peter Eisentraut wrote: > If you want to hack PL/Python, which is a Python interpreter embedded > into the PostgreSQL server, then this is the right place.  (Yes, it's > mixed with all the rest.) > > If you want to hack a Python client driver, then go to > http://in

Re: [HACKERS] Does mbutils.c really need to use L'\0' ?

Takahiro Itagaki writes: > I think all of the following codes work in the same way > at least on Windows, where the codes are actually used. > utf16[dstlen] = L'\0'; > utf16[dstlen] = '\0'; > utf16[dstlen] = 0; > utf16[dstlen] = (WCHAR) 0; The last one seems like the best choice,

Re: [HACKERS] cvs to git migration - keywords

Robert Haas writes: > So what happens right now using the existing git repository is that > the $PostgeSQL$ tags are there, but they're unexpanded. They just say > $PostgreSQL$ rather than $PostgreSQL: tgl blah blah$. Really? All of them? Seems like that would have taken some intentional proce

Re: [HACKERS] cvs to git migration - keywords

* Dave Page [100707 05:05]: > > +1 for #1. Changing history and the resulting possibility of becoming > one's own grandfather always makes me nervous. But, since we're already using CVS, our grandfather is already our granddaughter... I'll just point out that if you "expand" the CVS keywords in

Re: [HACKERS] cvs to git migration - keywords

On Wed, Jul 7, 2010 at 5:01 AM, Magnus Hagander wrote: > In the previous discussions of how to migrate from cvs to git, we've > all agreed we should kill the keyword expansion that we have now. I > don't think, however, that we ever decided what to do with the *old* > keywords. We did say we want

Re: [HACKERS] cvs to git migration - keywords

On Wed, Jul 7, 2010 at 3:40 PM, Tom Lane wrote: > One point that isn't completely clear from Magnus' description is > whether we should remove the $PostgreSQL$ lines from the HEAD branch > only, or from the still-active back branches as well.  I vote for the > latter --- that is, if you pull a his

Re: [HACKERS] cvs to git migration - keywords

Dave Page writes: > On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander wrote: >> 1) We can migrate the repository with the keywords, and then make one big >> commit just after (or before, that doesn't make a difference) removing >> them. In this case, backbranches and tags look exactly like they do

Re: [HACKERS] cvs to git migration - keywords

Magnus Hagander wrote: In the previous discussions of how to migrate from cvs to git, we've all agreed we should kill the keyword expansion that we have now. I don't think, however, that we ever decided what to do with the *old* keywords. We did say we want to be able to reproduce backbranches/

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

Tom Lane writes: > Dimitri Fontaine writes: >> Stop me if I'm all wrong already, but I though we said that we should >> handle this case by decoupling what we can send to the standby and what >> it can apply. > > What's the point of that? It won't make the standby apply any faster. True, but it

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

Dimitri Fontaine writes: > Stop me if I'm all wrong already, but I though we said that we should > handle this case by decoupling what we can send to the standby and what > it can apply. What's the point of that? It won't make the standby apply any faster. What it will do is make the protocol mo

Re: [HACKERS] multibyte-character aware support for function "downcase_truncate_identifier()"

Rajanikant Chirmade writes: > Every identifier is downcase & truncated by function > "downcase_truncate_identifier()" > before using it. > But since the function "downcase_truncate_identifier()" is not > multibyte-charecter aware, > it is not able to downcase some of special charecters in identif

Re: [HACKERS] Keepalives win32

Robert Haas wrote: (BTW, there are two buildfarm machines - wigeon and orangutan - that are consistently failing with rather bizarre error messages. Are these real failures or are those machines just messed up?) Dave and Scott, please investigate these errors in your buildfarm members.

Re: [HACKERS] Keepalives win32

Magnus Hagander wrote: > It'll now set them to 2 hours/1 second by default. I looked > quickly at the RFC and didn't find the exact values there, so those > values are the documented out-of-the-box defaults on Windows. I > can easily change them to RFC values if someone can find them for > me :)

Re: [HACKERS] Keepalives win32

On Wed, Jul 7, 2010 at 9:20 AM, Magnus Hagander wrote: > On Wed, Jun 30, 2010 at 17:46, Tom Lane wrote: >> "Kevin Grittner" writes: >>> I also think we may want to suggest that for most environments, >>> people may want to change these settings to something more >>> aggressive, like a 30 to 120

Re: [HACKERS] Keepalives win32

On Wed, Jun 30, 2010 at 17:46, Tom Lane wrote: > "Kevin Grittner" writes: >> I also think we may want to suggest that for most environments, >> people may want to change these settings to something more >> aggressive, like a 30 to 120 second initial delay, with a 10 or 20 >> second retry interval

Re: [HACKERS] keepalive in libpq using

On Tue, Jul 6, 2010 at 1:08 PM, Pavel Golub wrote: > While I'm very excited about enabling keepalives in libpq, I want to > know how can I use this functionality in my application? > > Let's imagine that I connect to a server with keepalives option, other > options (keepalives_idle, keepalives_int

Re: [HACKERS] Partitioning syntax

On Wed, Jul 7, 2010 at 2:14 AM, Takahiro Itagaki wrote: >> 5. The use of the term "partition" is not very consistent.  For >> example, we use CREATE PARTITION to create a partition, but we use >> DROP TABLE to get rid of it (there is no DROP PARTITION).  I think >> that the right syntax to use her

Re: [HACKERS] Python Interface Hacking

On ons, 2010-07-07 at 03:07 -0400, Peter Froehlich wrote: > I joined this list under the mis-impression that it was about hacking > the Python interfaces to pgsql. Is there possibly another list for > that? Or is the Python stuff just mixed in with all the rest? Sorry > for the meta-question... If

Re: [HACKERS] Python Interface Hacking

On Wed, Jul 7, 2010 at 3:07 AM, Peter Froehlich wrote: > I joined this list under the mis-impression that it was about hacking > the Python interfaces to pgsql. Is there possibly another list for > that? Or is the Python stuff just mixed in with all the rest? Sorry > for the meta-question... Well

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

On Wed, Jul 7, 2010 at 4:40 AM, Dimitri Fontaine wrote: > Stop me if I'm all wrong already, but I though we said that we should > handle this case by decoupling what we can send to the standby and what > it can apply. We could do this by sending the current WAL fsync'ed > position on the master in

Re: [HACKERS] cvs to git migration - keywords

On Wed, Jul 7, 2010 at 10:01 AM, Magnus Hagander wrote: > 1) We can migrate the repository with the keywords, and then make one big > commit just after (or before, that doesn't make a difference) removing > them. In this case, backbranches and tags look exactly like they do > now, but it also mean

[HACKERS] cvs to git migration - keywords

In the previous discussions of how to migrate from cvs to git, we've all agreed we should kill the keyword expansion that we have now. I don't think, however, that we ever decided what to do with the *old* keywords. We did say we want to be able to reproduce backbranches/tags *identically* to what

Re: [HACKERS] Proposal for 9.1: WAL streaming from WAL buffers

Robert Haas writes: > If it's unsafe to send written but unflushed WAL to the standby, then > for the same reasons we can't send unwritten WAL either. [...] > Having said that, I do think we urgently need some high-level design > discussion on how sync rep is actually going to handle this issue S

Re: I: [HACKERS] About "Our CLUSTER implementation is pessimal" patch

Leonardo F wrote: > I saw that you also changed the writing: (snip) > Are we sure it's 100% equivalent? I think writetup_rawheap() and readtup_rawheap() are a little complex, but should work as long as there are no padding between t_len and t_self in HeapTupleData struct. - It might be cleaner

[HACKERS] Python Interface Hacking

Hi all, I joined this list under the mis-impression that it was about hacking the Python interfaces to pgsql. Is there possibly another list for that? Or is the Python stuff just mixed in with all the rest? Sorry for the meta-question... Cheers, Peter -- Peter H. Froehlich