Re: [HACKERS] Hot Standby: too many KnownAssignedXids

On 19.11.2010 23:46, Joachim Wieland wrote: FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978, pArray->maxKnownAssignedXids: 6890 Hmm, that's a lot of entries in KnownAssignedXids. Can you recompile with WAL_DEBUG, and run the recovery again with wal_debug=on ? That will print

Re: [HACKERS] [JDBC] Support for JDBC setQueryTimeout, et al.

On Mon, 22 Nov 2010, Itagaki Takahiro wrote: On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura wrote: Regarding JDBC in the CF process -- other interfaces are handled there.  I haven't seen one patch this size for JDBC since I've been involved, let alone two competing patches to implement the

Re: [HACKERS] GiST seems to drop left-branch leaf tuples

On 22.11.2010 23:18, Peter Tanski wrote: Whatever test I use for Same(), Penalty() and Consistent() does not seem to affect the problem significantly. For now I am only using Consistent() as a check for retrieval. I believe it's not possible to lose leaf tuples with incorrectly defined gist su

Re: [HACKERS] final patch - plpgsql: for-in-array

2010/11/23 David Fetter : > On Tue, Nov 23, 2010 at 05:55:28AM +0100, Pavel Stehule wrote: >> >> ok, I can only recapitulate so this feature was proposed cca two >> months ago, and minimally Tom and maybe you did agreement - with >> request on syntax - do you remember? I am little bit tired so this

Re: [HACKERS] final patch - plpgsql: for-in-array

On Tue, Nov 23, 2010 at 05:55:28AM +0100, Pavel Stehule wrote: > > ok, I can only recapitulate so this feature was proposed cca two > months ago, and minimally Tom and maybe you did agreement - with > request on syntax - do you remember? I am little bit tired so this > agreement was changed when I

Re: [HACKERS] final patch - plpgsql: for-in-array

2010/11/22 Robert Haas : > On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule > wrote: >> So, please, I know, so you and Tom are busy, but try to spend a few >> time about this problem before you are definitely reject this idea. > > If I were to spend more time on this problem, what exactly would I >

Re: [HACKERS] knngist - 0.8

Robert Haas writes: > On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane wrote: >> On balance I'm inclined to leave the unique key as per previous proposal >> (with a "purpose" column) and add the which-sort-order-is-that >> information as payload columns that aren't part of the key. > This is probably O

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Nov 21, 2010 at 4:47 PM, Dimitri Fontaine wrote: > Robert Haas writes: >> On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas wrote: >>> Ah, nuts.  I see now there's a v7.  Never mind... >> >> OK.  I looked at the right version, now.  Hopefully. > > Yeah, that was the most recent one and I lin

Re: [HACKERS] knngist - 0.8

