Re: [HACKERS] Fwd: index corruption in PG 8.3.13

Hi, >>> 1. Somebody inserts a bunch of new tuples into the relation, causing >>> growth in the index. >> >> In case it's not obvious VACUUM FULL would do precisely that. > > Oh, I didn't even think about that.  Yeah, that could be it, too. Thanks a lot Greg and Robert. This theory seems very plau

Re: [HACKERS] Fwd: index corruption in PG 8.3.13

Hi, >> "Other peculiarity in the index file is that we found a lot of zeroed >> out pages. Blocks from #279 to #518 are all completely zeroed out >> without any signs of even a page header. Any ideas on how we can get >> so many zeroed out blocks? Apart from the extend code path, I fail to >> see

Re: [HACKERS] Fwd: index corruption in PG 8.3.13

> > What does stat say for the index data file? Are the Size and Blocks > values the same (modulo block size)? Or are these blocks actually not > allocated? > stat 58401 File: `58401' Size: 4300800 Blocks: 8400 IO Block: 4096 regular file Device: 801h/2049d Inode: 13901264

Re: [HACKERS] Fwd: index corruption in PG 8.3.13

Hi, >>> Blocks 519 to 521 are DELETED. They do not have the LEAF flag set, >>> meaning they could be internal pages, but that is strange since ROOT >>> page is at level 1. Also importantly their next XID is set FrozenXid, >>> meaning VACUUM FULL was at play. Maybe due to deletes, we reduced the >>

Re: [HACKERS] Fwd: index corruption in PG 8.3.13

>> Ouch. Attempting to attach the dotty image again.. > > I don't understand this graph.  What are the arrows?  Downlinks or > sibling pointers? > Sorry, they are sibling previous and next pointers. The ROOT is at level 1, rest all live blocks are at level 0. #524 is the leftmost page. Regards, N

[HACKERS] Fwd: index corruption in PG 8.3.13

Re-sending without the attachments. Can someone please allow my attachments through from the previous email? TIA Nikhils -- Forwarded message -- From: Nikhil Sontakke Date: Wed, Mar 9, 2011 at 8:42 PM Subject: index corruption in PG 8.3.13 To: pgsql-hackers@postgresql.org Hi

Re: [HACKERS] pg_depend dependency and concurrent DDL issues in PG 8.3.x

>> I see that all these issues have been fixed and committed by Tom via >> git commitid: 281a724d on 6th June, 2008. Was wondering why this fix >> is not in these supported branches like 8.3.13 for example. Kinda >> confused.. > > We don't usually back-patch such large changes. Oh ok. Thanks. Reg

[HACKERS] pg_depend dependency and concurrent DDL issues in PG 8.3.x

Hi, Am referring to the following conversation: http://archives.postgresql.org/pgsql-bugs/2007-12/msg00190.php To summarize, in 8.3.x due to improper locking and concurrency issues in the DROP OBJECT codepath, for example if one tries to drop an index while dropping the table from another sessio

Re: [HACKERS] PG signal handler and non-reentrant malloc/free calls

> > No, the question is why is the ImmediateInterruptOK flag set.  Whether > the interrupt actually happens isn't that relevant.  You could try > setting a watchpoint on the flag variable. > >> But adding hold/resume interrrupts in mcxt.c (not aset.c, since we >> want to be agnostic to the underlyi

Re: [HACKERS] PG signal handler and non-reentrant malloc/free calls

On Tue, Mar 1, 2011 at 10:17 PM, Heikki Linnakangas wrote: > On 01.03.2011 12:50, Nikhil Sontakke wrote: >>> >>>> Will try to get the call stack if needed. >>> >>> Yes, please. >> >> Here is the stack trace: > > Hmm, it looks like Imm

Re: [HACKERS] PG signal handler and non-reentrant malloc/free calls

> >> Will try to get the call stack if needed. > > Yes, please. > Here is the stack trace: #0 0xe410 in __kernel_vsyscall () #1 0xb7ee676e in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0xb7e82e41 in _L_lock_4214 () from /lib/libc.so.6 #3 0xb7e80048 in free () from /lib/libc.so.6 #4

[HACKERS] PG signal handler and non-reentrant malloc/free calls

Hi, I believe we have a case where not holding off interrupts while doing a malloc() can cause a deadlock due to system or libc level locking. In this case, a pg_ctl stop in fast mode was resorted to and that caused a backend to handle the interrupt when it was inside the malloc call. Now as part

[HACKERS] Favorable i--)

Hi, a very good business company, I suggest you go to see: mobiles3gs.com, and now all of products enjoy great discount, saving time and money. h--) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgs

Re: [HACKERS] possible memory leak with SRFs

>> Yeah this is my basic confusion. But wouldn't the arguments be >> evaluated afresh on the subsequent call for this SRF? > > No, see ExecMakeFunctionResult().  If we did that we'd have serious > problems with volatile functions, ie srf(random()). > Ok thanks. So if someone uses a really long-run

Re: [HACKERS] possible memory leak with SRFs

Hi, >> Can someone please explain why we do not reset the expression context >> if an SRF is involved during execution? > > Consider >        srf(foo(col)) > where foo returns a pass-by-reference datatype.  Your proposed patch > would cut the knees out from under argument values that the SRF could

Re: [HACKERS] possible memory leak with SRFs

multi-call context" anyways. And > AIUI, SRFs return tuples one-by-one or do we materialize the same into > a tuplestore in some cases? > > Regards, > Nikhils > > On Wed, May 5, 2010 at 7:23 PM, Nikhil Sontakke > wrote: >> Hi, >> >> I saw this behavio

Re: [HACKERS] possible memory leak with SRFs

ntext" anyways. And AIUI, SRFs return tuples one-by-one or do we materialize the same into a tuplestore in some cases? Regards, Nikhils On Wed, May 5, 2010 at 7:23 PM, Nikhil Sontakke wrote: > Hi, > > I saw this behavior with latest GIT head: > > create table xlarge(val numeric(19,

[HACKERS] possible memory leak with SRFs

Hi, I saw this behavior with latest GIT head: create table xlarge(val numeric(19,0)); insert into xlarge values(generate_series(1,5)); The above generate series will return an int8 which will then be casted to numeric (via int8_to_numericvar) before being inserted into the table. I observed that

Re: [HACKERS] row estimation off the mark when generate_series calls are involved

Hi, > I'm not very impressed with that patch, even discounting the > sum-vs-product thinko.  Trawling the tlist for SRFs will add a significant > number of cycles, to modify the rowcount in a way that is practically > always wrong (since the estimates for SRF output rowcounts are so bad). It's tr

Re: [HACKERS] CTAS not honoring NOT NULL, DEFAULT modifiers

>> Was wondering what are the standards for CTAS. Oracle seems to honor >> the NOT NULL modifier. This might be a bug if we do not honor >> modifiers in CTAS. > > Given that CREATE TABLE AS creates a table based on the result of a > query, it seems pretty logical that constraints wouldn't be copied

[HACKERS] row estimation off the mark when generate_series calls are involved

Another email which went into the wilderness when I sent it to pgsql-patches. Regards, Nikhils -- Forwarded message -- From: Nikhil Sontakke Date: Fri, Apr 16, 2010 at 6:50 PM Subject: row estimation off the mark when generate_series calls are involved To: pgsql-patc

[HACKERS] CTAS not honoring NOT NULL, DEFAULT modifiers

Guess no-one got to read this email. I sent it to pgsql-patches without realizing that it is a dead-list. Shouldn't we atleast bounce emails back to senders if they send an email to pgsql-patches? Regards, NIkhils -- Forwarded message -- From: Nikhil Sontakke Date: Fri,

Re: [HACKERS] plpgsql: numeric assignment to an integer variable errors out

Hi, > Now it is true that a lot of the uses for that were subsumed when > we added coerce-via-IO to the native cast capabilities; but I'm > still quite scared of what this would break, and I don't see any > field demand for a change. Well, we have had one of our EDB connectors facing issues becau

Re: [HACKERS] Why doesn't query_tree_walker examine the intoClause field?

PM, Nikhil Sontakke wrote: > Hi, > > I am kinda puzzled as to why the query_tree_walker() function does not > examine the intoClause field? I do see another function > raw_expression_tree_walker() which does walk that entry. So what is > the exact reason here? Or we just missed

[HACKERS] Why doesn't query_tree_walker examine the intoClause field?

Hi, I am kinda puzzled as to why the query_tree_walker() function does not examine the intoClause field? I do see another function raw_expression_tree_walker() which does walk that entry. So what is the exact reason here? Or we just missed it for the earlier function? Regards, Nikhils -- http://

Re: [HACKERS] Partitioning option for COPY

Hi, >> What would probably be helpful here is to take the mess of raw data >> above and turn it into a simpler partitioning roadmap. > > Thanks for summarising. > Yeah, excellent summary Greg. As you rightly pointed out, partitioning needs a broad roadmap so that the community can contribute in u

Re: [HACKERS] Syntax for partitioning

Hi, >> > partinfo = (PartitionInfo *) malloc(ntups * sizeof(PartitionInfo)); > > 1) Please stop casting the results of palloc and malloc.  We are not > writing C++ here. > I thought it was/is a good C programming practice to typecast (void *) always to the returning structure type!! Regards, Nik

Re: [HACKERS] Patch committers

Hi, > True, but even I avoid patches I don't understand, and "practicing" by > applying them could lead to a very undesirable outcome, e.g. > instability. > How about having a staging server to help around novice committers? Basically the selected new band of people can take a patch, review it an

Re: [HACKERS] Syntax for partitioning

Hi, >> Is this the same as / similar to Oracle's syntax? > > Yes. > >> IIRC Nikhil's patch was Oracle's syntax > > No. See: > http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/statements_7002.htm#i2125922 > Any decent prevalent partitioning syntax should be ok IMHO. IIRC, MySQL parit

Re: [HACKERS] Syntax for partitioning

Hi, > So, I'll take over the work if there are no ones to do it. > I'm thinking to add syntax support first. Table partitioning was > proposed many times, but it is still not applied into core. > The reason is it is too difficult to make perfect partitioning > feature at once. I think syntax suppo

Re: [HACKERS] Ragged CSV import

Hi, > the two most > useful are to read in only some of the defined columns, and to output > to > a separate disk file any rows which failed to match the expected > format. > The latter would not cause the copy to fail unless the count of such > rows exceeded a user-specified threshold. > +1 All

Re: [HACKERS] UPDATE ... SET (a, b, c) = (expr)

Hi Alvaro, > >> But then there's the matter of how to represent it from the grammar >> inwards.  At first I thought of creating a new parse node type, say >> MultiResTarget that would replace ResTarget in UpdateStmt, and get it >> from there into the optimizer and executor. > > Hmm, I should be pa

Re: [HACKERS] [PATCH] DefaultACLs

Hi, > I'd still like to have opinion from one of the commiters on "the > VIEW problem" which also affects grant on all patch ( see > http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and > I fear "returned with feedback" might prevent that until next commit fest. > > > I see pote

Re: [HACKERS] [PATCH] DefaultACLs

Hi, > >> Anyway, while this patch might not necessary get commited in this commit >> fest, I'd still like to have opinion from one of the commiters on "the VIEW >> problem" which also affects grant on all patch ( see >> http://archives.postgresql.org/pgsql-hackers/2009-07/msg00957.php ) and I >> f

Re: [HACKERS] GRANT ON ALL IN schema

Hi, > Nikhil, > > This is still flagged as Needs Review.  Are you still reviewing the > latest version, or should this be set to ready for committer, or what? > The review is complete from my side. There is this question about consistency between this patch and the Defaultacls patch. But am ok wi

Re: [HACKERS] [PATCH] DefaultACLs

Hi, >> I briefly looked at the DefaultACLs patch. Can you not re-use the >> GrantStmt structure for the defaults purpose too? You might have to >> introduce an "is_default" boolean similar to the "is_schema" boolean >> that  you have added in the "GRANT ON ALL" patch. If you think you can >> re-us

Re: [HACKERS] GRANT ON ALL IN schema

Hi, > > Attached is v2 with slightly improved code, nothing has changed > feature-wise. > Here are some comments on this patch from my side: grant.sgml * Maybe we should use schemaname in the sgml references instead of just schemaname +There is also the posibility of granting permissions t

Re: [HACKERS] [PATCH] DefaultACLs

Hi, >> > > No, DefaultACLs applies to objects created in the future while GRANT ON ALL > affects existing objects. I see. > DefaultACLs is more important functionality so it should probably take > precedence in review process. > > There is however one thing that needs some attention. Both patche

Re: [HACKERS] [PATCH] DefaultACLs

Hi Petr, > this is first public version of our DefaultACLs patch as described on > http://wiki.postgresql.org/wiki/DefaultACL . I have been assigned by Robert to do an initial review of your "GRANT ON ALL" patch mentioned here (http://archives.postgresql.org/pgsql-hackers/2009-07/msg00207.php) D

Re: [HACKERS] 8.5 development schedule

Hi, >> However, if anything, I think if anything we should go the other way >> and start the first CommitFest July 15th. > > I'm curious what the counter-arguments to this are.  Is it > review-fatigue from getting the release out, or is there an economy of > scale to building up a 100 patches bef

Re: [HACKERS] Patch for automating partitions in PostgreSQL 8.4 Beta 2

Hi, > > The patch automates table partitioning to support Range and Hash > partitions. Please refer to attached readme file for further details. > > The syntax used conforms to most of the suggestions mentioned in > http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring > the

Re: [HACKERS] ruby connect

Hi, > I’m trying to connect ruby to postgres on ubuntu and the only link I found > that has the library is down. Does anyone have the postgres library for > ruby? Or direct me to it? > > You would be better off searching for the drivers on rubyforge.org. Please do not send non-Postgres-developm

Re: [HACKERS] Throw some low-level C scutwork at me

Hi, > > OK, so, when I initially started catching up on this thread, I was > > kind of feeling annoyed at Tom, and I still wish he'd say something > > along the lines of "I did not mean to give offense and I'm sorry if my > > words came across in a way that I did not intend" rather than just > > e

Re: [HACKERS] Automating Partitions in PostgreSQL - Query on syntax

> > >> > (...) > >> > PARTITION BY RANGE (emp_id) > >> > ( > >> > emp_500 (START 1 END 500), > >> > emp_1500 (START 500 END 1500), > >> > emp_4000 (START 1520 END 4000) > >> > ); > >> > >> What if I need more columns to set the partitions? > > > > > > You can do so by using command like this, > > >

Re: [HACKERS] Bug of ALTER TABLE DROP CONSTRAINT

Hi, > We've discussed before the idea that NOT NULL constraints should be > explicitly represented in pg_constraint, just like general CHECK > constraints (this would allow them to be named, have sane inheritance > behavior, etc). If we had that, then pg_attribute.attnotnull could > indicate the

Re: [HACKERS] Bug of ALTER TABLE DROP CONSTRAINT

Hi, > >> > >> Making a column into the primary key forces the column to NOT NULL. > >> You'll need to DROP NOT NULL separately. > >> > >> It's probably possible to beat on the code hard enough to fix this, > > > > Yeah it will be a matter of finding the affected column entries and > invoking > > t

Re: [HACKERS] Bug of ALTER TABLE DROP CONSTRAINT

Hi, > > Considering the following sequence: > >create table t(a int primary key); > >alter table t drop constraint t_pkey; > >insert into t values(null); > >ERROR: null value in column "a" violates not-null constraint > > > > My question is, why "null" is not allowed to be inserte

Re: [HACKERS] Partitioning feature ...

Hi, > We already have system triggers -- the FK triggers. I don't think we've >>> had all that much trouble with them. >>> >>> >> >> In the case of the FK triggers, it's intentional (and maybe even >> documented) that users should be able to place their own triggers before >> or after the FK trig

Re: [HACKERS] Partitioning feature ...

Hi, > > >> As triggers are executed in order of their names, we've prefixed the > >> trigger names with "zz". This should work fine as long as no-one uses > >> trigger-name which starts with "zz". > >> > > this seems a lot fragile... why system generated triggers has to be > executed following th

Re: [HACKERS] Partitioning feature ...

Hi Kedar, > > > The syntax used conforms to most of the suggestions mentioned in > http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring > the following: > -- Specification of partition names is optional. System will be able to > generate partition names in such cases. > -- Su

Re: [HACKERS] cross-compiling plpython

> > So, I realized that there does not seem to be an easy way for cross >> compiling plpython. The configure checks for the locally installed python >> include locations and eventually the plpython makefile ends up picking all >> the local includes too. >> Does anyone have any experiences on cross-

[HACKERS] cross-compiling plpython

So, I realized that there does not seem to be an easy way for cross compiling plpython. The configure checks for the locally installed python include locations and eventually the plpython makefile ends up picking all the local includes too. Does anyone have any experiences on cross-compiling plpyth

[HACKERS] gcc: why optimize for size flag is not the default

Hi, I was wondering why -Os is not used in place of -O2 while compiling the Postgres sources with gcc. I prepared 2 install directories by respectively using -Os and -O2 flags and in the former case it seems to reduce the install footprint by about 1MB or so. Agreed this is not significant for nor

Re: [HACKERS] composite types DROP..CASCADE behaviour - bug or intentional?

> > > Consider the following on latest sources: > > postgres=# create type c3 as (y int, z c1); Oops, please disregard the above copy-paste unwanted sql. > > postgres=# create type comptype1 as (elem1 int); > > postgres=# create type comptype2 as (elem1 int, elem2 comptype1); > postgres=# \d co

[HACKERS] composite types DROP..CASCADE behaviour - bug or intentional?

Hi, Consider the following on latest sources: postgres=# create type c3 as (y int, z c1); postgres=# create type comptype1 as (elem1 int); postgres=# create type comptype2 as (elem1 int, elem2 comptype1); postgres=# \d comptype2 Composite type "public.comptype2" Column | Type +---

[HACKERS] float8 strtod weirdness

Hi, Consider the following with latest CVS sources: postgres=# create table temp(val float4); CREATE TABLE postgres=# insert into temp values (415.1); INSERT 0 1 postgres=# select * from temp where val = 415.1; val - (0 rows) !? The reason seems to be that 415.1 ends up being treated as a

Re: [HACKERS] plpgsql: numeric assignment to an integer variable errors out

Hi, > > > >> The following plpgsql function errors out with cvs head: > >> > >> CREATE function test_assign() returns void > >> AS > >> $$ declare x int; > >> BEGIN > >> x := 9E3/2; > >> END > >> $$ LANGUAGE 'plpgsql'; > >> > >> postgres=# select test_assign(); > >> ERROR: invalid input syntax fo

Re: [HACKERS] plpgsql: numeric assignment to an integer variable errors out

Hi, wrote: > The following plpgsql function errors out with cvs head: > > CREATE function test_assign() returns void > AS > $$ declare x int; > BEGIN > x := 9E3/2; > END > $$ LANGUAGE 'plpgsql'; > > postgres=# select test_assign(); > ERROR: invalid input syntax for integer: "4500.00

Re: [HACKERS] Partitioning wiki page

Hi, > At the moment, all you've done is show examples of how Oracle does >> partitioning and restate my requirements document, significant chunks >> completely verbatim. If you do that I think it fair to ask for a >> specific credit on that. But even so, thank you for the compliment. >> >> It was

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi, > I will be working on a roadmap for the partitioning features. I think that > there are different needs and that we will not be able to address them all > in 8.5 or even 8.6. > The goal will be to get things done step by step but possibly with a design > that will not require major refactori

[HACKERS] plpgsql: numeric assignment to an integer variable errors out

The following plpgsql function errors out with cvs head: CREATE function test_assign() returns void AS $$ declare x int; BEGIN x := 9E3/2; END $$ LANGUAGE 'plpgsql'; postgres=# select test_assign(); ERROR: invalid input syntax for integer: "4500." CONTEXT: PL/pgSQL function "tes

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi, > > > The status has always being WIP, because what has not happened is that we > > have not had consensus on whether this is a logical first baby step ahead > > with partitioning. I haven't seen core members commenting on whether > trying > > to aggregate the current set of manual operations

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi, > i review it on nov 6, and there were open questions by me and by > > Emmanuel none of those has been answered: > > http://archives.postgresql.org/pgsql-hackers/2008-11/msg00362.php > > Hmm, there's only one actual question in that email, which is a > request for ideas about PL/pgsql vs. C.

[HACKERS] No write stats in pg_statio system views

Hi, What is the reason for not having heap_blks_write kind of stats in the pg_statio system views? Is it because bgwriter does the writing (we do have bg stats there) most of the times? Wouldn't the write stats help to get the complete IO picture for the relation? Regards, Nikhils -- http://www.

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi, > > > > >> > > >> Thanks for taking a look. But if I am not mistaken Gavin and co. >> are >> > working >> > > >> on a much exhaustive proposal. In light of that maybe this patch >> might >> > not >> > > >> be needed in the first place? >> > > >> >> > > >> I will wait for discussion and a subs

Re: [HACKERS] Fwd: [PATCHES] Auto Partitioning Patch - WIP version 1

Hi, On Wed, Oct 22, 2008 at 8:14 PM, Jaime Casanova < [EMAIL PROTECTED]> wrote: > just remembering that -patches is a dead list, so i'm sending this to > -hackers where it will have more visibility... > > -- Forwarded message ------ > On 10/22/08, Nikhil

<    1   2