Re: [HACKERS] SR fails to send existing WAL file after off-line copy

On 01.11.2010 05:21, Robert Haas wrote: There seem to be two cases in the code that can generate that error. One, attempting to open the file returns ENOENT. Two, after the data has been read, the last-removed position returned by XLogGetLastRemoved precedes the data we think we just read, imply

Re: [HACKERS] Maximum function call nesting depth for regression tests

Robert Haas writes: > On Sat, Oct 30, 2010 at 10:47 PM, Tom Lane wrote: >> I don't especially care for choice #1.  To me, one of the things that >> the regression tests ought to flag is whether a machine is so limited >> that "reasonable" coding might fail.  If you can't do twenty or so >> levels

Re: [HACKERS] SR fails to send existing WAL file after off-line copy

On Sun, Oct 31, 2010 at 5:31 PM, Greg Smith wrote: > Which is confusing because that file is certainly on the master still, and > hasn't even been considered archived yet much less removed: > > [mas...@pyramid pg_log]$ ls -l $PGDATA/pg_xlog > -rw--- 1 master master 16777216 Oct 31 16:29 00

[HACKERS] Comparison with "true" in source code

There are some "== true" in the codes, but they might not be safe because all non-zero values are true in C. Is it worth cleaning up them? src/backend/access/gin/ginget.c(1364):#define GinIsVoidRes(s) ( ((GinScanOpaque) scan->opaque)->isVoidRes == true ) src/backend/access/gist/gistproc.

Re: [HACKERS] [PATCH] Custom code int(32|64) => text conversions out of performance reasons

On Sun, Oct 31, 2010 at 11:04 PM, Itagaki Takahiro wrote: > On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund wrote: >> While looking at binary COPY performance I forgot to add BINARY and was a bit >> shocked to see printf that high in the profile... >> >> A change from 9192.476ms 5309.928ms seems to

Re: [HACKERS] [PATCH] Custom code int(32|64) => text conversions out of performance reasons

On Mon, Nov 1, 2010 at 6:41 AM, Andres Freund wrote: > While looking at binary COPY performance I forgot to add BINARY and was a bit > shocked to see printf that high in the profile... > > A change from 9192.476ms 5309.928ms seems to be pretty good indication that a > change in that area is warant

Re: [HACKERS] [PATCH] More Coccinelli cleanups

On Fri, Oct 29, 2010 at 7:33 PM, Marti Raudsepp wrote: > Since my previous Coccinelle cleanup patches have gained positive > feedback I decided to try some more. > > This time I wrote my own spatches. > > patch 0001 turns (a - b == 0) into (a == b) and similarly with != > patch 0002 applies the sa

Re: [HACKERS] type info refactoring

On Sun, Oct 31, 2010 at 6:13 PM, Peter Eisentraut wrote: > On sön, 2010-10-31 at 14:30 -0400, Robert Haas wrote: >> It's true that if the ostensible maximum length of a string or the >> precision of a numeric get lost somewhere on their path through the >> system, probably nothing terribly awful w

Re: [HACKERS] type info refactoring

On sön, 2010-10-31 at 14:30 -0400, Robert Haas wrote: > It's true that if the ostensible maximum length of a string or the > precision of a numeric get lost somewhere on their path through the > system, probably nothing terribly awful will happen. The worst case > is that those values won't be enf

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: > Yeah, I think that sucks a lot. I don't see what's wrong with > Heikki's solution, actually. Coding the parser and replace. If all it takes is calling our replace function on the all-in-memory query string that we have in pg_execute_from_file() function, I can have a try at

Re: [HACKERS] type info refactoring

On sön, 2010-10-31 at 13:01 -0400, Tom Lane wrote: > But I'm still wondering whether it's smart to try to promote all of > this fundamentally-auxiliary information to first-class status. It's > really unclear to me that that will end up being a net win either > conceptually or notationally. Fair

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Oct 31, 2010 at 5:46 PM, Dimitri Fontaine wrote: > Heikki Linnakangas writes: >> Just do "SET search_pa...@extschema@" at the beginning of the install >> script, just like we have "SET search_path=public" there now. > > Well there's the installation itself then the "runtime", as you say >

Re: [HACKERS] type info refactoring

On sön, 2010-10-31 at 18:50 +0200, Heikki Linnakangas wrote: > Yeah, that was my first impression too. I assumed that TypeInfo would be > embedded in other structs directly, rather than a pointer and palloc. > Something like: > > /* > * TypeInfo - encapsulates type information > */ > typedef

Re: [HACKERS] type info refactoring

On sön, 2010-10-31 at 10:39 -0400, Tom Lane wrote: > To my mind, the reason we have a distinction between type OID and > typmod > is that for most operations, you know the type OID of the result but > not the typmod. Trying to force typmod into every API that currently > works with type OIDs isn't

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: > Just do "SET search_pa...@extschema@" at the beginning of the install > script, just like we have "SET search_path=public" there now. Well there's the installation itself then the "runtime", as you say later... > Well, in case of functions you can always do "CREATE F