On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane wrote: > The reason I bring this up now is that it affects the decision as to > what the unique key for pg_amop ought to be.  Instead of having an > enum "purpose" column, maybe we should consider that the unique key > is (operator oid, opfamily oid, order

Re: [HACKERS] reporting reason for certain locks

On Mon, Nov 22, 2010 at 5:55 PM, Alvaro Herrera wrote: > Hi, > > When we lock on a Xid or VirtualXid, there's no way to obtain clear > information on the reason for locking.  Consider the following example: > > CREATE TABLE foo (a int); > > Session 1: > BEGIN; > SELECT 1; > -- we now have a snapsh

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

On 11/22/10 5:38 PM, Josh Berkus wrote: > All, > > Whatever we pick, someone will be confused by it and about equal numbers > regardless. Let's just stick with the current patch. ... "original patch". Sorry. Let's not fiddle with the names. > > Or we could call it "extraint conclusions". ;-

Re: [HACKERS] reporting reason for certain locks

> ... or maybe not, because when we call XactLockTableWait, we've already > established that we've accepted to sleep. > > Thoughts? Other than this being a sincere need, no. -- -- Josh Berkus PostgreSQL Experts Inc.

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

All, Whatever we pick, someone will be confused by it and about equal numbers regardless. Let's just stick with the current patch. Or we could call it "extraint conclusions". ;-) -- -- Josh Berkus PostgreSQL Experts Inc.

Re: [HACKERS] knngist - 0.8

I wrote: > As far as the syntax of CREATE/ALTER OPERATOR CLASS/FAMILY is concerned, > I like Robert's proposal (OPERATOR ... FOR ORDER or FOR SEARCH) better > than Teodor's, though we don't need the multiple-purposes-per-entry > aspect of it. This is mainly because it looks more easily extensible

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

On Nov 22, 2010, at 4:46 PM, Tom Lane wrote: >> Oh my boots and buttons. I think we're splitting some very fine hairs >> here. A few weeks back you were telling us that label wasn't a very good >> word and shouldn't be sanctified in the SQL. > > It isn't a very good word for the abstract value,

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

On Mon, Nov 22, 2010 at 7:46 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 11/22/2010 06:57 PM, Tom Lane wrote: >>> Maybe instead of "textual label", we should say "name"?  But that >>> doesn't seem like quite le mot juste either.  "label" is actually a >>> pretty good word for the text repr

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

Andrew Dunstan writes: > On 11/22/2010 06:57 PM, Tom Lane wrote: >> Maybe instead of "textual label", we should say "name"? But that >> doesn't seem like quite le mot juste either. "label" is actually a >> pretty good word for the text representation of an enum value. > Oh my boots and buttons.

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

On 11/22/2010 06:57 PM, Tom Lane wrote: "David E. Wheeler" writes: Patch attached. Most of those changes seem like they make it less readable, not more so. In particular I don't find it an improvement to replace "textual label" with "textual value". I think of "value" as meaning some abstra

Re: [HACKERS] knngist - 0.8

I've done some *very* preliminary review of this patch now. I think that the way to move forward is to first commit the work surrounding changes to pg_amop, including suitable changes to CREATE/ALTER OPERATOR CLASS/FAMILY so that there's a way to put the new info into the table. The system won't i

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

"David E. Wheeler" writes: > Patch attached. Most of those changes seem like they make it less readable, not more so. In particular I don't find it an improvement to replace "textual label" with "textual value". I think of "value" as meaning some abstract notion of a particular enum member, whic

Re: [HACKERS] reporting reason for certain locks

Alvaro Herrera writes: > A much more common ocurrence is tuple locks. We block in an Xid in that > case; and this has been a frequent question in the mailing lists and > IRC. > I think it would be very nice to be able to report something to the > user; however, I'm not seeing the mechanism. At

Re: [HACKERS] s/LABEL/VALUE/ for ENUMs

On 11/22/2010 06:36 PM, David E. Wheeler wrote: Patch attached. Thanks, I'll look at this shortly. I think it needs a little bit more, which I'll do. In particular, we should now avoid using the word 'value' to refer to the internal representation of an enum - that will just be confusing.

[HACKERS] s/LABEL/VALUE/ for ENUMs

Patch attached. Best, David enum_value.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] reporting reason for certain locks

Hi, When we lock on a Xid or VirtualXid, there's no way to obtain clear information on the reason for locking. Consider the following example: CREATE TABLE foo (a int); Session 1: BEGIN; SELECT 1; -- we now have a snapshot Session 2: CREATE INDEX CONCURRENTLY foo_a ON foo(a); This blocks unti

Re: [HACKERS] Extensions, this time with a patch

Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010: > Itagaki Takahiro writes: > > No. My suggestion was just to use the internal parser. > > What about something like the attached, cfparser.v3.patch? the handling of relative vs absolute paths is bogus here. I think it'd

Re: [HACKERS] Extensions, this time with a patch

Excerpts from Alvaro Herrera's message of lun nov 22 18:59:52 -0300 2010: > Hmm, the first thought that comes to mind is that the GucContext param > to ParseConfigFile is unused and can be removed. This is probably an > oversight from when include files were introduced in 2006. Committed and pus

