Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

2011/8/5 Robert Haas : > On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai wrote: >> BTW, what is the current status of this patch? > > I think it's waiting for me to get around to reviewing it.  Sorry, > been busy :-( > Thanks for your efforts. >> The status of contrib/sepgsql part is unclear for

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

> > However, for small operations it's a net loss - you avoid writing a WAL > record, but you have to fsync() the heap instead. If you only modify a few > rows, the extra fsync (or fsyncs if there are indexes too) is more expensive > than writing the WAL. > > We'd need a heuristic to decide whether

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

Jeff Davis wrote: > On Thu, 2011-08-04 at 18:07 -0400, Bruce Momjian wrote: > > I am confused how generating WAL traffic that is larger than the heap > > file we are fsync'ing can possibly be slower. Are you just throwing out > > an idea to try to make me prove it? > > That's worded in a slightly

Re: [HACKERS] cataloguing NOT NULL constraints

Excerpts from Tom Lane's message of vie ago 05 21:23:41 -0400 2011: > Peter Eisentraut writes: > > On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote: > >> Yeah, perhaps you're right. The main reason they were considered > >> separately is that we wanted to have them to be optimized via > >>

Re: [HACKERS] cataloguing NOT NULL constraints

Peter Eisentraut writes: > On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote: >> Yeah, perhaps you're right. The main reason they were considered >> separately is that we wanted to have them to be optimized via >> pg_attribute.attnotnull, but my patch does away with the need for that >> bec

Re: [HACKERS] error: could not find pg_class tuple for index 2662

daveg writes: > Should this be applied in addition to the earlier patch, or to replace it? Apply it instead of the earlier one. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postg

Re: [HACKERS] error: could not find pg_class tuple for index 2662

On Fri, Aug 05, 2011 at 12:10:31PM -0400, Tom Lane wrote: > I wrote: > > Ahh ... you know what, never mind about stack traces, let's just see if > > the attached patch doesn't fix it. > > On reflection, that patch would only fix the issue for pg_class, and > that's not the only catalog that gets c

Re: [HACKERS] cataloguing NOT NULL constraints

On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote: > > Have you considered just cataloging NOT NULL constraints as CHECK > > constraints and teaching the reverse parser to convert "x CHECK (x IS > > NOT NULL)" to "x NOT NULL". > > Hmm, no, I admit I haven't. The current approach was suggest

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On Thu, 2011-08-04 at 18:07 -0400, Bruce Momjian wrote: > I am confused how generating WAL traffic that is larger than the heap > file we are fsync'ing can possibly be slower. Are you just throwing out > an idea to try to make me prove it? That's worded in a slightly confusing way, but here is th

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai wrote: > BTW, what is the current status of this patch? I think it's waiting for me to get around to reviewing it. Sorry, been busy :-( > The status of contrib/sepgsql part is unclear for me, although we agreed that > syscache is suitable mechani

Re: [HACKERS] Further news on Clang - spurious warnings

Peter Geoghegan writes: > Now, apart from the Flex warning, there are just 3 warnings left. They > all look like this: > repl_gram.y:106:30: warning: implicit conversion from enumeration type > 'enum ReplNodeTag' to different enumeration type 'NodeTag' (aka 'enum > NodeTag') [-Wconversion] > Att

Re: [HACKERS] Further news on Clang - spurious warnings

Now, apart from the Flex warning, there are just 3 warnings left. They all look like this: repl_gram.y:106:30: warning: implicit conversion from enumeration type 'enum ReplNodeTag' to different enumeration type 'NodeTag' (aka 'enum NodeTag') [-Wconversion] (

Re: [HACKERS] [v9.1] sepgsql - userspace access vector cache

BTW, what is the current status of this patch? The status of contrib/sepgsql part is unclear for me, although we agreed that syscache is suitable mechanism for security labels. Thanks, 2011/7/22 Kohei KaiGai : > 2011/7/22 Yeb Havinga : >> On 2011-07-22 11:55, Kohei Kaigai wrote: >>> 2) Also

Re: [HACKERS] Further news on Clang - spurious warnings

On 5 August 2011 17:12, Robert Haas wrote: > On Thu, Aug 4, 2011 at 4:49 PM, Peter Geoghegan wrote: >> Can we please commit a fix for this problem? > > Done. Thanks Robert. -- Peter Geoghegan       http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services -- Sen

Re: [HACKERS] per-column FDW options, v5

On Fri, Jul 29, 2011 at 10:09 AM, Robert Haas wrote: > 2011/7/29 Shigeru Hanada : >> Here is a rebased version of per-column FDW options patch.  I've >> proposed this patch in last CF, but it was marked as returned with >> feedback.  So I would like to propose in next CF 2011-09.  I already >> mov

Re: [HACKERS] Further news on Clang - spurious warnings

On Thu, Aug 4, 2011 at 4:49 PM, Peter Geoghegan wrote: > Can we please commit a fix for this problem? Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] error: could not find pg_class tuple for index 2662

I wrote: > Ahh ... you know what, never mind about stack traces, let's just see if > the attached patch doesn't fix it. On reflection, that patch would only fix the issue for pg_class, and that's not the only catalog that gets consulted during relcache reloads. I think we'd better do it as attache

[HACKERS] GetSnapshotData() comments

I think that the first sentence, in the following comment within GetSnapshotData(), is not quite right, because at the time this is executed, we already hold ProcArrayLock, which is the only lock that gets grabbed here: /* * If we're in recovery then snapshot data comes from a dif

Re: [HACKERS] plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

On 08/04/2011 11:23 PM, Alex Hunsaker wrote: On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan wrote: Let's slow down a bit. Nobody that we know of has encountered the problem Tom's referring to, over all the years plperlu has been available. The changes you're proposing have the potential to dow

Re: [HACKERS] Reduce WAL logging of INSERT SELECT

On Thu, Aug 4, 2011 at 11:07 PM, Bruce Momjian wrote: > Simon Riggs wrote: >> On Thu, Aug 4, 2011 at 10:46 PM, Bruce Momjian wrote: >> >> > Right. ?I brought up SELECT INTO because you could make the argument >> > that INSERT ... SELECT is not a utility command like the other ones and >> > theref

Re: [HACKERS] psql: display of object comments

On Thu, Aug 4, 2011 at 10:24 PM, Josh Kupershmidt wrote: > A few existing backslash commands, such as \dn and maybe \db, don't > exactly follow this precedent. Not sure if we want to bother adjusting > the existing commands to be consistent in this regard. Defining > "typical usage" is pretty wish

Re: [HACKERS] Online base backup from the hot-standby

2011/8/5 Jun Ishiduka : >> I will provide a patch which can exeute pg_start/stop_backup >> including to solve above comment and conditions in next stage. >> Then please review. > > done. great ! > > > * Procedure > > 1. Call pg_start_backup('x') on the standby. > 2. Take a backup of the data dir.