[HACKERS] [PATCH] Custom code int(32|64) => text conversions out of performance reasons

Hi, While looking at binary COPY performance I forgot to add BINARY and was a bit shocked to see printf that high in the profile... Setup: CREATE TABLE convtest AS SELECT a.i ai, b.i bi, a.i*b.i aibi, (a.i*b.i)::text aibit FROM generate_series(1,1000) a(i), generate_series(1, 1) b(i); Pro

[HACKERS] SR fails to send existing WAL file after off-line copy

Last week we got this report from Matt Chesler: http://archives.postgresql.org/pgsql-admin/2010-10/msg00221.php that he was getting errors when trying to do a simple binary replication test. The problem is that what appears to be a perfectly good WAL segment doesn't get streamed to the standb

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On Sun, Oct 31, 2010 at 15:17, Andrew Dunstan wrote: > On 10/31/2010 04:40 PM, Alex Hunsaker wrote: >> And with the change we get the same >> proc_desc for triggers and non triggers, so if the trigger function >> gets called first, any call to the direct function will use the same >> proc_desc wit

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 10/31/2010 04:40 PM, Alex Hunsaker wrote: On Sun, Oct 31, 2010 at 12:00, Andrew Dunstan wrote: On 10/31/2010 11:44 AM, Tom Lane wrote: Good catch, patch reverted (and regression test added). Well, I guess that answers the question of why we needed it, which nobody could answer before. I'

Re: [HACKERS] Simplifying replication

Josh Berkus writes: >> You have to put the WAL files *somewhere* while you do the base backup. > > Agreed. That's why I like the idea of having a > max_wal_size/min_wal_time instead of keep_wal_segments or > checkpoint_segments. It's relatively simple for a DBA to know how much > disk space s/he

Re: [HACKERS] Range Types, discrete and/or continuous

Jeff Davis writes: > Also, there's a good case for continuous ranges for types like NUMERIC, > but still continuous ranges don't seem quite as important overall. Well it seems to me that the prefix_range type is continuous, so I would tend to disagree here :) A prefix_range is currently written

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On Sun, Oct 31, 2010 at 12:00, Andrew Dunstan wrote: > On 10/31/2010 11:44 AM, Tom Lane wrote: >> Good catch, patch reverted (and regression test added). > > Well, I guess that answers the question of why we needed it, which nobody > could answer before. I'm not sure I exactly understand what's go

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 21:42, Dimitri Fontaine wrote: Heikki Linnakangas writes: If I understand that correctly, the idea is that p_fun holds the name of a function that's in the same schema as the extension? You would write that as v_sql := 'SELECT * FROM @extsch...@.' || p_fun || '()'; Fair enough.

Re: [HACKERS] [RFC][PATCH]: CRC32 is limiting at COPY/CTAS/INSERT ... SELECT + speeding it up

On Sat, Oct 30, 2010 at 5:05 AM, Andres Freund wrote: > This thread died after me not implementing a new version and some potential > license problems. > > I still think its worthwile (and I used it in production for some time) so I > would like to implement a version fit for the next commitfest.

[HACKERS] create custom collation from case insensitive portuguese

Thanks to all the work they have done with this incredible database, postgresql. I've achieved some success in changing collate operating system (linux) to generate sort of way of Brazil Portuguese hopes by adding the following code in LC_COLLATE LC_COLLATE copy "iso14651_t1_ci" reorder-afte

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: > If I understand that correctly, the idea is that p_fun holds the name of a > function that's in the same schema as the extension? You would write that as > > v_sql := 'SELECT * FROM @extsch...@.' || p_fun || '()'; Fair enough. Now what about the citext example, where

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Robert Haas writes: ... > related indexes, sequences, and constraints. It seems hard to fit > that into a general framework, but maybe it could be done for other > object types. My guess is that we're talking about having a generic code that would get exercised directly from src/backend/commands

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 20:19, Dimitri Fontaine wrote: Heikki Linnakangas writes: In particular, embedded and/or dynamic calls in PLs will get hairy if not turing complete and outright impossible to solve. Sorry, I don't follow. Got an example? Well, who's to say the following hypothetical plpgsql ex

Re: [HACKERS] Maximum function call nesting depth for regression tests

On Sat, Oct 30, 2010 at 10:47 PM, Tom Lane wrote: > A few days ago I added a regression test that involves a plpgsql > function calling a sql function, which recurses back to the plpgsql > function, etc, to a depth of 10 cycles (ie 10 plpgsql function calls > and 10 sql function calls).  There are

Re: [HACKERS] type info refactoring

2010/10/31 Robert Haas : > On Sun, Oct 31, 2010 at 1:01 PM, Tom Lane wrote: >> Heikki Linnakangas writes: >>> ... I assumed that TypeInfo would be >>> embedded in other structs directly, rather than a pointer and palloc. >> >> Yeah, that would avoid the extra-pallocs complaint, although it might

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On Sun, Oct 31, 2010 at 12:45 PM, Dimitri Fontaine wrote: > Bernd Helmle writes: >> This reminds me of a small discussion we had some years ago when i targeted >> this for the sake of completeness of ASS (see >> ). > > Discovered