Re: [HACKERS] Extensions, this time with a patch

Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010: > Itagaki Takahiro writes: > > No. My suggestion was just to use the internal parser. > > What about something like the attached, cfparser.v3.patch? > > If that looks ok, do we want to add some documentation about the ne

Re: [HACKERS] final patch - plpgsql: for-in-array

On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule wrote: > So, please, I know, so you and Tom are busy, but try to spend a few > time about this problem before you are definitely reject this idea. If I were to spend more time on this problem, what exactly would I spend that time doing and how would

Re: [HACKERS] GiST seems to drop left-branch leaf tuples

One minor correction: postgres=# explain select count(*) from fps2 f1 join fps2 f2 on f1.fingerprint = f2.fingerprint; QUERY PLAN Aggregate (cost=1173.6

[HACKERS] GiST seems to drop left-branch leaf tuples

I have been working on a plugin for GiST that has some unusual features: * The data type for both Node and Leaf keys is large (typically 4222 bytes on 32-bit; 4230 bytes on 64-bit). * Due to the large size the storage class is EXTENDED (main would only degrade to EXTENDED in any case). Tes

Re: [HACKERS] Extensions, this time with a patch

Itagaki Takahiro writes: > No. My suggestion was just to use the internal parser. What about something like the attached, cfparser.v3.patch? If that looks ok, do we want to add some documentation about the new lexer capabilities? Also, for what good reason would we want to prevent people from us

Re: [HACKERS] Hot Standby: too many KnownAssignedXids

On Sun, Nov 21, 2010 at 11:48 PM, Fujii Masao wrote: > -- > If you suspect a bug in Hot Standby, please set >        trace_recovery_messages = DEBUG2 > in postgresql.conf and repeat the action > > Always useful to know > * max_connections > * current number of sessions > * whether we h

Re: [HACKERS] directory archive format for pg_dump

On 22.11.2010 19:07, Tom Lane wrote: Heikki Linnakangas writes: But I'm not actually sure we should be preventing mix& match of files from different dumps. It might be very useful to do just that sometimes, like restoring a recent backup, with the contents of one table replaced with older data

Re: [HACKERS] final patch - plpgsql: for-in-array

Hello I spent last two days a searching how to solve this problem better. Probably I removed a issue with toasting. But I found other issue, that wasn't discussed before. This issue is only seq access to items via array_seek function. I though about some variable that stores a last accessed field

Re: [HACKERS] Patch to add a primary key using an existing index

On 10-11-22 09:37 AM, Gurjeet Singh wrote: On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer > wrote: Submission Review: Tests The expected output for the regression tests you added don't match what I'm getti

Re: [HACKERS] Per-column collation

On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote: > * COLLATE information must be explicitly passed by caller in the patch, > but we might forgot the handover when we write new codes. Is it possible > to pass it automatically, say using a global variable? If we could do so, > existing exte

Re: [HACKERS] Per-column collation

On tor, 2010-11-18 at 21:37 +0200, Heikki Linnakangas wrote: > Have you done any performance testing? Functions like text_cmp can be > a hotspot in sorting, so any extra overhead there might be show up in > tests. Without having optimized it very much yet, the performance for a 1GB ORDER BY is *

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 1:28 PM, Magnus Hagander wrote: > I think the reasonable options are either "don't backpatch at all" or > "backpatch the same way as we put it in HEAD, which is probably > included in backend". I agree that sticking it in contrib is a > half-measure that we shouldn't do. >

Re: [HACKERS] Instrument checkpoint sync calls

On Mon, Nov 15, 2010 at 12:09 PM, Greg Smith wrote: > So my task list is: > > 0) Rebase against the HEAD that just code related to this touched today > > 1) Assume that log_checkpoints is sufficient control over whether the timing > overhead added is worth collecting, and therefore remove the half

Re: [HACKERS] visibility map

