[HACKERS] Invitation to connect on LinkedIn

LinkedIn Gourish Singbal souhaite se connecter à vous sur LinkedIn : -- Amine, I'd like to add you to my professional network on LinkedIn. - Gourish Accepter l'invitation de Gourish Singbal http://www.linkedin.com/e/cm7uxn-gbbsl8em-2n/VWCdriNH

Re: [HACKERS] Partitioning syntax

Robert Haas wrote: > I've taken a little bit more of a look at this patch and I guess I'm > not too happy with the design. Thanks. I was thinking about only syntax for partitioning in the patch, but I need more consideration about insert-aware catalog design. > 5. The use of the term "partitio

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

Hi All, 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 identifier like "my_SchemÄ". If schema

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

Tom Lane wrote: > >> I'm dubious that it's worth the trouble. I suggest that it might be > >> best to replace these usages of L'\0' by plain scalar 0. > I'd tend to go with just 0, > which is a reasonably common substitute for non-wide '\0' ... I think all of the following codes work in the sa

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

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 an object - just something that will CONFLICT WITH an > >> Acce

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

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 an object - just something that will CONFLICT WITH an >> AccessExclusiveLock.  So, use the same locking rules, perhaps, but >> take a much wea

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

Robert Haas writes: > Obviously not. We don't need to acquire an AccessExclusiveLock to > comment on an object - just something that will CONFLICT WITH an > AccessExclusiveLock. So, use the same locking rules, perhaps, but > take a much weaker lock, like AccessShareLock. Well, it probably needs

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

2010/7/6 KaiGai Kohei : > (2010/07/06 23:33), Tom Lane wrote: >> Robert Haas  writes: >>> 2010/7/6 KaiGai Kohei: In the following scenario, we can see orphan comments. >> >>> Yeah.  I think the reason we haven't seen any complaints about this >>> before is that the worst-case scenario is that

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

(2010/07/06 23:33), Tom Lane wrote: > Robert Haas writes: >> 2010/7/6 KaiGai Kohei: >>> In the following scenario, we can see orphan comments. > >> Yeah. I think the reason we haven't seen any complaints about this >> before is that the worst-case scenario is that a comment for a dropped >> data

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

On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao wrote: > In 9.0, walsender reads WAL always from the disk and sends it to the standby. > That is, we cannot send WAL until it has been written (and flushed) to the > disk. > This degrades the performance of synchronous replication very much since a > t

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

On Tue, Jul 6, 2010 at 5:49 PM, Greg Smith wrote: > I was never arguing in favor of touching anything in the back branches; if > you recall I didn't even voice an opinion here until I got concerned about > too many changes happening in them.  I think a proper fix in 9.0 combined > with a release n

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

Andrew Dunstan writes: > Tom Lane wrote: >> I'm dubious that it's worth the trouble. I suggest that it might be >> best to replace these usages of L'\0' by plain scalar 0. Does anyone >> think that wouldn't work or is too grotty? > or maybe 0x, which I gather from >

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 17:49 -0400, Tom Lane wrote: >> Crash? I can see people regarding that as a security problem. Maybe we >> need to do something more pro-active to prevent such conflicts? > I don't see how. Loading any module that uses the same symbols as > anoth

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

On Tue, 2010-07-06 at 17:49 -0400, Tom Lane wrote: > pet...@postgresql.org (Peter Eisentraut) writes: > > Log Message: > > --- > > Add note that using PL/Python 2 and 3 in the same session will probably > > crash > > Crash? I can see people regarding that as a security problem. Maybe we

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

Tom Lane wrote: I grow weary of mopping up after pgindent, as in http://archives.postgresql.org/pgsql-committers/2010-07/msg00069.php The problem evidently is that pgindent hasn't heard of wide character constants. No doubt the best fix would be to teach it about them; but given that we seem

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

On tis, 2010-07-06 at 17:49 -0400, Tom Lane wrote: > pet...@postgresql.org (Peter Eisentraut) writes: > > Log Message: > > --- > > Add note that using PL/Python 2 and 3 in the same session will probably > > crash > > Crash? I can see people regarding that as a security problem. Maybe we

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

pet...@postgresql.org (Peter Eisentraut) writes: > Log Message: > --- > Add note that using PL/Python 2 and 3 in the same session will probably crash Crash? I can see people regarding that as a security problem. Maybe we need to do something more pro-active to prevent such conflicts?

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

Robert Haas wrote: Bruce felt it wasn't worth putting that amount of work into backbranch docs that nobody's likely to read anyway, but I suppose that view could be overruled if there's a strong consensus. I was never arguing in favor of touching anything in the back branches; if you reca

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