Re: [HACKERS] type info refactoring

On Sun, Oct 31, 2010 at 1:01 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> ... I assumed that TypeInfo would be >> embedded in other structs directly, rather than a pointer and palloc. > > Yeah, that would avoid the extra-pallocs complaint, although it might be > notationally a bit of a PIT

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: >> In particular, embedded and/or dynamic calls in PLs will get hairy if >> not turing complete and outright impossible to solve. > > Sorry, I don't follow. Got an example? Well, who's to say the following hypothetical plpgsql example should be forgiven only in an excep

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 10/31/2010 11:44 AM, Tom Lane wrote: =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: Seems that this circumverts some output conversion error checking, since adding the attached to the regression suite results in a segfault during the plperl installcheck. Reverting 2d01ec0708d571eef926f3f5795aa73

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 19:38, Dimitri Fontaine wrote: Sorry for the interruption, our program now continues... Dimitri Fontaine writes: That's exactly the road I want to avoid, because of the script parsing issues. In particular, embedded and/or dynamic calls in PLs will get hairy if not turing comp

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Sorry for the interruption, our program now continues... Dimitri Fontaine writes: > That's exactly the road I want to avoid, because of the script parsing issues. In particular, embedded and/or dynamic calls in PLs will get hairy if not turing complete and outright impossible to solve. -- Dim

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Heikki Linnakangas writes: > CREATE EXTENSION myextension ... SCHEMA myschema; > > And in the .sql file in the extension you could have special markers for the > schema, something like: That's exactly the road I want to avoid, because of the script parsing issues. Regards, -- Dimitri Fontaine h

Re: [HACKERS] type info refactoring

Heikki Linnakangas writes: > ... I assumed that TypeInfo would be > embedded in other structs directly, rather than a pointer and palloc. Yeah, that would avoid the extra-pallocs complaint, although it might be notationally a bit of a PITA in places like equalfuncs.c. I think that would end up

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

On 31.10.2010 14:46, Dimitri Fontaine wrote: What we could do is offer extension's author a way to find their operator or functions or whatever dynamically in SQL, so that writing robust pure-SQL functions is possible. What comes to mind now would be a way to call a function/operator/... by OID a

Re: [HACKERS] type info refactoring

On 31.10.2010 16:39, Tom Lane wrote: Peter Eisentraut writes: Here's a big patch to avoid passing around type OID + typmod (+ collation) separately all over the place. Instead, there is a new struct TypeInfo that contains these fields, and only a pointer is passed around. Some stuff in here

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Bernd Helmle writes: > This reminds me of a small discussion we had some years ago when i targeted > this for the sake of completeness of ASS (see > ). Discovered it, thanks for the pointer. > I didn't follow the previous discuss

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

--On 30. Oktober 2010 18:59:30 -0400 Tom Lane wrote: I'm not sure whether that really fixes anything, or just provides people with a larger-caliber foot-gun. See for example recent complaints about citext misbehaving if it's not in the public schema (or more generally, any schema not in the

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > Seems that this circumverts some output conversion error checking, since > adding the attached to the regression suite results in a segfault during > the plperl installcheck. > Reverting 2d01ec0708d571eef926f3f5795aa73759df5d9a fixes it. Good catch, pat

Re: [HACKERS] why does plperl cache functions using just a bool for is_trigger

On 25/10/10 03:59, Andrew Dunstan wrote: > > > On 10/24/2010 09:34 PM, Tom Lane wrote: >> >>> For both trigger and non-trigger functions, we compile this ahead of the >>> user-set function code: >>> our $_TD; local $_TD=shift; >>> Non-trigger functions get passed "undef" to correspond to thi

Re: [HACKERS] type info refactoring

Peter Eisentraut writes: > Here's a big patch to avoid passing around type OID + typmod (+ > collation) separately all over the place. Instead, there is a new > struct TypeInfo that contains these fields, and only a pointer is passed > around. > Some stuff in here (or not in here) is probably a

Re: [HACKERS] ALTER OBJECT any_name SET SCHEMA name

Hi, Thanks for your review! Tom Lane writes: > Dimitri Fontaine writes: >> ALTER EXTENSION ext SET SCHEMA name; >> ALTER EXTENSION ext SET SCHEMA foo TO bar; > >> I think that would end the open debate about search_path vs extension, >> because each user would be able to relocate his local

[HACKERS] create custom collation from case insensitive portuguese

Thanks to all the work they have done with this incredible database, postgresql. I've achieved some success in changing collate operating system (linux) to generate sort of way of Brazil Portuguese hopes by adding the following code in LC_COLLATE LC_COLLATE copy "iso14651_t1_ci" reorder-afte