On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas wrote: >> I *think* that the answer to this parenthesized question is "no". >> When we vacuum a page, we set the LSN on both the heap page and the >> visibility map page.  Therefore, neither of them can get written to >> disk until the WAL record

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On mån, 2010-11-22 at 19:56 +0200, Heikki Linnakangas wrote: > This whole thing makes me wonder: is there truly no reliable, simple > method to tell Windows to create a core dump on crash, without writing > custom code for it. I haven't seen one, but I find it amazing if there > isn't. We can't be

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 19:39, Tom Lane wrote: > Magnus Hagander writes: >> On Mon, Nov 22, 2010 at 18:46, Tom Lane wrote: >>> ... I haven't looked at the patch but this >>> discussion makes it sound like the dumper is dependent on an >>> uncomfortably large amount of backend code being function

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Magnus Hagander writes: > On Mon, Nov 22, 2010 at 18:46, Tom Lane wrote: >> ... I haven't looked at the patch but this >> discussion makes it sound like the dumper is dependent on an >> uncomfortably large amount of backend code being functional. > No, it's dependent on close to zero backend fun

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 18:56, Heikki Linnakangas wrote: > On 22.11.2010 19:47, Robert Haas wrote: >> >> I am as conservative about back-patching as anybody here, but >> debugging on Windows is not an easy thing to do, and I strongly >> suspect we are going to point people experiencing crashes on

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 18:54, Tom Lane wrote: > Robert Haas writes: >> I am as conservative about back-patching as anybody here, but >> debugging on Windows is not an easy thing to do, and I strongly >> suspect we are going to point people experiencing crashes on Windows >> to this code whether

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 18:46, Tom Lane wrote: > Magnus Hagander writes: >> * However, when storing it in crashdumps, I think the code would need >> to create that directory if it does not exist, doesn't it? > > If it didn't do so, then manual creation/removal of the directory could > be used as

Re: [HACKERS] format() with embedded to_char() formatter

2010/11/22 Robert Haas : > On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane wrote: >> Robert Haas writes: >>> On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane wrote: And lastly, AFAICS there is no way to do what you suggest without some really ugly kluges in the parser --- I think the function

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On 22.11.2010 19:47, Robert Haas wrote: I am as conservative about back-patching as anybody here, but debugging on Windows is not an easy thing to do, and I strongly suspect we are going to point people experiencing crashes on Windows to this code whether it's part of our official distribution or

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Robert Haas writes: > I am as conservative about back-patching as anybody here, but > debugging on Windows is not an easy thing to do, and I strongly > suspect we are going to point people experiencing crashes on Windows > to this code whether it's part of our official distribution or not. I > do

Re: [HACKERS] format() with embedded to_char() formatter

On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane wrote: > Robert Haas writes: >> On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane wrote: >>> And lastly, AFAICS there >>> is no way to do what you suggest without some really ugly kluges >>> in the parser --- I think the function parsing code would have to >>>

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Magnus Hagander writes: > * On Unix, the core file is dropped in the database directory, we > don't have a separate directory for crashdumps. If we want to be > consistent, we should do that here too. I do think that storing them > in a directory like "crashdumps" is better, but I just wanted to r

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 12:30 PM, Tom Lane wrote: > Robert Haas writes: >> I don't see why an upgrading aid would be worthy of back-patching, but >> not a debugging aid.  I'd certainly prioritize those in the other >> order. > > I think the sort of upgrading aid Peter has in mind is the kind wher

Re: [HACKERS] dblink versus long connection strings

On 11/22/2010 12:21 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/22/2010 12:08 PM, Tom Lane wrote: No, because = isn't disallowed in names ... Ok, true, but it still might not be a bad heuristic to use for issuing a warning on lookup. The fine manual says that using "=" in a connection

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Robert Haas writes: > I don't see why an upgrading aid would be worthy of back-patching, but > not a debugging aid. I'd certainly prioritize those in the other > order. I think the sort of upgrading aid Peter has in mind is the kind where it's entirely useless if it's not back-patched, because i