I grow weary of mopping up after pgindent, as in http://archives.postgresql.org/pgsql-committers/2010-07/msg00069.php The problem evidently is that pgindent hasn't heard of wide character constants. No doubt the best fix would be to teach it about them; but given that we seem to have next to no u

Re: [HACKERS] t_self as system column

Robert Haas writes: > On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote: >> Why wouldn't it be feasible? > Just because it might be too much to do all at once. My thought is that the hardest part of this is going to be making sure that every "column index" usage in the code is properly categ

Re: [HACKERS] t_self as system column

On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan wrote: >> I have a strong suspicion that's going to be a, ahem, challenging >> project.  But it would be great to have.  Getting rid of the system >> column entries from pg_attribute is probably easy by comparison. > > It will be a bit invasive, but I

Re: [HACKERS] keepalives on MacOS X

On Fri, Jul 2, 2010 at 5:44 PM, Robert Haas wrote: > On Tue, Jun 29, 2010 at 10:53 PM, Fujii Masao wrote: >> On Tue, Jun 29, 2010 at 11:28 PM, Robert Haas wrote: >>> On Tue, Jun 29, 2010 at 12:42 AM, Tom Lane wrote: Yeah, a bit of rooting around in the Darwin sources shows that this v

Re: [HACKERS] t_self as system column

Robert Haas wrote: On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera wrote: I'm intending to work on logical column identifiers for 9.1. Perhaps I could try to have a look at this, too, while at it. I have a strong suspicion that's going to be a, ahem, challenging project. But it wo

Re: [HACKERS] t_self as system column

On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera wrote: > Excerpts from Robert Haas's message of mar jul 06 10:08:21 -0400 2010: > >> Treating OID as a user-defined column seems reasonable, and probably >> not even that messy if we put some appropriate macros in place.  I'm >> guessing the messy par

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

On Tue, Jul 6, 2010 at 3:40 PM, Greg Smith wrote: > Robert Haas wrote: >> >> OK, so I talked to Bruce about this and I guess I've been persuaded >> that we should just apply the patch I sent upthread to HEAD and leave >> the back-branches broken, for fear of creating an incompatibility. >> > > The

Re: [HACKERS] t_self as system column

Excerpts from Robert Haas's message of mar jul 06 10:08:21 -0400 2010: > Treating OID as a user-defined column seems reasonable, and probably > not even that messy if we put some appropriate macros in place. I'm > guessing the messy part would be finding all the places that expect to > be consult

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

Robert Haas wrote: OK, so I talked to Bruce about this and I guess I've been persuaded that we should just apply the patch I sent upthread to HEAD and leave the back-branches broken, for fear of creating an incompatibility. The only thing that might be appropriate to backport is the docs fix

Re: [HACKERS] logistics for beta3

Robert Haas wrote: > On Mon, Jul 5, 2010 at 3:14 PM, Andrew Dunstan wrote: > > Andrew Dunstan wrote: > >> Marc G. Fournier wrote: > - Someone (presumably Bruce) needs to run pgindent. ?Any reason to > wait any longer on that? > >> > >> The typedefs list on the buildfarm needs to be refre

Re: [HACKERS] logistics for beta3

On mån, 2010-07-05 at 11:01 -0400, Tom Lane wrote: > Peter was suggesting that if we *stopped* using RTLD_GLOBAL then it > might be possible to use plpython2 and plpython3 concurrently in one > backend. After looking at the archives I'm not convinced that's > workable --- it sounds like not using

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

On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane wrote: >>> Changing the unit setting would also be a behavioral change.  I think >>> what Bruce is suggesting is that this is simply not worth worrying about >>> in the back branch

Re: [HACKERS] Partitioning syntax

On Thu, Jun 17, 2010 at 9:34 PM, Takahiro Itagaki wrote: > Jaime Casanova wrote: >> This one, doesn't apply to head anymore... please update > > Thank you for reviewing my patch! > > I attached an updated patch set for partitioning syntax. I've taken a little bit more of a look at this patch and

[HACKERS] keepalive in libpq using

Hello all. 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_interval, keepalives_count) are used either. Then ne

Re: [HACKERS] TRUNCATE+COPY optimization and --jobs=1 in pg_restore

2010/2/10 Takahiro Itagaki > > Tom Lane wrote: > > > Takahiro Itagaki writes: > > > We have an optimization to bulkload date in pg_restore, but the code > > > only works in parallel restore (--jobs >= 2). Why don't we do the > > > same optimization in the serial restore (--jobs = 1) ? > > > > T

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

On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane wrote: > without any field complaints, I refer you to Simon's original commit message: "Bug found during recent performance tuning for PostgreSQL user." -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent v

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

