Re: [PATCHES] Packed Varlena Update (v21)
Added to TODO: o Allow single-byte header storage for arrays --- Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > >> Forgot to mention: one of the revisions was to not add the "sizes.sql" > >> test, because the output was platform-dependent and is likely to get > >> more so if any ability to change the toast thresholds gets put in. > >> Can we improve that test to not expose any platform-dependent numbers? > > > I had imagined that we would have two versions of output files. Other than > > 32-bit versus 64-bit what other platform-dependent variations enter into it? > > If there'd be only two then I'd be all right with it, but I'm worried > that making TOAST thresholds configurable would result in lots more > possible outputs than that. > > BTW, another area that should be kept on the TODO list is to see whether > it makes sense to support 1-byte-header format for array elements. > I looked at that briefly while reviewing the patch but decided it was a > large additional chunk of work and not on the critical path. > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] CREATE TABLE LIKE INCLUDING INDEXES support
Added to TODO:
o Have WITH CONSTRAINTS also create constraint indexes
http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php
---
Trevor Hardcastle wrote:
> Greetings all,
>
> I wrote this patch about a week ago to introduce myself to coding on
> PostgreSQL. I wasn't entirely sure what the 'INCLUDING INDEXES' option
> was meant to do, so I held off submitting it until I could get around to
> asking about that and tweaking the documentation to reflect the patch.
> By useful coincidence the thread "Auto creation of Partitions" had this
> post in it, which made the intent of the option clear enough for me to
> go ahead and see what people think of this.
>
> Gregory Stark wrote:
> > "NikhilS" <[EMAIL PROTECTED]> writes:
> >
> >
> >> the intention is to use this information from the parent and make it a
> >> property of the child table. This will avoid the step for the user having
> >> to
> >> manually specify CREATE INDEX and the likes on all the children tables
> >> one-by-one.
> >>
> >
> > Missed the start of this thread. A while back I had intended to add WITH
> > INDEXES to CREATE TABLE LIKE. That would let you create a tale LIKE parent
> > WITH CONSTRAINTS WITH INDEXES and get pretty much a perfect table ready for
> > adding to the inheritance structure.
> >
> >
> >
> So, that's what this patch does. When a table is created with 'CREATE
> TABLE ... LIKE parent INCLUDING INDEXES' this iterates over the parent
> table indexes looking for constraint indexes, and alters the
> CreateStmtContext to include equivalent indexes on the child table.
>
> This is probably a somewhat naive implementation, being a first attempt.
> I wasn't sure what sort of lock to place on the parent indexes or what
> tablespace the new indexes should be created in. Any help improving it
> would be appreciated.
>
> Thank you,
> -Trevor Hardcastle
>
> Index: src/backend/parser/analyze.c
> ===
> RCS file: /projects/cvsroot/pgsql/src/backend/parser/analyze.c,v
> retrieving revision 1.361
> diff -c -r1.361 analyze.c
> *** src/backend/parser/analyze.c 20 Feb 2007 17:32:16 - 1.361
> --- src/backend/parser/analyze.c 7 Mar 2007 01:43:12 -
> ***
> *** 14,19
> --- 14,20
> #include "postgres.h"
>
> #include "access/heapam.h"
> + #include "access/genam.h"
> #include "catalog/heap.h"
> #include "catalog/index.h"
> #include "catalog/namespace.h"
> ***
> *** 40,45
> --- 41,47
> #include "utils/acl.h"
> #include "utils/builtins.h"
> #include "utils/lsyscache.h"
> + #include "utils/relcache.h"
> #include "utils/syscache.h"
>
>
> ***
> *** 1345,1355
> }
> }
>
> - if (including_indexes)
> - ereport(ERROR,
> - (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> - errmsg("LIKE INCLUDING INDEXES is not
> implemented")));
> -
> /*
>* Insert the copied attributes into the cxt for the new table
>* definition.
> --- 1347,1352
> ***
> *** 1448,1453
> --- 1445,1519
> }
>
> /*
> + * Clone constraint indexes if requested.
> + */
> + if (including_indexes && relation->rd_rel->relhasindex)
> + {
> + List *parent_index_list = RelationGetIndexList(relation);
> + ListCell *parent_index_scan;
> +
> + foreach(parent_index_scan, parent_index_list)
> + {
> + Oidparent_index_oid =
> lfirst_oid(parent_index_scan);
> + Relation parent_index;
> +
> + parent_index = index_open(parent_index_oid,
> AccessShareLock);
> +
> + /*
> + * Create new unique or primary key indexes on the
> child.
> + */
> + if (parent_index->rd_index->indisunique ||
> parent_index->rd_index->indisprimary)
> + {
> + IndexInfo *parent_index_info;
> + Constraint *n = makeNode(Constraint);
> + AttrNumber parent_attno;
> +
> + parent_index_info =
> BuildIndexInfo(parent_index);
> +
> + if (parent_index->rd_index->indisprimary)
> + {
> + n->contype = CONSTR_PRIMARY;
> + }
> + else
> + {
> + n->contype = CONSTR_UNIQUE;
> + }
> + /* Let DefineIndex name it */
> + n->name = NULL;
> +
Re: [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- ITAGAKI Takahiro wrote: > The attached patch clears up the usage of strxfrm() on Windows. If the > server encoding is UTF-8 and the locale is not C, we should use wcsxfrm() > instead of strxfrm() because UTF-8 locale are not supported on Windows. > We've already have a special version of strcoll() for Windows, but the > usage of strxfrm() was still broken. > > When we are caught up in the bug, we see the next error message. > | ERROR: invalid memory alloc request size 2147483648 > If the server is wrong configured between the server encoding and the > locale, strxfrm() could be failed and return values like INT_MAX or > (size_t)-1. We've passed the result+1 straight to palloc(), so the server > tried to allocale more than 1GB of memory and gave up. > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] non-recursive WITH clause support
On Mon, Apr 09, 2007 at 09:08:31PM -0400, Tom Lane wrote: > David Fetter <[EMAIL PROTECTED]> writes: > > On Mon, Apr 09, 2007 at 06:43:08PM -0400, Tom Lane wrote: > >> So this does not really add any new functionality, it's just variant > >> syntax for something you can do about as easily without it, right? > > > Not totally as easily. For example, you can do some kinds of > > aggregation with a few fewer keystrokes. > > Example please? It's not obvious to me what this does that wouldn't be > exactly isomorphic to creating a temporary view. It would be isomorphic, but happens automagically for the scope of the query instead of being three queries. Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] non-recursive WITH clause support
David Fetter <[EMAIL PROTECTED]> writes: > On Mon, Apr 09, 2007 at 06:43:08PM -0400, Tom Lane wrote: >> So this does not really add any new functionality, it's just variant >> syntax for something you can do about as easily without it, right? > Not totally as easily. For example, you can do some kinds of > aggregation with a few fewer keystrokes. Example please? It's not obvious to me what this does that wouldn't be exactly isomorphic to creating a temporary view. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] UTF8MatchText
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
ITAGAKI Takahiro wrote:
> Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > > I do not understand this patch. You have defined two functions,
> > > UTF8MatchText() and UTF8MatchTextIC(), and the difference between them
> > > is that one calls CHAREQ and the other calls ICHAREQ, but just above
> > > those two functions you define the macros identically:
> >
> > Why are there two functions? Also, can't you use one function and just
> > pass a boolean to indicate whether case should be ignored?
>
> The same is true of MBMatchText() and MBMatchTextIC().
> Now, I'll split the patch into two changes.
>
> 1. DropMBMatchTextIC.patch
> Drop MBMatchTextIC() and use MBMatchText() instead.
>
> 2. UTF8MatchText.patch
> Add UTF8MatchText() as a specialized version of MBMatchText().
>
>
> As a future work, it might be good to research the performance of rewriting
> "col ILIKE 'pattern'" to "lower(col) LIKE lower('pattern')" in planner so that
> we can avoid to call lower() for constant pattern in the right-hand side and
> can use functional indexes (lower(col)). I think we never need MBMatchTextIC()
> in the future unless we move to wide-character server encoding :)
>
> Regards,
> ---
> ITAGAKI Takahiro
> NTT Open Source Software Center
>
[ Attachment, skipping... ]
[ Attachment, skipping... ]
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Minor recovery changes
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Simon Riggs wrote: > As discussed on -hackers and -admin... a few minor changes, rolled into > a single patch. > > - check we have an archiver to carry away WAL files at shutdown > (was part of task 1) > > - archive_mode GUC, on which archive_command is dependent > closing loophole to avoid data loss with wal-avoiding commands > (was task 10) > > - %r option in recovery.conf sends last restartpoint to recovery command > (was task 3) > > - %r handled in pg_standby, updated README > (was task 4) > > - code cleanup of pg_standby in various minor places > > - doc on Warm Standby now includes pg_standby and %r > > - log_restartpoints shows LOG message for at each restartpoint, rather > than DEBUG2 e.g. > LOG: recovery restart point at 0/4220 > (was task 5) > > - end of recovery now displays last transaction end time, as requested > by Warren Little e.g. > LOG: last completed transaction was at log time 2007-04-08 18:07:11 BST > also shown at each restartpoint > (discussed on -admin, mar 30) > > TODO (by me) > > - docs need another thorough refresh to pick up minor mentions of > archive_command -> archive_mode > > - work out how to keep archiver alive long enough to archive last WAL > file after a shutdown checkpoint... trickier than I imagined since it > overlaps need for fast exit when performing restart, per last edit of > the archiver code. > > - agree whether to allow pg_stop_backup() to exit before file archived > > Applies cleanly to CVS HEAD. Updated test files, all options tested. > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 5: don't forget to increase your free space map settings -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] RESET SESSION v3
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Marko Kreen wrote: > Changes in v3: > > * DEALLOCATE PREPARE ALL > * RESET PLANS wont check for ACL_CREATE_TEMP anymore. > * Add prepare.h and portal.h to guc.c. > > > On 4/7/07, Neil Conway <[EMAIL PROTECTED]> wrote: > > > * RESET SESSION does not ABORT anymore, instead fails if in transaction. > > > I think it's quite bizarre to have RESET SESSION fail if used in a > > transaction, but to allow an equivalent sequence of commands to be > > executed by hand inside a transaction. > > I think implicit ABORT would annoy various tools that > partially parse user sql and expect to know what transaction > state currently is. For them a new tranaction control statement > would be nuisance. > > > guc.c is missing some #includes. > > For some reason gcc4.0 did not show any warnings by default. > > > > * DEALLOCATE PREPARE ALL gives bison conflicts. Is that even needed? > > > > Seems best to have it, for the sake of consistency. The shift/reduce > > conflict is easy to workaround, provided you're content to duplicate the > > body of the DEALLOCATE ALL rule -- e.g. see the attached incremental > > diff. > > Thanks, included. > > > > * Are the CommandComplete changes needed? > > > > Seems warranted to me. BTW, why is CLOSE's command tag "CLOSE CURSOR", > > not "CLOSE"? That seems needlessly verbose, and inconsistent with other > > commands (e.g. DEALLOCATE). > > Because the regular tag is "CLOSE CURSOR". I did not > want to break any expectations. But yes, the inconsistency > is weird. > > > > * ResetPlanCache() is implemented as PlanCacheCallback((Datum)0, > > > InvalidOid); That seems to leave plans for utility commands untouched. > > > Is it problem? > > > > Yes, I'd think you'd also want to cleanup plans for utility commands. > > Tom thought otherwise, so I kept the old way. > > > -- > marko [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] non-recursive WITH clause support
On Mon, Apr 09, 2007 at 06:43:08PM -0400, Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > Here's an updated patch that fixes the bug I had. This is now functional > > basic > > non-recursive WITH clause support. > > http://community.enterprisedb.com/recursive/with-pg82stable-v2.patch.gz > > It's a pretty short simple patch as is; it just directly inlines any WITH > > clauses as if they had been written as subqueries. > > So this does not really add any new functionality, it's just variant > syntax for something you can do about as easily without it, right? Not totally as easily. For example, you can do some kinds of aggregation with a few fewer keystrokes. > The downside that I see is is that it changes WITH and SET into fully > reserved words, which no doubt will break a few people's applications. Really? > While we're probably going to have to do that eventually, I'd like > to be able to point to some non-negligible benefit resulting from > the change when we do it. > > So my inclination is to not apply this in its current form, but to > wait for the full recursive-WITH feature before taking the > compatibility hit. Is there some way to poll people for uses of WITH and SET in places they shouldn't be? Cheers, D -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] non-recursive WITH clause support
Gregory Stark <[EMAIL PROTECTED]> writes: > Here's an updated patch that fixes the bug I had. This is now functional basic > non-recursive WITH clause support. > http://community.enterprisedb.com/recursive/with-pg82stable-v2.patch.gz > It's a pretty short simple patch as is; it just directly inlines any WITH > clauses as if they had been written as subqueries. So this does not really add any new functionality, it's just variant syntax for something you can do about as easily without it, right? The downside that I see is is that it changes WITH and SET into fully reserved words, which no doubt will break a few people's applications. While we're probably going to have to do that eventually, I'd like to be able to point to some non-negligible benefit resulting from the change when we do it. So my inclination is to not apply this in its current form, but to wait for the full recursive-WITH feature before taking the compatibility hit. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Arrays of Complex Types
On Mon, Apr 09, 2007 at 04:07:16PM -0400, Andrew Dunstan wrote: > Some type systems have named array types, some don't. I can live happily > with either. Are array types anonymous in the standard? Yes, they're anonymous in the standard. That doesn't mean we can't give them names if we wanted... > At any rate, the point of the remark was to take this off the table for now. Sure, once the array types are created automatically the command becomes completely redundant. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] UTF8MatchText
Patch removed, updated version submitted. --- ITAGAKI Takahiro wrote: > "Andrew - Supernews" <[EMAIL PROTECTED]> wrote: > > > ITAGAKI> I think all "safe ASCII-supersets" encodings are comparable > > ITAGAKI> by bytes, not only UTF-8. > > > > This is false, particularly for EUC. > > Umm, I see. I updated the optimization to be used only for UTF8 case. > I also added some inlining hints that are useful on my machine (Pentium 4). > > > x1000 of LIKE '%foo% on 1 rows tables [ms] > encoding | HEAD | P1 | P2 | P3 > ---+---+---+---+--- > SQL_ASCII | 7094 | 7120 | 7063 | 7031 > LATIN1| 7083 | 7130 | 7057 | 7031 > UTF8 | 17974 | 10859 | 10839 | 9682 > EUC_JP| 17032 | 17557 | 17599 | 15240 > > - P1: UTF8MatchText() > - P2: P1 + __inline__ GenericMatchText() > - P3: P2 + __inline__ wchareq() > (The attached patch is P3.) > > Regards, > --- > ITAGAKI Takahiro > NTT Open Source Software Center > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Martijn van Oosterhout wrote: On Mon, Apr 09, 2007 at 10:14:41AM -0400, Andrew Dunstan wrote: . defer for the present any consideration of a "CREATE TYPE foo AS ARRAY ..." command. What is the rationale for allowing people to name the array type. When I originally proposed the syntax I presumed that the array name would be kept internal and hidden from the user, just that it would exist after that command. What possible reason is there for allowing the user to give the array type a name? Have a nice day, Some type systems have named array types, some don't. I can live happily with either. Are array types anonymous in the standard? At any rate, the point of the remark was to take this off the table for now. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Arrays of Complex Types
On Mon, Apr 09, 2007 at 10:14:41AM -0400, Andrew Dunstan wrote: > . defer for the present any consideration of a "CREATE TYPE foo AS ARRAY > ..." command. What is the rationale for allowing people to name the array type. When I originally proposed the syntax I presumed that the array name would be kept internal and hidden from the user, just that it would exist after that command. What possible reason is there for allowing the user to give the array type a name? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [PATCHES] [HACKERS] Arrays of Complex Types
On Mon, Apr 09, 2007 at 10:40:49AM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Regarding catalog objects, we might have to try a little harder than
> > just not generating in bootstrap mode - IIRC we generate system views
> > (including pg_stats) in non-bootstrap mode. Maybe we just need to exempt
> > anything in the pg_catalog namespace. What would happen if a user
> > created a view over pg_statistic?
>
> Nothing:
>
> regression=# create view vvv as select * from pg_statistic;
> ERROR: column "stavalues1" has pseudo-type anyarray
>
> which means we do have an issue for the pg_stats view. Now that I look
> instead of guessing, the existing test in CheckAttributeType is not on
> bootstrap mode but standalone mode:
>
> /* Special hack for pg_statistic: allow ANYARRAY during initdb */
> if (atttypid != ANYARRAYOID || IsUnderPostmaster)
> ereport(ERROR,
> (errcode(ERRCODE_INVALID_TABLE_DEFINITION),
> errmsg("column \"%s\" has pseudo-type %s",
> attname, format_type_be(atttypid;
>
> so for consistency we should use the same condition to suppress types
> for system catalogs.
Groovy :)
> > Or maybe we should go to the heart
> > of the problem and simply check for pseudo-types directly.
>
> Actually we may have an issue already:
>
> regression=# create table zzz (f1 pg_statistic);
> CREATE TABLE
>
> I couldn't make it misbehave in a short amount of trying:
>
> regression=# insert into zzz
> values(row(0,0,0,0,0,0,0,0,0,0,0,0,0,array[1,2],null,null,null,array[12,13],null,null,null));
> ERROR: ROW() column has type integer[] instead of type anyarray
>
> but I don't feel comfortable about this at all. Maybe
> CheckAttributeType should be made to recurse into composite columns.
That'd be great :)
Cheers,
D
--
David Fetter <[EMAIL PROTECTED]> http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
Skype: davidfetter
Remember to vote!
Consider donating to PostgreSQL: http://www.postgresql.org/about/donate
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Regarding catalog objects, we might have to try a little harder than
> just not generating in bootstrap mode - IIRC we generate system views
> (including pg_stats) in non-bootstrap mode. Maybe we just need to exempt
> anything in the pg_catalog namespace. What would happen if a user
> created a view over pg_statistic?
Nothing:
regression=# create view vvv as select * from pg_statistic;
ERROR: column "stavalues1" has pseudo-type anyarray
which means we do have an issue for the pg_stats view. Now that I look
instead of guessing, the existing test in CheckAttributeType is not on
bootstrap mode but standalone mode:
/* Special hack for pg_statistic: allow ANYARRAY during initdb */
if (atttypid != ANYARRAYOID || IsUnderPostmaster)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TABLE_DEFINITION),
errmsg("column \"%s\" has pseudo-type %s",
attname, format_type_be(atttypid;
so for consistency we should use the same condition to suppress types
for system catalogs.
> Or maybe we should go to the heart
> of the problem and simply check for pseudo-types directly.
Actually we may have an issue already:
regression=# create table zzz (f1 pg_statistic);
CREATE TABLE
I couldn't make it misbehave in a short amount of trying:
regression=# insert into zzz
values(row(0,0,0,0,0,0,0,0,0,0,0,0,0,array[1,2],null,null,null,array[12,13],null,null,null));
ERROR: ROW() column has type integer[] instead of type anyarray
but I don't feel comfortable about this at all. Maybe
CheckAttributeType should be made to recurse into composite columns.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Arrays of Complex Types
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: How would we do that? Not create the array types in bootstrap mode? Or just special-case pg_statistic? Not generate them in bootstrap mode works for me. IIRC, there's code somewhere in there that allows anyarray to pass as a column type in bootstrap mode, so that seems to fit ... OK, summarising what looks to me like a consensus position, ISTM the plan could be: . fix makeArrayTypeName() or similar to make it try harder to generate a unique non-clashing name . remove the existing "62 instead of 63" name length restrictions . autogenerate array types for all explicitly or implicitly created composite types other than for system catalog objects. . defer for the present any consideration of a "CREATE TYPE foo AS ARRAY ..." command. Regarding catalog objects, we might have to try a little harder than just not generating in bootstrap mode - IIRC we generate system views (including pg_stats) in non-bootstrap mode. Maybe we just need to exempt anything in the pg_catalog namespace. What would happen if a user created a view over pg_statistic? Should the test be to avoid arrays for things that depend on the catalogs? Or maybe we should go to the heart of the problem and simply check for pseudo-types directly. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] autovacuum multiworkers, patch 5
ITAGAKI Takahiro wrote: > > > >Yes, that's correct. Per previous discussion, what I actually wanted to > > > >do was to create a GUC setting to simplify the whole thing, something > > > >like "autovacuum_max_mb_per_second" or "autovacuum_max_io_per_second". > > > >Then, have each worker use up to (max_per_second/active workers) as much > > > >IO resources. > > > > One thing I forgot to mention is that this is unlikely to be implemented > > in 8.3. > > This is a WIP cost balancing patch built on autovacuum-multiworkers-5.patch. > The total cost of workers are adjusted to autovacuum_vacuum_cost_delay. > > I added copy of worker's cost parameters to the shared WorkerInfo array. > A launcher and each worker reads and writes the copied parameters when > a worker starts a vacuum job or exit the process. Workers assign their local > VacuumCostDelay from the shared value every sleep in vacuum_delay_point(). Thanks! I had already incorporated the foreach_worker changes into my code, and later realized that there's an important bug regarding the PGPROC of the workers, so I've reworked the patch, which meant that the foreach_worker() macro went away completely. I'll put it your changes in my current WIP patch; if you do any further work on it, please let me have it to include it in the latest work. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Minor recovery changes
Simon Riggs wrote: > On Sun, 2007-04-08 at 23:02 -0400, Bruce Momjian wrote: > > Simon, do you have email access while you are away for two weeks? Can > > you answer questions via email? > > It's not a complete blackout, if I check through... > > Irregular email 10-12 Apr > Now available 17 Apr half day Ah, Now -> Not. > Email 19, 21 Apr eve I am confused. What about April 13-16? You are available during the days you do not mention, I assume. Anyway, being able to check email once a day and reply to a personal question to you is sufficient to allow us to move the patches forward. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
From: "ITAGAKI Takahiro" <[EMAIL PROTECTED]> The attached patch clears up the usage of strxfrm() on Windows. If the server encoding is UTF-8 and the locale is not C, we should use wcsxfrm() instead of strxfrm() because UTF-8 locale are not supported on Windows. We've already have a special version of strcoll() for Windows, but the usage of strxfrm() was still broken. When we are caught up in the bug, we see the next error message. | ERROR: invalid memory alloc request size 2147483648 If the server is wrong configured between the server encoding and the locale, strxfrm() could be failed and return values like INT_MAX or (size_t)-1. We've passed the result+1 straight to palloc(), so the server tried to allocale more than 1GB of memory and gave up. Ahh..., Certainly, the bug lurked there. probably, your patch will help it. It was not pursued in Japan for the reasons that the locale had been recommended to be used by C up to now. however, It seems to have caused the user's confusion. In that sense, I vote.+1 But, I am skeptic the locale setting still functions correctly. However, I think it is great work.:-) Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] autovacuum multiworkers, patch 5
> > >Yes, that's correct. Per previous discussion, what I actually wanted to > > >do was to create a GUC setting to simplify the whole thing, something > > >like "autovacuum_max_mb_per_second" or "autovacuum_max_io_per_second". > > >Then, have each worker use up to (max_per_second/active workers) as much > > >IO resources. > > One thing I forgot to mention is that this is unlikely to be implemented > in 8.3. This is a WIP cost balancing patch built on autovacuum-multiworkers-5.patch. The total cost of workers are adjusted to autovacuum_vacuum_cost_delay. I added copy of worker's cost parameters to the shared WorkerInfo array. A launcher and each worker reads and writes the copied parameters when a worker starts a vacuum job or exit the process. Workers assign their local VacuumCostDelay from the shared value every sleep in vacuum_delay_point(). I agree that "mb_per_second" or "io_per_second" are easier to use than present cost delay parameters, but we need more research to move to it. I think it is better to keep "cost_limit" and "cost_delay" as of 8.3, but we need cost-balanced multiworkers at any rate. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center autovacuum_balance.patch Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows
The attached patch clears up the usage of strxfrm() on Windows. If the server encoding is UTF-8 and the locale is not C, we should use wcsxfrm() instead of strxfrm() because UTF-8 locale are not supported on Windows. We've already have a special version of strcoll() for Windows, but the usage of strxfrm() was still broken. When we are caught up in the bug, we see the next error message. | ERROR: invalid memory alloc request size 2147483648 If the server is wrong configured between the server encoding and the locale, strxfrm() could be failed and return values like INT_MAX or (size_t)-1. We've passed the result+1 straight to palloc(), so the server tried to allocale more than 1GB of memory and gave up. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center fix_strxfrm.patch Description: Binary data ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