Re: [HACKERS] dblink versus long connection strings

Andrew Dunstan writes: > On 11/22/2010 12:08 PM, Tom Lane wrote: >> No, because = isn't disallowed in names ... > Ok, true, but it still might not be a bad heuristic to use for issuing a > warning on lookup. The fine manual says that using "=" in a connection name might be unwise because of the

Re: [HACKERS] format() with embedded to_char() formatter

Robert Haas writes: > On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane wrote: >> And lastly, AFAICS there >> is no way to do what you suggest without some really ugly kluges >> in the parser --- I think the function parsing code would have to >> have special cases to make format() work like this. > Huh

Re: [HACKERS] dblink versus long connection strings

On 11/22/2010 12:08 PM, Tom Lane wrote: Andrew Dunstan writes: On 11/22/2010 11:51 AM, Tom Lane wrote: Perhaps a reasonable compromise is to issue the truncation warnings when an overlength name is being *entered* into the connection table, but not for simple lookups. Can't we distinguish a

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 10:17 AM, Peter Eisentraut wrote: > On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote: >> Do we want to backpatch it into contrib/? > > It's not a bug fix or an upgrading aid, so no. I don't see why an upgrading aid would be worthy of back-patching, but not a debugg

Re: [HACKERS] dblink versus long connection strings

Andrew Dunstan writes: > On 11/22/2010 11:51 AM, Tom Lane wrote: >> Perhaps a reasonable compromise is to issue the truncation warnings when >> an overlength name is being *entered* into the connection table, but not >> for simple lookups. > Can't we distinguish a name from a conninfo string by t

Re: [HACKERS] format() with embedded to_char() formatter

On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane wrote: > Itagaki Takahiro writes: >> I'd like to propose %{...}s syntax, where format('%{xxx}s', arg) >> is equivalent to format('%s', to_char(arg, 'xxx')). I think the >> approach is better than implement C-like formatter because we >> can reuse existing

Re: [HACKERS] directory archive format for pg_dump

Heikki Linnakangas writes: > But I'm not actually sure we should be preventing mix & match of files > from different dumps. It might be very useful to do just that sometimes, > like restoring a recent backup, with the contents of one table replaced > with older data. A warning would be ok, thou

Re: [HACKERS] dblink versus long connection strings

On 11/22/2010 11:51 AM, Tom Lane wrote: Itagaki Takahiro writes: On Tue, Nov 23, 2010 at 01:27, Tom Lane wrote: I'm inclined to think that we should just change all the truncate_identifier calls to warn=false, and forget about providing identifier-truncated warnings here. Â It's too difficu

Re: [HACKERS] dblink versus long connection strings

Itagaki Takahiro writes: > On Tue, Nov 23, 2010 at 01:27, Tom Lane wrote: >> I'm inclined to think that we should just change all the >> truncate_identifier calls to warn=false, and forget about providing >> identifier-truncated warnings here.  It's too difficult to tell whether >> a string is r

Re: [HACKERS] directory archive format for pg_dump

On 20.11.2010 06:10, Joachim Wieland wrote: 2010/11/19 José Arthur Benetasso Villanova: The md5.c and kwlookup.c reuse using a link doesn't look nice either. This way you need to compile twice, among others things, but I think that its temporary, right? No, it isn't. md5.c is used in the same

Re: [HACKERS] dblink versus long connection strings

On Tue, Nov 23, 2010 at 01:27, Tom Lane wrote: > This bug report: > http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php > shows that this patch was ill-considered: > http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php > and this later attempt didn't fix it, because it s

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Magnus Hagander writes: > on-by-default is what we gain. I think that's fairly big... Only if that's actually what we want, which is far from clear in this corner. There are good reasons why most Linux distros configure daemons not to dump core by default. It's annoying when we are trying to de

[HACKERS] dblink versus long connection strings