Robert Haas writes: > On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane wrote: >> Changing the unit setting would also be a behavioral change.  I think >> what Bruce is suggesting is that this is simply not worth worrying about >> in the back branches. > It seems pretty strange not to at least document

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

On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian wrote: >>> Anything backpatched risks causing instability, and might discourage >>> people from performing minor upgrades.  Minor fixes are rarely worth the >>> risk of causin

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

Robert Haas writes: > On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian wrote: >> Anything backpatched risks causing instability, and might discourage >> people from performing minor upgrades.  Minor fixes are rarely worth the >> risk of causing instability in back-branches. > OK. Well, in that ca

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

Robert Haas writes: > The reason I think it's OK to change the behavior in the back-branches > is that (a) the only thing it affects is logging, so it shouldn't > really "break" anything, and (b) apparently nobody has noticed that > the interpretation of the GUC is off by three orders of magnitude

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

On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian wrote: > Robert Haas wrote: >> I think my least favorite option is changing the behavior only in >> HEAD.  I think the reasonable options are: >> >> 1. Change the behavior in HEAD, 8.4, and 8.3, per previous discussion. >>  If we do this, we should do

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

Robert Haas wrote: > I think my least favorite option is changing the behavior only in > HEAD. I think the reasonable options are: > > 1. Change the behavior in HEAD, 8.4, and 8.3, per previous discussion. > If we do this, we should do what I proposed in my previous email. > > 2. Change the com

Re: [HACKERS] 64-bit pgbench V2

On Tue, Jul 6, 2010 at 11:01 AM, Greg Smith wrote: > Robert Haas wrote: >> >> It doesn't seem very palatable to have multiple handwritten integer >> parsers floating around the code base either.  Maybe we should try to >> standardize something and ship it in src/port, or somesuch > > I was conside

Re: [HACKERS] 64-bit pgbench V2

Robert Haas wrote: It doesn't seem very palatable to have multiple handwritten integer parsers floating around the code base either. Maybe we should try to standardize something and ship it in src/port, or somesuch I was considering at one point making two trips through strtol, each allowed t

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

On Tue, Jul 6, 2010 at 10:42 AM, Tom Lane wrote: > Robert Haas writes: >> log_temp_files was introduced in 8.3, so we'll need to backpatch this >> to 8.3, not just 8.4.  Greg Smith tells me Simon has been busy with >> other things, so I'm going to pick this up.  Barring objections, I'm >> going t

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

Robert Haas wrote: On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus wrote: Shouldn't this be backpatched, or was this a new bug in 9.0? We've always output bytes. I'd have noticed the discrepancy myself if I'd read the actual docs ;-) KB would be more useful. And I don't think peopl

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

Robert Haas writes: > log_temp_files was introduced in 8.3, so we'll need to backpatch this > to 8.3, not just 8.4. Greg Smith tells me Simon has been busy with > other things, so I'm going to pick this up. Barring objections, I'm > going to revert Simon's patch and change the behavior instead,

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

Robert Haas writes: > 2010/7/6 KaiGai Kohei : >> In the following scenario, we can see orphan comments. > Yeah. I think the reason we haven't seen any complaints about this > before is that the worst-case scenario is that a comment for a dropped > database object eventually becomes associated wi

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

On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus wrote: > >>> Shouldn't this be backpatched, or was this a new bug in 9.0? > > We've always output bytes.  I'd have noticed the discrepancy myself if I'd > read the actual docs ;-) > > KB would be more useful.  And I don't think people have enough script

Re: [HACKERS] t_self as system column

On Mon, Jul 5, 2010 at 3:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane wrote: >>> At one time I was hoping to get rid of explicit entries in pg_attribute >>> for system columns, which would negate this concern.  I think we're >>> stuck with them now, th

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

2010/7/6 KaiGai Kohei : > In the following scenario, we can see orphan comments. Yeah. I think the reason we haven't seen any complaints about this before is that the worst-case scenario is that a comment for a dropped database object eventually becomes associated with a new database object. But

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

> I reviewed > your patch. It seems to be in good shape, and worked as > expected. I > suppressed a compiler warning in the patch and cleaned up > whitespaces in it. > Patch attached. Thanks for the review! I saw that you also changed the writing: LogicalTapeWrite(state->tapeset, tapenum,

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

ter description than "copy&paste from FormIndexDatum". Regards, --- Takahiro Itagaki NTT Open Source Software Center sorted_cluster-20100706.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://w

[HACKERS] Bug? Concurrent COMMENT ON and DROP object

In the following scenario, we can see orphan comments. session.1 session.2 ---- 1: CREATE TYPE my_typ AS (a int, b text); 2: BEGIN; 3: COMMENT ON TYPE my_typ IS 'testt