This bug report: http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php shows that this patch was ill-considered: http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php and this later attempt didn't fix it, because it still misbehaves in HEAD: http://archives.postgresql.org/pg

Re: [HACKERS] Extensions, this time with a patch

On Mon, Nov 22, 2010 at 18:36, Dimitri Fontaine wrote: >> * Can we export ParseConfigFile() in guc-file.l rather than >>   parseRecoveryCommandFileLine()? > > Should we then consider recovery.conf entries as ordinary GUCs? That > would allow to connect to a standby and issue 'show primary_conninf

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 15:15, Robert Haas wrote: > On Mon, Nov 22, 2010 at 6:37 AM, Magnus Hagander wrote: >> Do we want to backpatch it into contrib/? Adding a new module there >> seems kind of wrong - probably better to keep the source separate and >> just publish the DLL files for people who

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 16:33, Tom Lane wrote: > Peter Eisentraut writes: >> On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote: >>> Do we want to backpatch it into contrib/? > >> It's not a bug fix or an upgrading aid, so no. > > I'm less than thrilled about back-patching this, too.  It se

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Peter Eisentraut writes: > On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote: >> Do we want to backpatch it into contrib/? > It's not a bug fix or an upgrading aid, so no. I'm less than thrilled about back-patching this, too. It seems to fly in the face of all our historical practice.

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote: > Do we want to backpatch it into contrib/? It's not a bug fix or an upgrading aid, so no. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pg

Re: [HACKERS] Extensions, this time with a patch

Itagaki Takahiro writes: > I checked cfparser.v2.patch. Thanks for reviewing it! > It exports the static parseRecoveryCommandFileLine() in xlog.c > as the global cfParseOneLine() in cfparser.c without modification. > > It generates one warning, but it can be easily fixed. > cfparser.c:34: warn

Re: [HACKERS] format() with embedded to_char() formatter

Itagaki Takahiro writes: > I'd like to propose %{...}s syntax, where format('%{xxx}s', arg) > is equivalent to format('%s', to_char(arg, 'xxx')). I think the > approach is better than implement C-like formatter because we > can reuse existing to_char() functions for the purpose. This seems pretty

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 9:49 AM, Tom Lane wrote: > Robert Haas writes: >> However, I am not clear what benefit we get from moving this into core >> in 9.1.  If it's still going to require a full postmaster restart, the >> GUC you have to change may as well be shared_preload_libraries as a >> new

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

Robert Haas writes: > However, I am not clear what benefit we get from moving this into core > in 9.1. If it's still going to require a full postmaster restart, the > GUC you have to change may as well be shared_preload_libraries as a > new one. +1. I am not in favor of randomly repackaging fun

Re: [HACKERS] Explain analyze getrusage tracking

On Mon, Nov 22, 2010 at 12:40 PM, Magnus Hagander wrote: > I tried building this under windows, and got a bunch of errors. Thanks! -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hacke

Re: [HACKERS] Patch to add a primary key using an existing index

On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer wrote: > > Submission Review: > > > Tests > > The expected output for the regression tests you added don't match > what I'm getting when I run the tests with your patch applied. > I think you just need to regenerate th

Re: [HACKERS] final patch - plpgsql: for-in-array

On Mon, Nov 22, 2010 at 8:39 AM, Jaime Casanova wrote: > On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote: >> On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule >> wrote: >>> Hello >>> >>> this patch implement a new iteration construct - iteration over an >>> array. The sense of this new itera

Re: [HACKERS] final patch - plpgsql: for-in-array

On Mon, Nov 22, 2010 at 6:21 AM, Valentine Gogichashvili wrote: > Hi, > with the FOR e IN SELECT UNNEST(a) construct there is an issue again related > to the unresting of composite type arrays: > [ example ] > Is it a bug or a feature? It looks like the problem in this example is that PL/pgsql tr

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Mon, Nov 22, 2010 at 6:37 AM, Magnus Hagander wrote: > Do we want to backpatch it into contrib/? Adding a new module there > seems kind of wrong - probably better to keep the source separate and > just publish the DLL files for people who do debugging? If this works without changes to core, I

Re: [HACKERS] final patch - plpgsql: for-in-array

On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova wrote: > On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule > wrote: >> Hello >> >> this patch implement a new iteration construct - iteration over an >> array. The sense of this new iteration is: >>  * a simple and cleaner syntax > > i will start the

Re: [HACKERS] Tab completion for view triggers in psql

Excerpts from David Fetter's message of dom nov 21 21:17:12 -0300 2010: > Given its small and isolated nature, I was hoping we could get this in > sooner rather than later. As I understand it, CFs are there to review > patches that take significant effort for even a committer to > understand, so

Re: [HACKERS] patch: fix performance problems with repated decomprimation of varlena values in plpgsql

2010/11/22 Andrew Dunstan : > > > On 11/22/2010 07:46 AM, Pavel Stehule wrote: >> >> Hello >> >> this patch remove a multiple detoasting of varlena values in plpgsql. >> >> It is usable mainly for iteration over longer array directly loaded >> from relation. >> >> It's doesn't have a impact on sema

Re: [HACKERS] patch: fix performance problems with repated decomprimation of varlena values in plpgsql

On 11/22/2010 07:46 AM, Pavel Stehule wrote: Hello this patch remove a multiple detoasting of varlena values in plpgsql. It is usable mainly for iteration over longer array directly loaded from relation. It's doesn't have a impact on semantic or behave - it's just eliminate some performance

Re: [HACKERS] format() with embedded to_char() formatter

Hello There is little bit complication. There are no one "to_char" function - so you cannot to use DirectFunctionCall API. but I am not against to this proposal. regards Pavel 2010/11/22 Itagaki Takahiro : > format() function is very useful to construct formatted text, > but it doesn't suppor

[HACKERS] patch: fix performance problems with repated decomprimation of varlena values in plpgsql

Hello this patch remove a multiple detoasting of varlena values in plpgsql. It is usable mainly for iteration over longer array directly loaded from relation. It's doesn't have a impact on semantic or behave - it's just eliminate some performance trap. sample: table 1 rows one column with a

Re: [HACKERS] Explain analyze getrusage tracking

On Mon, Nov 15, 2010 at 03:33, Greg Stark wrote: > This is an update to my earlier patch to add getrusage resource > tracking to EXPLAIN ANALYZE. > > With this patch you get something like: > >                                                  QUERY PLAN > --

[HACKERS] format() with embedded to_char() formatter

format() function is very useful to construct formatted text, but it doesn't support embedded formatter unlike sprintf() in C. Of course, we can use to_char() functions for each argument value, but embedded formatter would be more readable. I'd like to propose %{...}s syntax, where format('%{xxx}s

Re: Latches with weak memory ordering (Re: [HACKERS] max_wal_senders must die)

On 21.11.2010 15:18, Robert Haas wrote: On Sat, Nov 20, 2010 at 4:07 PM, Tom Lane wrote: Robert Haas writes: So what DO we need to guard against here? I think the general problem can be stated as "process A changes two or more values in shared memory in a fairly short span of time, and proc

Re: [HACKERS] Re: Proposed Windows-specific change: Enable crash dumps (like core files)

On Tue, Oct 5, 2010 at 17:21, Craig Ringer wrote: > OK, it's pretty much ready for proper testing now. If a few people are happy > with the results and think it's a good idea I'll chuck it in the commitfest > app. > > As built, the crash dump handler works with a stock PostgreSQL 9.0 (release > bu

Re: [HACKERS] final patch - plpgsql: for-in-array

Hi, with the FOR e IN SELECT UNNEST(a) construct there is an issue again related to the unresting of composite type arrays: BEGIN; CREATE TYPE truple AS (i integer, a text, b text); DO $SQL$ DECLARE start_time timestamp; t truple; ta truple[] := ARRAY( select ROW(s.i, 'A' || (s.i)::text, '