Re: [HACKERS] ask for review of MERGE

2010-09-29 Thread Greg Smith
Starting looking at the latest MERGE patch from Boxuan here tonight. The 
regression tests pass for me here, good starting sign. I expect to move 
onto trying to break it more creatively next, then onto performance 
tests. Nothing much more exciting than that to report so far.


It had suffered some bit rot, I think because of the security label 
changes. Attached is a rebased version against the new git HEAD so 
nobody else has to duplicate that to apply the patch. Also, to provide 
an alternate interface for anyone who wants to do testing/browsing of 
this patch, I've made a Github fork with a merge branch in it. I plan to 
commit intermediate stuff to there that keeps up to date with review 
changes: http://github.com/greg2ndQuadrant/postgres/tree/merge


Probably easier to read 
http://github.com/greg2ndQuadrant/postgres/compare/merge than most local 
patch viewers, so I gzip'ed the attached updated patch to save some bytes.


One compiler warning I noticed that needs to get resolved:

src/backend/commands/explain.c:

explain.c: In function ‘ExplainMergeActions’:
explain.c:1528: warning: comparison of distinct pointer types lacks a cast

That is complaining about this section:

if (mt_planstate-operation != CMD_MERGE ||
mt_planstate-mt_mergeActPstates == NIL)
return;

So presumably that comparison with NIL needs a cast. Once I get more 
familiar with the code I'll fix that myself if Boxuan doesn't offer a 
suggestion first.


The rest of the compiler warnings I saw didn't look related to his code, 
maybe stuff my picky Ubuntu compiler is noticing that was done recently 
to HEAD. I haven't checked HEAD without this patch yet to confirm, and 
am done for the night now. Here's the list if anyone is interested:


Warning in src/backend/parser/scan.c:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-fwrapv -g -I../../../src/include -D_GNU_SOURCE -c -o index.o index.c 
-MMD -MP -MF .deps/index.Po

In file included from gram.y:12172:
scan.c: In function ‘yy_try_NUL_trans’:
scan.c:16256: warning: unused variable ‘yyg’

Warning in src/backend/utils/error/elog.c:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-fwrapv -g -I../../../../src/include -D_GNU_SOURCE -c -o ts_cache.o 
ts_cache.c -MMD -MP -MF .deps/ts_cache.Po

elog.c: In function ‘write_console’:
elog.c:1698: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result

elog.c: In function ‘write_pipe_chunks’:
elog.c:2388: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result
elog.c:2397: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result


Warning in src/bin/scripts/common.c:

gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing 
-fwrapv -g -I. -I. -I../../../src/interfaces/libpq 
-I../../../src/bin/pg_dump -I../../../src/include -D_GNU_SOURCE -c -o 
input.o input.c -MMD -MP -MF .deps/input.Po

common.c: In function ‘handle_sigint’:
common.c:247: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result
common.c:250: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result
common.c:251: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result


--
Greg Smith, 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us
Author, PostgreSQL 9.0 High PerformancePre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book



merge_v203-rebase.patch.gz
Description: GNU Zip compressed data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] libpq changes for synchronous replication

2010-09-29 Thread Fujii Masao
On Tue, Sep 21, 2010 at 1:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
 It doesn't feel right to always accept PQputCopyData in COPY OUT mode,
 though. IMHO there should be a new COPY IN+OUT mode.

 Yeah, I was going to make the same complaint.  Breaking basic
 error-checking functionality in libpq is not very acceptable.

 It should be pretty safe to add a CopyInOutResponse message to the
 protocol without a protocol version bump. Thoughts on that?

 Not if it's something that an existing application might see.  If
 it can only happen in replication mode it's OK.

The attached patch adds a CopyXLogResponse message. The walsender sends
it after processing START_REPLICATION command, instead of CopyOutResponse.
During Copy XLog mode, walreceiver can receive some data from walsender,
and can send some data to walsender.

 Personally I think this demonstrates that piggybacking replication
 data transfer on the COPY protocol was a bad design to start with.
 It's probably time to split them apart.

In the patch, replication data is still transferred on COPY protocol.
If we'd transfer that on dedicated protocol for replication, we would
need to duplicate PQgetCopyData and PQputCopyData and define those
duplicated functions as something like PQgetXLogData and PQputXLogData
for replication.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


libpqrcv_send_v2.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


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Fujii Masao
On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas robertmh...@gmail.com wrote:
 The idea of relying on the existence of recovery.conf to determine
 whether we should continue recovery forever or switch to normal
 running seems somewhat klunky to me.  It mixes up settings with
 control information.  Maybe the control information should move to
 pg_control, and the settings to postgresql.conf.  *waves hands*

You mean to move standby_mode to postgresql.conf, and determine
whether the server should start in standby mode or not by considering
of standby_mode and the status information in pg_control?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Leonardo Francalanci
  10% is nothing.  I was expecting this  patch would give an order of
  magnitude of improvement or somethine like  that in the worst cases of
  the current code (highly unsorted  input)
 
 Yes. It should be x10 faster than ordinary method in the worst  cases.


Here's my post with a (very simple) performance test:

http://archives.postgresql.org/pgsql-hackers/2010-02/msg00766.php


The test I used wasn't a worst case scenario, since it is based on
random data, not wrong-ordered data. Obviously, the real difference
can be seen on large tables (5M+ rows), and/or slow disks.


Leonardo




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] operator dependency of commutator and negator

2010-09-29 Thread Itagaki Takahiro
When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
pg_dump generates an invalid SQL command for the operators depending on
the dropped one. Is it an unavoidable restriction?

  CREATE OPERATOR  (
PROCEDURE = text_lt, LEFTARG = text, RIGHTARG = text, COMMUTATOR = 
  );
  CREATE OPERATOR  (
PROCEDURE = text_gt, LEFTARG = text, RIGHTARG = text, COMMUTATOR = 
  );
  DROP OPERATOR  (text, text);

$ pg_dump
--
-- Name: ; Type: OPERATOR; Schema: public; Owner: postgres
--
CREATE OPERATOR  (
PROCEDURE = text_lt,
LEFTARG = text,
RIGHTARG = text,
COMMUTATOR = 16395  == HERE
);


-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] patch: SQL/MED(FDW) DDL

2010-09-29 Thread Shigeru HANADA
On Tue, 28 Sep 2010 10:26:42 -0400
Robert Haas robertmh...@gmail.com wrote:
 On Mon, Sep 27, 2010 at 2:50 AM, SAKAMOTO Masahiko
 sakamoto.masah...@oss.ntt.co.jp wrote:
  ?http://wiki.postgresql.org/wiki/SQL/MED
 With regard to what is written here, it strikes me that it would be an
 extremely bad idea to try to mix reloptions or attoptions with
 fdwoptions.  fdwoptions are options to be passed transparently to the
 fdw to handle as it likes; rel/attoptions affect the behavior of PG.

In current patch, fdwoptions for relations have been separated from
reloptins by introducing pg_foreign_table catalog.  As mentioned in
wiki, integration into rel/attoptions is nothing but an idea, we're
willing to add pg_foreign_attribute catalog which has columns:

farelid oid not null
faattnumsmallintnot null
faoptions   text[]  not null

Though this catalog has only fdwoptions as non-key value.
Or, adding attrfdwoptions column to pg_attribute catalog is better?

 I think the section about WHERE clause push-down is way off base.
 First, it seems totally wrong to assume that the same functions and
 operators will be defined on the remote side as you have locally;
 indeed, for CSV files, you won't have anything defined on the remote
 side at all.  You need some kind of a discovery mechanism here to
 figure out which quals are push-downable.  And it should probably be
 something generic, not a bunch of hard-wired rules that may or may not
 be correct in any particular case.  What if the remote side is a
 competing database product that doesn't understand X = ANY(Y)?
 Second, even if a functions or operators does exist on both sides of
 the link, how do you know whether they have compatible semantics?
 Short of solving the entscheidungsproblem, you're not going to be able
 to determine that algorithmically, so you need some kind of mechanism
 for controlling what assumptions get made.  Otherwise, you'll end up
 with queries that don't work and no way for the user to fix it.

First of all, WHERE clause push-down ideas written in wiki are just
for FDW for PostgreSQL, implicitly same version, so we have assumed
that the remote side has same syntax/semantics.  WHERE clause
push-down is implemented in postgresql_fdw, and optimizer/planner are
not .

The postgresql_fdw pushes down WHERE clause with following steps.
  * scans all quals in the PlanState and pickup remote-able quals
  * for each remote-able quals,
* adds WHERE clause to remote SQL statement
* remove the qual from PlanState node to avoid duplicate
  evaluation at upper layer ExecScan()

If the foreign data wrapper didn't support WHERE clause push-down,
such as CSV-wrapper, the wrapper can retrieve all tuples from remote
side and pass them to upper layer, and ExecScan() will filter the
tuples based on the quals in the PlanState.

By the way, in current implementation, all operators/functions in
SELECT clause will be evaluated on the local side always, so FDWs
should provide only plain column values.

 It seems to me that the API should allow PG to ask the FDW questions like 
 this:
 
 - How many tuples are there on the remote side?
 - Here is a qual.  Are you able to evaluate this qual remotely?
 - What are the startup and total costs of a sequential scan of the
 remote side with the following set of remotely executable quals?
 - Are there any indices available on the remote side, and if so what
 are there names and which columns do they index in which order
 (asc/desc, nulls first/last)?
 - What are the startup and total costs of an index scan of the remote
 side using the index called $NAME given the following set of remotely
 executable quals?
 
 and, as you mentIon:
 
 - Please update pg_statistic for this foreign table, if you have that
 capability.
 
 Then:
 
 - Begin a sequential scan with the following set of quals.
 - Begin an index scan using the index called X with the following set of 
 quals.
 - Fetch next tuple.
 - End scan.
 
 Maybe that's too much for a first version but if we're not going to
 deal with the problems in a general way, then we ought to not deal
 with them at all, rather than having hacky rules that will work if
 your environment is set up in exactly the way the code expects and
 otherwise break horribly.
Using remote indexes might be very effective, but I think there are
many issues.

For instance, how can planner/optimizer know whether the foreign table
has been indexed or not?  Checking remote catalogs for each scan must
be a bad idea.  HiRDB, Hitachi's dbms product, seems to have
introduced FOREIGN INDEX for that purpose.

I'll consider about cost estimation and path/plan generation again,
and post later.

Regards, Shigeru Hanada
--
Shigeru Hanada


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] is sync rep stalled?

2010-09-29 Thread Fujii Masao
On Wed, Sep 29, 2010 at 11:47 AM, Robert Haas robertmh...@gmail.com wrote:
 So we've got two patches that implement synchronous replication, and
 no agreement on which one, if either, should be committed.  We have no
 agreement on how synchronous replication should be configured, and at
 most a tenuous agreement that it should involve standby registration.

 This is bad.

 This feature is important, and we need to get it done.  How do we get
 the ball rolling again?

ISTM that it still takes long to make consensus on standby registration.
So, how about putting the per-standby parameters in recovery.conf, and
focusing on the basic features in synchronous replication at first?
During that time, we can deepen discussion on standby registration, and
then we can implement that.

The basic features that I mean is for most basic use case, that is, one
master and one synchronous standby case. In detail,

 * Support multiple standbys with various synchronization levels.

Not required for that case.

 * What happens if a synchronous standby isn't connected at the moment? Return 
 immediately vs. wait forever.

The wait-forever option is not required for that case. Let's implement
the return-immediately at first.

 * Per-transaction control. Some transactions are important, others are not.

Not required for that case.

 * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers can 
 be seen as important special cases of this.

Not required for that case.

 * async, recv, fsync and replay levels of synchronization.

At least one of three synchronous levels should be included in the first
commit. I think that either recv or fsync is suitable for first try
because those don't require wake-up signaling from startup process to
walreceiver and are relatively easy to implement.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] string function - format function proposal

2010-09-29 Thread Pavel Stehule
Hello

2010/9/29 Itagaki Takahiro itagaki.takah...@gmail.com:
 On Thu, Sep 9, 2010 at 8:57 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
 I am sending a updated version.

 changes:
 * tag %v removed from format function,
 * proprietary tags %lq a iq removed from sprintf
 * code cleaned

 patch divided to two parts - format function and stringfunc (contains
 sprintf function and substitute function)

 === Discussions about the spec ===
 Two patches add format() into the core, and substitute() and sprintf() into
 stringfunc contrib module. But will we have 3 versions of string formatters?

 IMHO, substitute() is the best choice that we will have in the core because
 functionalities in format() and sprintf() can be achieved by combination of
 substitute() and quote_nullable(), quote_ident(), or to_char(). I think the
 core will provide only simple and non-overlapped features. Users can write
 wrapper functions by themselves if they think the description is redundant.

I think we need a three variants of formating functions - format in
core, fo simply creating and building a messages, a SQL strings,
sprintf for traditionalist in contrib - this functions isn't well
joined to SQL environment and it's too heavy - more it overwrite a
some functionality of to_char function. substitute function
provide just positional unformatted parameters - that isn't typical
ucase - so must not be in core too.


 === format.diff ===
 * It has a reject in doc, but the hunk can be fixed easily.
    1 out of 2 hunks FAILED -- saving rejects to file 
 doc/src/sgml/func.sgml.rej
  COMMENT: We have the function list in alphabetical order,

fixed

  so format() should be inserted after encode().
 * It can be built without compile warnings.
 * Enough documentation and regression tests are included.

 === stringfunc.diff ===
 * It can be applied cleanly and built without compile warnings.
 * Documentation is included, but not enough.
  COMMENT: According to existing docs, function list are described with
  variablelist or table.

fixed

 * Enough regression tests are included.
 * COMMENT: stringfunc directory should be added to contrib/Makefile.

 * BUG: stringfunc_substitute_nv() calls text_format().
  I think we don't need stringfunc_substitute_nv at all.
  It can be replaced by stringfunc_substitute(). _nv version is only
  required if it is in the core because of sanity regression test.

you have a true - but I am not sure about coding patters for contribs,
so I designed it with respect to core sanity check.


 * BUG?: The doc says sprintf() doesn't support length modifiers,
  but it is actually supported in broken state:

I was wrong in documentation - length modifiers are supported -
positional modifiers are not supported. fixed.

 postgres=# SELECT sprintf('%*s', 2, 'ABC');
  sprintf
 -
  ABC      = should be ERROR if unsupported, or AB if supported.
 (1 row)

it works well - with modifier doesn't reduce string. String is
stripped by precision modifiers.

SELECT sprintf('%*.s', 2, ABC) -- AB

checked via gcc

please, try
printf(%s\n, 12345678);
printf(%3s\n, 12345678);
printf(%.3s\n, 12345678);
printf(%10.3s\n, 12345678);

do you understand me, why I dislike printf? How much people knows
well these formatting rules?


 * BUG?: ereport(ERROR,
         (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
          errmsg(unsupported tag \%%%c\, tag)));
  Is the code ok if the tag (a char) is a partial byte of multi-byte character?

it's bug - the supported tags are only single byte, but unsupported
tag can be multibyte character and must by showed correctly - fixed.

  My machine prints ? in the case, but it might be platform-dependent.

 === Both patches ===
 * Performance: I don't think those functions are not performance-critical,
  but we could cache typoutput functions in fn_extra if needed.
  record_out would be a reference.

I though about it too and I checked it now - there is 0.4% performance
on 1000 rows on my PC (format function) - so  I don't do any
changes - caching of oids means a few lines more - but here isn't
expected effect.


 * Coding: Whitespace and tabs are mixed in some places. They are not so
  important because we will run pgindent, but careful choice will be
  preferred even of a patch.


checked, fixed

Thank you very much for review

regards

Pavel Stehule

 --
 Itagaki Takahiro

*** ./doc/src/sgml/func.sgml.orig	2010-09-09 02:48:22.0 +0200
--- ./doc/src/sgml/func.sgml	2010-09-29 07:18:59.845395002 +0200
***
*** 1272,1277 
--- 1272,1280 
  primaryencode/primary
 /indexterm
 indexterm
+ primaryformat/primary
+/indexterm
+indexterm
  primaryinitcap/primary
 /indexterm
 indexterm
***
*** 1495,1500 
--- 1498,1520 
 entryliteralencode(E'123\\000\\001', 'base64')/literal/entry
 entryliteralMTIzAAE=/literal/entry
/row   
+   
+   /row
+entry
+ 

Re: [HACKERS] Stalled post to pgsql-committers

2010-09-29 Thread Magnus Hagander
On Wed, Sep 29, 2010 at 10:08, Peter Eisentraut pete...@gmx.net wrote:
 On sön, 2010-09-26 at 17:11 +0200, Magnus Hagander wrote:
 On Sun, Sep 26, 2010 at 15:39, Heikki Linnakangas
 heikki.linnakan...@enterprisedb.com wrote:
  On 25/09/10 19:43, Peter Eisentraut wrote:
 
  I'm not subscribed to pgsql-committers, but apparently under the new
  git-enabled setup, I'm getting a Stalled post to pgsql-committers
  message for every commit.  Fix that please.
 
  Just subscribe with 'nomail'. That's what I did.

 Yeah, that's what you need to do. I would guess you were previously
 subscribed as pe...@postgresql.org, but the git commit scrpit sends
 the email from pete...@gmx.net, so you need to subscribe from that one
 (with or without nomail).

 No, that address was not subscribed to that list.  There must have been
 some other mechanism at work.

 Btw., I think it would be more proper if the commit notifications
 contained a header like

 Sender: g...@gitmaster.postgresql.org

 so that they don't give a false impression about the origin of the
 message.

We discussed that before, and it was a very clear requirement that
they were sent from the committer, and not from g...@.

And FWIW, majordomo does it's filtering on From and not Sender, so it
wouldn't make a difference just changing Sender, it'd need to change
From. We could probably add a X-something header to it if what
you're looking for is a way to filter them client side?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Standby registration

2010-09-29 Thread Fujii Masao
On Thu, Sep 23, 2010 at 6:49 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
 Automatic registration is a good answer to both your points A)
 monitoring and C) wal_keep_segments, but needs some more thinking wrt
 security and authentication.

Aside from standby registration itself, I have another thought for C). Keeping
many WAL files in pg_xlog of the master is not good design in the first place.
I cannot believe that pg_xlog in most systems has enough capacity to store many
WAL files for the standby.

Usually the place where many WAL files can be stored is the archive. So I've
been thinking to make walsender send the archived WAL file to the standby.
That is, when the WAL file required for the standby is not found in pg_xlog,
walsender restores it from the archive by executing restore_command that users
specified. Then walsender read the WAL file and send it.

Currently, if pg_xlog is not enough large in your system, you have to struggle
with the setup of warm-standby environment on streaming replication, to prevent
the WAL files still required for the standby from being deleted before shipping.
Many people would be disappointed about that fact.

The archived-log-shipping approach cuts out the need of setup of warm-standby
and wal_keep_segments. So that would make streaming replication easier to use.
Thought?

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Using streaming replication as log archiving

2010-09-29 Thread Magnus Hagander
On Wed, Sep 29, 2010 at 05:40, Fujii Masao masao.fu...@gmail.com wrote:
 On Tue, Sep 28, 2010 at 5:23 PM, Magnus Hagander mag...@hagander.net wrote:
 When I ran that, the size of the WAL file in inprogress directory
 became more than 16MB. Obviously something isn't right.

 Wow, that's weird. I'm unable to reproduce that here - can you try to
 figure out why that happened?

 Sorry, I overlooked the single-digit figure in the result of ls -l.

Aha, that explains it.

 To be exact, the size of the WAL file in inprogress directory can be
 less than 16MB. Here is the result of ls -l inprogress.

 $ ls -l inprogress/
 total 1724
 -rw-rw-r-- 1 postgres postgres 1757352 Sep 29 12:03 00010003

 This also would be problem since the WAL file smaller than 16MB cannot
 be used for recovery. I think that pg_streamrecv should create 16MB
 file with zero at first, and write the received WAL records in that, as
 walreceiver does.

It's actually intentional. If we create a file at first, there is no
way to figure out exactly how far through a partial segment we are
without parsing the details of the log. This is useful both for the
admin (who can look at the directory and watch the file grow) and the
tool itself (to know when the .save file can be rotated away, when
recovering from a partial segment receive).

My idea was to just have the admin pad the file when it's time to do
the restore. I could perhaps even add an option to the tool to do it -
the idea being it's a manual step still.

Do you have another suggestion for how to provide those two things?

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Stalled post to pgsql-committers

2010-09-29 Thread Peter Eisentraut
On ons, 2010-09-29 at 10:19 +0200, Magnus Hagander wrote:
  Btw., I think it would be more proper if the commit notifications
  contained a header like
 
  Sender: g...@gitmaster.postgresql.org
 
  so that they don't give a false impression about the origin of the
  message.
 
 We discussed that before, and it was a very clear requirement that
 they were sent from the committer, and not from g...@.

This not really a matter of taste or policy, it's about RFC 822
correctness and not impostering people.  You would of course keep the
From header.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-29 Thread Peter Eisentraut
On ons, 2010-09-15 at 12:58 -0500, Kevin Grittner wrote:
 I just discovered the --patience flag on the git diff command, and
 I'd like to suggest that we encourage people to use it when possible
 for building patches.  I just looked at output with and without it
 (and for good measure, before and after filterdiff --format=context
 for both), and the results were much better with this switch.

I have tried this switch various times now and haven't seen any
difference at all in the output.  Do you have an existing commit where
you see a difference so I can try it and see if there is some other
problem that my local configuration has?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread KaiGai Kohei

Thanks for your reviewing, and sorry for delayed responding due to
the LinuxCon Japan for a couple of days.

(2010/09/28 12:57), Robert Haas wrote:

2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:

This patch allows external security providers to check privileges
to create a new relation and to inform the security labels to be
assigned on the new one.


Review:

I took a brief look at this patch tonight and I think it's on the
wrong track.  There's no reason for the hook function to return the
list of security labels and then have the core code turn around and
apply them to the object.  If the hook function wants to label the
object, it can just as easily call SetSecurityLabel() itself.


However, it is not actually easy, because we cannot know OID of
the new table before invocation of heap_create_with_catalog().
So, we needed to return a list of security labels to caller of
the hook, then the core core calls SetSecurityLabel() with newly
assigned OID.

I don't think it is an option to move the hook after the pollution
of system catalogs, although we can pull out any information about
the new relation from syscache.


It seems to me that there is a general pattern to the hooks that are
needed here.  For each object type for which we wish to have MAC
integration, you need the ability to get control when the object is
created and again when the object is dropped.  You might want to deny
the operation, apply labels to the newly created object, do some
logging, or whatever.  So it strikes me that you could have a hook
function with a signature like this:

typedef void (*object_access_hook_type)(ObjectType objtype, Oid oid,
int subid, ObjectAccessType op);

...where ObjectAccessType is an enum.

Then you could do something like this:

#define InvokeObjectAccessHook(objtype, oid, subid, op) \
 if (object_access_hook != NULL) \
 object_access_hook(objtype, oid, subid, op);

Then you can sprinkle calls to that macro in strategically chosen
places to trap create, drop, comment, security label, ... whatever the
object gets manipulated in a way that something like SE-Linux is apt
to care about.  So ObjectAccessType can have values like OAT_CREATE,
OAT_DROP, OAT_COMMENT, OAT_SECURITY_LABEL, ...


Sorry, it seems to me the idea simplifies the issue too much to implement
access control features correctly.
For example, we need to provide security modules the supplied label on
the SECURITY LABEL hook, so it has to take one more argument at least.
For example, we will need to provide them OID of the new schema on
the ALTER TABLE SET SCHEMA at least too.
  :

So, we need to inform the security modules some more extra information
rather than OID of the objects to be referenced.


I would like to mark this patch Returned with Feedback, because I
think the above suggestions are going to amount to a complete rewrite.


It is too early.

Please consider again the reason why we needed to return a list of
security labels to be assigned on the new relation

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Git downed?

2010-09-29 Thread KaiGai Kohei
Does the git.postgresql.org down?

Harada-san being also unreachable now.
-- 
KaiGai Kohei kai...@kaigai.gr.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Git downed?

2010-09-29 Thread Peter Geoghegan
It looks that way to me too.

.Oh wait, it works now.

-- 
Regards,
Peter Geoghegan

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Git downed?

2010-09-29 Thread Dave Page
2010/9/29 KaiGai Kohei kai...@kaigai.gr.jp:
 Does the git.postgresql.org down?

 Harada-san being also unreachable now.

Seems to be a network issue. It's fine for some people (like me), and
down for others.

Thom reports that it's now back for him.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Git downed?

2010-09-29 Thread KaiGai Kohei

(2010/09/29 20:53), Dave Page wrote:

2010/9/29 KaiGai Koheikai...@kaigai.gr.jp:

Does the git.postgresql.org down?

Harada-san being also unreachable now.


Seems to be a network issue. It's fine for some people (like me), and
down for others.

Thom reports that it's now back for him.


Now I'm reachable to the git.postgreql.org.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Alvaro Herrera
Excerpts from Leonardo Francalanci's message of mié sep 29 03:17:07 -0400 2010:

 Here's my post with a (very simple) performance test:
 
 http://archives.postgresql.org/pgsql-hackers/2010-02/msg00766.php

I think the 10M rows test is more in line with what we want (83s vs. 646).

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] patch: SQL/MED(FDW) DDL

2010-09-29 Thread Shigeru HANADA
On Tue, 28 Sep 2010 22:14:22 +0300
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
 On 09/28/10 17:26, Robert Haas wrote:
  First, it seems totally wrong to assume that the same functions and
  operators will be defined on the remote side as you have locally;
  indeed, for CSV files, you won't have anything defined on the remote
  side at all.  You need some kind of a discovery mechanism here to
  figure out which quals are push-downable.  And it should probably be
  something generic, not a bunch of hard-wired rules that may or may not
  be correct in any particular case.  What if the remote side is a
  competing database product that doesn't understand X = ANY(Y)?
  Second, even if a functions or operators does exist on both sides of
  the link, how do you know whether they have compatible semantics?
 
 Or side-effects.
 
 The SQL/MED specification has routine mappings for this purpose. We 
 will need that or something similar.

Yes, I see the problem.

To resolve function-mismatch issues, we need routine mapping mechanism. 
With that, FDW can translate function calls into remote expressions
along rules which are defined by user.

SQL/MED standard requires a routine mapping to map a pair of local
routine and server to a set of generic options.  An local routine
is identified by type, name and parameters.

The type is one of ROUTINE/FUNCTION/PROCEDURE/METHOD.  I think
supporting only FUNCTION is enough because PostgreSQL doesn't have
ROUTINE/PROCEDURE/METHOD.

I think that the pg_routine_mapping catalog should have
columns/indexes:

rmname  namenot null
rmprocidoid not null
rmserverid  oid not null
rmoptions   text[]

pg_routine_mapping_oid_index UNIQUE, btree(oid)
pg_routine_mapping_name_index UNIQUE, btree(rmname)
pg_routine_mapping_proc_server_index UNIQUE, btree(rmprocid, rmserverid)

To use a remote function which PostgreSQL doesn't have in foreign
query, we need a local dummy function which is mapped to remote
function.  The local function may be empty but should have appropriate
parameters.

Supported features:
  * Create routine mapping (USAGE on the server required)
  * Alter routine mappging's generic options (must be owner of the
routine mappping)
  * Drop routine mapping (must be owner of the routine mapping)
  * Query routine mapping informations via information_schema views
routine_mappings and routine_mapping_options (no restriction)

FDWs can define any specification of generic options.
Maybe FDW for PostgreSQL needs no entry if no special functions was
defined.  Routine mappings can be used to absorb the difference of the
versions. 

Any comments are welcome.

Regards,

--
Shigeru Hanada


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Alvaro Herrera
Excerpts from Itagaki Takahiro's message of mié sep 29 01:25:38 -0400 2010:

 To be exact, It's very complex.
 During reconstructing tables, it requires about twice disk space of
 the old table (for sort tapes and the new table).
 After sorting the table, CLUSTER performs REINDEX. We need
 {same size of the new table} + {twice disk space of the new indexes}.
 Also, new relations will be the same sizes of old relations if they
 have no free spaces.

Aren't the old table and indexes kept until transaction commit, though?
So during the reindex you still keep the old copy of the table and
indexes around, thus double space.  The only space difference would be
extra free space in the old table, tuples older than OldestXmin, and
fillfactor changes.

 So, I think twice disk space of the sum of table and indexes would be
 the simplest explanation for safe margin.

Agreed.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
 I don't think it is an option to move the hook after the pollution
 of system catalogs, although we can pull out any information about
 the new relation from syscache.

Why not?

 Sorry, it seems to me the idea simplifies the issue too much to implement
 access control features correctly.
 For example, we need to provide security modules the supplied label on
 the SECURITY LABEL hook, so it has to take one more argument at least.
 For example, we will need to provide them OID of the new schema on
 the ALTER TABLE SET SCHEMA at least too.
  :

So what?  The patch you submitted doesn't provide the OID of the new
schema when someone does ALTER TABLE SET SCHEMA, either.  I proposed a
design which was much more general than what you submitted, and you're
now complaining that it's not general enough.  It's unrealistic to
think you're going to solve every problem with one patch.  Moreover,
it's far from obvious that you actually do need the details that
you're proposing anyway.  Are you really going to write an SE-Linux
policy that allows people to change the schema of table A to schema B
but not schema C?  Or that allows a hypothetical smack plugin to label
a given object with one label but not another?  And if so, are those
absolutely must-have features for the first version or are those
things that would be nice to have in version 3 or 4?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 3:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas robertmh...@gmail.com wrote:
 The idea of relying on the existence of recovery.conf to determine
 whether we should continue recovery forever or switch to normal
 running seems somewhat klunky to me.  It mixes up settings with
 control information.  Maybe the control information should move to
 pg_control, and the settings to postgresql.conf.  *waves hands*

 You mean to move standby_mode to postgresql.conf, and determine
 whether the server should start in standby mode or not by considering
 of standby_mode and the status information in pg_control?

I can't parse that.  I guess I'm wondering whether standby_mode itself
should move into pg_control.  Otherwise, you need a GUC somewhere that
says whether or not you should even try standby_mode plus a trigger
file that can override the GUC.  It seems like there's one bit of
information that's being spread out across multiple places.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ask for review of MERGE

2010-09-29 Thread Josh Kupershmidt
On Wed, Sep 29, 2010 at 2:44 AM, Greg Smith g...@2ndquadrant.com wrote:

 The rest of the compiler warnings I saw didn't look related to his code,
 maybe stuff my picky Ubuntu compiler is noticing that was done recently to
 HEAD. I haven't checked HEAD without this patch yet to confirm, and am done
 for the night now. Here's the list if anyone is interested:

 Warning in src/backend/parser/scan.c:

 gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
 -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -g
 -I../../../src/include -D_GNU_SOURCE -c -o index.o index.c -MMD -MP -MF
 .deps/index.Po
 In file included from gram.y:12172:
 scan.c: In function ‘yy_try_NUL_trans’:
 scan.c:16256: warning: unused variable ‘yyg’

Known problem: http://archives.postgresql.org/pgsql-hackers/2009-07/msg00657.php

I'm pretty sure I've seen the warn_unused_result warnings on HEAD as well.

Josh

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 1:12 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
 On Wed, Sep 29, 2010 at 1:27 PM, Alvaro Herrera
 alvhe...@commandprompt.com wrote:
 I see a consistent
 ~10% advantage for the sequential scan clusters.

 10% is nothing.  I was expecting this patch would give an order of
 magnitude of improvement or somethine like that in the worst cases of
 the current code (highly unsorted input)

 Yes. It should be x10 faster than ordinary method in the worst cases.

 I have a performance result of pg_reorg, that performs as same as
 the patch. It shows 16 times faster than the old CLUSTER. In addition,
 it was slow if not fragmented. (So, it should not be consistent.)
 http://reorg.projects.postgresql.org/

Can you reproduce that with this patch?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ask for review of MERGE

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 2:44 AM, Greg Smith g...@2ndquadrant.com wrote:
 One compiler warning I noticed that needs to get resolved:

 src/backend/commands/explain.c:

 explain.c: In function ‘ExplainMergeActions’:
 explain.c:1528: warning: comparison of distinct pointer types lacks a cast

 That is complaining about this section:

 if (mt_planstate-operation != CMD_MERGE ||
 mt_planstate-mt_mergeActPstates == NIL)
 return;

 So presumably that comparison with NIL needs a cast. Once I get more
 familiar with the code I'll fix that myself if Boxuan doesn't offer a
 suggestion first.

Possibly NULL was meant instead of NIL.  NIL is specifically for a List.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ask for review of MERGE

2010-09-29 Thread Boxuan Zhai
On Wed, Sep 29, 2010 at 9:16 PM, Robert Haas robertmh...@gmail.com wrote:

 On Wed, Sep 29, 2010 at 2:44 AM, Greg Smith g...@2ndquadrant.com wrote:
  One compiler warning I noticed that needs to get resolved:
 
  src/backend/commands/explain.c:
 
  explain.c: In function ‘ExplainMergeActions’:
  explain.c:1528: warning: comparison of distinct pointer types lacks a
 cast
 
  That is complaining about this section:
 
  if (mt_planstate-operation != CMD_MERGE ||
  mt_planstate-mt_mergeActPstates == NIL)
  return;
 
  So presumably that comparison with NIL needs a cast. Once I get more
  familiar with the code I'll fix that myself if Boxuan doesn't offer a
  suggestion first.

 Possibly NULL was meant instead of NIL.  NIL is specifically for a List.


Yes, it should be NULL instead of NIL.

At first, I designed this filed as a List. But I changed it into an array in
the last editions. This is why I have an unmatched assignment here. Sorry
for that.


 --
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise Postgres Company



Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

2010-09-29 Thread Magnus Hagander
On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
 On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 It's hard to say what the safest option is, I think.  There seem to be
 basically three proposals on the table:

 1. Back-port the dead-man switch, and ignore exit 128.
 2. Don't back-port the dead-man switch, but ignore exit 128 anyway.
 3. Revert to Magnus's original solution.

 Each of these has advantages and disadvantages.  The advantage of #1
 is that it is safer than #2, and that is usually something we prize
 fairly highly.  The disadvantage of #1 is that it involves
 back-porting the dead-man switch, but on the flip side that code has
 been out in the field for over a year now in 8.4, and AFAIK we haven't
 any trouble with it.  Solution #3 should be approximately as safe as
 solution #1, and has the advantage of touching less code in the back
 branches, but on the other hand it is also NEW code.  So I think it's
 arguable which is the best solution.  I think I like option #2 least
 as among those choices, but it's a tough call.

 Well, I don't want to use Magnus' original solution in 8.4 or up,
 so I don't like #3 much: it's not only new code but code which would
 get very limited testing.  And I don't believe that the risk of
 unexpected use of exit(128) is large enough to make #1 preferable to #2.
 YMMV.

 So, can we go with #2 for the next point releases of = 8.3? I
 understand that our customer who has been testing that approach hasn't
 seen any unexpected side-effects.

Do we feel this is safe enough?

Also, just to be clear - they tested the ignore 128 only patch? Or
did they test the patch that also had some global events implementing
a win32-only deadman switch?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

2010-09-29 Thread Magnus Hagander
On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
 On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 It's hard to say what the safest option is, I think.  There seem to be
 basically three proposals on the table:

 1. Back-port the dead-man switch, and ignore exit 128.
 2. Don't back-port the dead-man switch, but ignore exit 128 anyway.
 3. Revert to Magnus's original solution.

 Each of these has advantages and disadvantages.  The advantage of #1
 is that it is safer than #2, and that is usually something we prize
 fairly highly.  The disadvantage of #1 is that it involves
 back-porting the dead-man switch, but on the flip side that code has
 been out in the field for over a year now in 8.4, and AFAIK we haven't
 any trouble with it.  Solution #3 should be approximately as safe as
 solution #1, and has the advantage of touching less code in the back
 branches, but on the other hand it is also NEW code.  So I think it's
 arguable which is the best solution.  I think I like option #2 least
 as among those choices, but it's a tough call.

 Well, I don't want to use Magnus' original solution in 8.4 or up,
 so I don't like #3 much: it's not only new code but code which would
 get very limited testing.  And I don't believe that the risk of
 unexpected use of exit(128) is large enough to make #1 preferable to #2.
 YMMV.

 So, can we go with #2 for the next point releases of = 8.3? I
 understand that our customer who has been testing that approach hasn't
 seen any unexpected side-effects.

Do we feel this is safe enough?

Also, just to be clear - they tested the ignore 128 only patch? Or
did they test the patch that also had some global events implementing
a win32-only deadman switch?


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

2010-09-29 Thread Dave Page
On Wed, Sep 29, 2010 at 2:45 PM, Magnus Hagander mag...@hagander.net wrote:
 On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
 On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 It's hard to say what the safest option is, I think.  There seem to be
 basically three proposals on the table:

 1. Back-port the dead-man switch, and ignore exit 128.
 2. Don't back-port the dead-man switch, but ignore exit 128 anyway.
 3. Revert to Magnus's original solution.

 Each of these has advantages and disadvantages.  The advantage of #1
 is that it is safer than #2, and that is usually something we prize
 fairly highly.  The disadvantage of #1 is that it involves
 back-porting the dead-man switch, but on the flip side that code has
 been out in the field for over a year now in 8.4, and AFAIK we haven't
 any trouble with it.  Solution #3 should be approximately as safe as
 solution #1, and has the advantage of touching less code in the back
 branches, but on the other hand it is also NEW code.  So I think it's
 arguable which is the best solution.  I think I like option #2 least
 as among those choices, but it's a tough call.

 Well, I don't want to use Magnus' original solution in 8.4 or up,
 so I don't like #3 much: it's not only new code but code which would
 get very limited testing.  And I don't believe that the risk of
 unexpected use of exit(128) is large enough to make #1 preferable to #2.
 YMMV.

 So, can we go with #2 for the next point releases of = 8.3? I
 understand that our customer who has been testing that approach hasn't
 seen any unexpected side-effects.

 Do we feel this is safe enough?

I've yet to hear of a way a process can exit with a 128 that seems
like it could happen in our code.

 Also, just to be clear - they tested the ignore 128 only patch?

Yes.


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread Alvaro Herrera
Excerpts from KaiGai Kohei's message of mié sep 29 06:38:09 -0400 2010:

 (2010/09/28 12:57), Robert Haas wrote:
  2010/9/1 KaiGai Koheikai...@ak.jp.nec.com:
  This patch allows external security providers to check privileges
  to create a new relation and to inform the security labels to be
  assigned on the new one.
 
  Review:
 
  I took a brief look at this patch tonight and I think it's on the
  wrong track.  There's no reason for the hook function to return the
  list of security labels and then have the core code turn around and
  apply them to the object.  If the hook function wants to label the
  object, it can just as easily call SetSecurityLabel() itself.
 
 However, it is not actually easy, because we cannot know OID of
 the new table before invocation of heap_create_with_catalog().
 So, we needed to return a list of security labels to caller of
 the hook, then the core core calls SetSecurityLabel() with newly
 assigned OID.
 
 I don't think it is an option to move the hook after the pollution
 of system catalogs, although we can pull out any information about
 the new relation from syscache.

Why not?  The relation is not yet visible to other transactions until
the creation is committed, so you can apply security labels after
populating the catalogs and there's no security leak.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread KaiGai Kohei

(2010/09/29 22:00), Robert Haas wrote:

On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheikai...@kaigai.gr.jp  wrote:

I don't think it is an option to move the hook after the pollution
of system catalogs, although we can pull out any information about
the new relation from syscache.


Why not?


All the existing security checks applies before modifying system catalogs.

At least, I cannot find out any constructive reason why we try to apply
permission checks on object creation time with different manner towards
the existing privilege mechanism...


Sorry, it seems to me the idea simplifies the issue too much to implement
access control features correctly.
For example, we need to provide security modules the supplied label on
the SECURITY LABEL hook, so it has to take one more argument at least.
For example, we will need to provide them OID of the new schema on
the ALTER TABLE SET SCHEMA at least too.
  :


So what?  The patch you submitted doesn't provide the OID of the new
schema when someone does ALTER TABLE SET SCHEMA, either.  I proposed a
design which was much more general than what you submitted, and you're
now complaining that it's not general enough.  It's unrealistic to
think you're going to solve every problem with one patch.


Sorry, I never said one patch with enough generic hook solves everything.

By contraries, I think the proposed prototype of the hook cannot inform
the plugins anything except for OID and event type, even if necessary.
Some of permission checks needs its specific prototype to inform extra
information rather than OIDs; such as new label in SECURITY LABEL hook,
new schema in upcoming ALTER TABLE SET SCHEMA, and so on...

Of course, we can implement some of permission checks with OID of the
target object and event type collectly. E,g. I cannot image any extra
information to check permission on COMMENT. I never deny it.


Moreover,
it's far from obvious that you actually do need the details that
you're proposing anyway.  Are you really going to write an SE-Linux
policy that allows people to change the schema of table A to schema B
but not schema C?  Or that allows a hypothetical smack plugin to label
a given object with one label but not another?  And if so, are those
absolutely must-have features for the first version or are those
things that would be nice to have in version 3 or 4?



In your proposition, prototype of the security hook has four arguments:
ObjectType, oid, subid and ObjectAccessType, doesn't it?

When user tries to change the schema of table from A to B, we can know
the current schema of the table using syscache, but we need to inform
the plugin that B is the new schema, because we have no way to pull out
what schema was provided by the user.

As LookupCreationNamespace() checks CREATE permission on the new schema,
SELinux also want to check permission on the new schema, not only old one.
So, I concerned about the prototype does not inform about new schema that
user provided using ALTER TABLE SET SCHEMA statement.

Thanks,
--
KaiGai Kohei kai...@kaigai.gr.jp

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Tom Lane
Fujii Masao masao.fu...@gmail.com writes:
 On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas robertmh...@gmail.com wrote:
 The idea of relying on the existence of recovery.conf to determine
 whether we should continue recovery forever or switch to normal
 running seems somewhat klunky to me.  It mixes up settings with
 control information.  Maybe the control information should move to
 pg_control, and the settings to postgresql.conf.  *waves hands*

 You mean to move standby_mode to postgresql.conf, and determine
 whether the server should start in standby mode or not by considering
 of standby_mode and the status information in pg_control?

I think keeping the status information in a transient text file may
still be a good design choice.  If you push it into pg_control it will
be impossible to modify by hand.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] patch: SQL/MED(FDW) DDL

2010-09-29 Thread Alvaro Herrera
Excerpts from Robert Haas's message of mar sep 28 10:26:54 -0400 2010:

 Then:
 
 - Begin a sequential scan with the following set of quals.
 - Begin an index scan using the index called X with the following set of 
 quals.
 - Fetch next tuple.
 - End scan.

I'm not sure that it's a good idea to embed into the FDW API the set of
operations known to the executor.  For example your proposal fails to
consider bitmap scans.  Seems simpler and more general to hand the quals
over saying I need to scan this relation with these quals, and have it
return an opaque iterable object; the remote executor would be in charge
of determining their usage for indexscans; or even for filtering tuples
with quals that cannot be part of the index condition.

There doesn't to be much point in knowing the names of remote indexes
either (if it came to referencing them, better use OIDs)

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-29 Thread Kevin Grittner
Peter Eisentraut pete...@gmx.net wrote:
 
 I have tried this switch various times now and haven't seen any
 difference at all in the output.  Do you have an existing commit
 where you see a difference so I can try it and see if there is
 some other problem that my local configuration has?
 
Having looked at it more, I find that the output with the switch is
usually the same as without; but when they differ, I always have
preferred the version with it on.  Attached is the diff which caused
me to see if there was a way to make the diff output smarter, and
the result of adding the --patience flag.
 
This is the unified form that git puts out by default, but the
benefit is there after filterdiff --format=context, too.
 
-Kevin
 



patience-off.diff
Description: Binary data


patience-on.diff
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


Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Itagaki Takahiro
On Wed, Sep 29, 2010 at 10:14 PM, Robert Haas robertmh...@gmail.com wrote:
 http://reorg.projects.postgresql.org/

 Can you reproduce that with this patch?

No, I can't use the machine anymore.

-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] operator dependency of commutator and negator

2010-09-29 Thread Alvaro Herrera
Excerpts from Itagaki Takahiro's message of mié sep 29 03:56:33 -0400 2010:
 When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
 pg_dump generates an invalid SQL command for the operators depending on
 the dropped one. Is it an unavoidable restriction?

Maybe we need a pg_depend entry from each pg_operator entry to the other
one.  The problem is that this creates a cycle in the depends graph; not
sure how well these are handled in the code, if at all.

-- 
Álvaro Herrera alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] documentation udpates to pgupgrade.html

2010-09-29 Thread Colin 't Hart
Bruce,

To query for Postgresql services on Windows use:

sc query type= service | find postgresql


On my machine this yields:

SERVICE_NAME: postgresql-9.0
DISPLAY_NAME: postgresql-9.0 - PostgreSQL Server 9.0


NB the space after type= is very important, don't ask me why...



I prefer to use 'sc start servicename' and 'sc stop servicename',
then you can use one tool for everything.

The following shows these commands (and the query command) in action.


C:\Documents and Settings\Administratorsc stop postgresql-9.0

SERVICE_NAME: postgresql-9.0
TYPE   : 10  WIN32_OWN_PROCESS
STATE  : 3  STOP_PENDING
(STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE: 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT : 0x2
WAIT_HINT  : 0x2710

C:\Documents and Settings\Administratorsc start postgresql-9.0

SERVICE_NAME: postgresql-9.0
TYPE   : 10  WIN32_OWN_PROCESS
STATE  : 2  START_PENDING
(NOT_STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN))

WIN32_EXIT_CODE: 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT : 0x0
WAIT_HINT  : 0x7d0
PID: 3732
FLAGS  :

C:\Documents and Settings\Administratorsc query postgresql-9.0

SERVICE_NAME: postgresql-9.0
TYPE   : 10  WIN32_OWN_PROCESS
STATE  : 4  RUNNING
(STOPPABLE, PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE: 0  (0x0)
SERVICE_EXIT_CODE  : 0  (0x0)
CHECKPOINT : 0x0
WAIT_HINT  : 0x0



Hope this isn't too much info and answers all your questions :-)


Regards,

Colin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Unable to generate man pages for translated sgml

2010-09-29 Thread Tatsuo Ishii
Hi,

Starting from 9.0, it seems unable to generate man pages for Japanese
translated sgml(generating html is ok). Until 8.4 it worked fine. Does
anybody succeeded in generating non English/multibyte translated man pages?
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] [BUGS] BUG #5305: Postgres service stops when closing Windows session

2010-09-29 Thread Magnus Hagander
On Wed, Sep 29, 2010 at 15:54, Dave Page dp...@pgadmin.org wrote:
 On Wed, Sep 29, 2010 at 2:45 PM, Magnus Hagander mag...@hagander.net wrote:
 On Mon, Sep 27, 2010 at 14:34, Dave Page dp...@pgadmin.org wrote:
 On Thu, Sep 9, 2010 at 9:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 It's hard to say what the safest option is, I think.  There seem to be
 basically three proposals on the table:

 1. Back-port the dead-man switch, and ignore exit 128.
 2. Don't back-port the dead-man switch, but ignore exit 128 anyway.
 3. Revert to Magnus's original solution.

 Each of these has advantages and disadvantages.  The advantage of #1
 is that it is safer than #2, and that is usually something we prize
 fairly highly.  The disadvantage of #1 is that it involves
 back-porting the dead-man switch, but on the flip side that code has
 been out in the field for over a year now in 8.4, and AFAIK we haven't
 any trouble with it.  Solution #3 should be approximately as safe as
 solution #1, and has the advantage of touching less code in the back
 branches, but on the other hand it is also NEW code.  So I think it's
 arguable which is the best solution.  I think I like option #2 least
 as among those choices, but it's a tough call.

 Well, I don't want to use Magnus' original solution in 8.4 or up,
 so I don't like #3 much: it's not only new code but code which would
 get very limited testing.  And I don't believe that the risk of
 unexpected use of exit(128) is large enough to make #1 preferable to #2.
 YMMV.

 So, can we go with #2 for the next point releases of = 8.3? I
 understand that our customer who has been testing that approach hasn't
 seen any unexpected side-effects.

 Do we feel this is safe enough?

 I've yet to hear of a way a process can exit with a 128 that seems
 like it could happen in our code.

 Also, just to be clear - they tested the ignore 128 only patch?

 Yes.

Ok, applied. Please verify that it matches your expectations :D

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Stalled post to pgsql-committers

2010-09-29 Thread Peter Eisentraut
On sön, 2010-09-26 at 17:11 +0200, Magnus Hagander wrote:
 On Sun, Sep 26, 2010 at 15:39, Heikki Linnakangas
 heikki.linnakan...@enterprisedb.com wrote:
  On 25/09/10 19:43, Peter Eisentraut wrote:
 
  I'm not subscribed to pgsql-committers, but apparently under the new
  git-enabled setup, I'm getting a Stalled post to pgsql-committers
  message for every commit.  Fix that please.
 
  Just subscribe with 'nomail'. That's what I did.
 
 Yeah, that's what you need to do. I would guess you were previously
 subscribed as pe...@postgresql.org, but the git commit scrpit sends
 the email from pete...@gmx.net, so you need to subscribe from that one
 (with or without nomail).

No, that address was not subscribed to that list.  There must have been
some other mechanism at work.

Btw., I think it would be more proper if the commit notifications
contained a header like

Sender: g...@gitmaster.postgresql.org

so that they don't give a false impression about the origin of the
message.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] operator dependency of commutator and negator

2010-09-29 Thread Tom Lane
Alvaro Herrera alvhe...@commandprompt.com writes:
 Excerpts from Itagaki Takahiro's message of mié sep 29 03:56:33 -0400 2010:
 When we drop an operator used by other operators as COMMUTATOR or NEGATOR,
 pg_dump generates an invalid SQL command for the operators depending on
 the dropped one. Is it an unavoidable restriction?

 Maybe we need a pg_depend entry from each pg_operator entry to the other
 one.  The problem is that this creates a cycle in the depends graph; not
 sure how well these are handled in the code, if at all.

See the comment in catalog/pg_operator.c:

/*
 * NOTE: we do not consider the operator to depend on the associated
 * operators oprcom and oprnegate. We would not want to delete this
 * operator if those go away, but only reset the link fields; which is not
 * a function that the dependency code can presently handle.  (Something
 * could perhaps be done with objectSubId though.)  For now, it's okay to
 * let those links dangle if a referenced operator is removed.
 */

I'm not sure that fixing this case is worth the amount of work it'd
take.  How often do you drop just one member of a commutator pair?

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Path question

2010-09-29 Thread Robert Haas
On Tue, Sep 28, 2010 at 11:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 Robert Haas robertmh...@gmail.com writes:
 ...what makes the pathkeys potentially useful is that they match the
 root pathkeys for the query.  However, without Greg's hacks, the
 transposed child equivalence classes don't show up in the equivalence
 member lists, so get_eclass_for_sort_expr() generates new equivalence
 classes for them.  Subsequently, when truncate_useless_pathkeys() is
 called, those new equivalence classes are found not to be equal to the
 overall ordering desired for the query, so it truncates them away.

 I'm not presently sure quite what the best way to fix this is... any ideas?

 Probably what's needed is to extend the child eclass member stuff to
 cover sort-key eclasses.  Per relation.h:

  * em_is_child signifies that this element was built by transposing a member
  * for an inheritance parent relation to represent the corresponding 
 expression
  * on an inheritance child.  The element should be ignored for all purposes
  * except constructing inner-indexscan paths for the child relation.

 Likely these need to be ignored a bit less.  A couple of Greg's
 undocumented hacks seem to be related to this point, but not all of
 them.  In any case you'd need some careful thought about when to
 ignore child EMs and when not.

Makes sense to me.  It seems that there are actually two halves to
this problem: getting the child EMs to be generated in the first
place, and then getting them to be examined at the appropriate time.

The FIXME in set_append_rel_pathlist() is there to ensure that
add_child_rel_equivalences() always gets called, and the hack in
add_child_rel_equivalences() is there to ensure that child EMs are
generated unconditionally rather than only when they're useful for
merging.  That doesn't seem entirely off-base.  In
set_append_rel_pathlist(), I think that we shouldn't set
has_eclass_joins on the child relation unless it's set on the parent,
but calling add_child_rel_equivalences() unconditionally might be
reasonable.  Similarly, in add_child_rel_equivalences(), I think that
the cur_ec-ec_has_const test should be retained, but the test on
list_length(cur_ec-ec_members) needs to be relaxed or eliminated.  As
a matter of correctness, it seems like it should be OK to do this
always - the worst thing that can happen is you end up with some extra
EMs that don't (or shouldn't) do anything.  However, it's possible
that, for performance, we might want to avoid generating EMs that
won't actually be needed.  I'm not entirely clear on whether there is
an inexpensive way for us to know that.  Perhaps we could replace the
list_length() test with a call to has_useful_pathkeys() and just
accept that there will be some false positives.

The two FIXMEs in make_sort_from_pathkeys() are there to ensure that
we find the child EMs when we go to generate a sort.  There's no
reason that I can see to remove the em_has_const test, but it looks
like we need to remove the em_is_child test.  We need to match each
pathkey to an element of the child's target list, which means we must
consider an EM that appears in the child's target list, which is means
a child EM or nothing.  Testing reveals that if you keep Greg's hacks
to add the child EMs but remove the hacks from
make_sort_from_pathkeys(), it still works IF every child can use an
index scan, but if you need to do an index scan on some children and
sort others then you get:

ERROR:  could not find pathkey item to sort

...which seems consistent with the above analysis.  If we accept that
it's necessary, that still leaves the question of whether it's safe.
I'm a little less certain on this point, but it seems like it ought to
be OK.  As far as I'm aware, we currently never sort append children.
Indeed, unless equivalence classes for those append children were
getting created by some mechanism other than
add_child_rel_equivalences(), it seems like it ought to fail with the
above error messages.  And on the flip side it should be impossible
for us to pick up a child EM when we meant to get some other one
because they shouldn't be equal().

Thoughts?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Fujii Masao masao.fu...@gmail.com writes:
 On Tue, Sep 28, 2010 at 10:34 PM, Robert Haas robertmh...@gmail.com wrote:
 The idea of relying on the existence of recovery.conf to determine
 whether we should continue recovery forever or switch to normal
 running seems somewhat klunky to me.  It mixes up settings with
 control information.  Maybe the control information should move to
 pg_control, and the settings to postgresql.conf.  *waves hands*

 You mean to move standby_mode to postgresql.conf, and determine
 whether the server should start in standby mode or not by considering
 of standby_mode and the status information in pg_control?

 I think keeping the status information in a transient text file may
 still be a good design choice.  If you push it into pg_control it will
 be impossible to modify by hand.

It could be done with a trivial tool, though.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] operator dependency of commutator and negator

2010-09-29 Thread Itagaki Takahiro
On Wed, Sep 29, 2010 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 I'm not sure that fixing this case is worth the amount of work it'd
 take.  How often do you drop just one member of a commutator pair?

I found the issue when an user tries to write a safe installer
script under DROP before CREATE coding rule:

 1. DROP OPERATOR IF EXISTS  ... ;
 2. CREATE OPERATOR  (... COMMUTATOR );
 3. DROP OPERATOR IF EXISTS  ... ;
 4. CREATE OPERATOR  (... COMMUTATOR );

3 drops catalog-only  added at 2, and 4 adds a operator that
has a different oid from 's commutator. The operator 
becomes broken state in system catalog.

Anyway, it must be a rare case, and we can just avoid the usage.

-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-29 Thread Kevin Grittner
Peter Eisentraut pete...@gmx.net wrote:
 
 Do you have an existing commit where you see a difference so I can
 try it and see if there is some other problem that my local
 configuration has?
 
Random poking around in the postgresql.git commits didn't turn up
any where it mattered, so here's before and after files for the
example diff files already posted.  If you create branch, commit the
before copy, and copy in the after copy, you should be able to
replicate the results I posted.
 
-Kevin


predicate.h-before
Description: Binary data


predicate.h-after
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


Re: [HACKERS] security hook on table creation

2010-09-29 Thread Stephen Frost
KaiGai,

* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
 All the existing security checks applies before modifying system catalogs.

 At least, I cannot find out any constructive reason why we try to apply
 permission checks on object creation time with different manner towards
 the existing privilege mechanism...

The reason to do it was pretty clear- makes the code flow alot nicer and
make more sense.  The existing checks aren't really doing the same thing
as this one, so I don't see that as a really good reason to contort the
code.  The impression you gave is that you had a security concern
associated with this, if that's the case, please articulate what that
concern is and we can then address it.  If you concern is just about
code clarity and flow, I think I'd have to vote with Robert on this one.

Thanks,

Stephen


signature.asc
Description: Digital signature


Re: [HACKERS] operator dependency of commutator and negator

2010-09-29 Thread Tom Lane
Itagaki Takahiro itagaki.takah...@gmail.com writes:
 On Wed, Sep 29, 2010 at 11:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 I'm not sure that fixing this case is worth the amount of work it'd
 take.  How often do you drop just one member of a commutator pair?

 I found the issue when an user tries to write a safe installer
 script under DROP before CREATE coding rule:

  1. DROP OPERATOR IF EXISTS  ... ;
  2. CREATE OPERATOR  (... COMMUTATOR );
  3. DROP OPERATOR IF EXISTS  ... ;
  4. CREATE OPERATOR  (... COMMUTATOR );

 3 drops catalog-only  added at 2, and 4 adds a operator that
 has a different oid from 's commutator. The operator 
 becomes broken state in system catalog.

 Anyway, it must be a rare case, and we can just avoid the usage.

Yeah.  The above script seems incorrect anyway: if we did clean
up the commutator links fully then step 3 would undo the effect
of step 2.  So really you should drop all the operators first
and then start creating new ones.

On the other hand ... the above script pattern would do the right thing
if OperatorUpd() were willing to overwrite existing nonzero values in
the referenced operators' entries.  I'm not sure if this is a good idea
though.  I think that the reason it doesn't do it now is so that you
don't accidentally damage the links in an existing unrelated operator.
But AFAICS there are no cases where commutator and negator pairs
shouldn't be symmetrical, so simply doing nothing doesn't seem like the
right thing either: if you don't modify the other operator then you're
definitely leaving an inconsistent state in the catalogs.  Maybe what we
should do is require the user to own the referenced operator and then
unconditionally force the referenced operator's link to match.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Kohei kai...@kaigai.gr.jp wrote:
 (2010/09/29 22:00), Robert Haas wrote:

 On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheikai...@kaigai.gr.jp  wrote:

 I don't think it is an option to move the hook after the pollution
 of system catalogs, although we can pull out any information about
 the new relation from syscache.

 Why not?

 All the existing security checks applies before modifying system catalogs.

 At least, I cannot find out any constructive reason why we try to apply
 permission checks on object creation time with different manner towards
 the existing privilege mechanism...

The reason would be so that you can apply security labels if you so
desire.  If you choose to throw an error instead, transaction abort
will clean everything up.  We could have two hooks - one earlier when
we're checking DAC permisisons, and a second one later to apply
labels, but I don't see that there's enough of a gain from that to be
worth the additional complexity.  It's still simpler than your
proposed design, though.

 So what?  The patch you submitted doesn't provide the OID of the new
 schema when someone does ALTER TABLE SET SCHEMA, either.  I proposed a
 design which was much more general than what you submitted, and you're
 now complaining that it's not general enough.  It's unrealistic to
 think you're going to solve every problem with one patch.

 Sorry, I never said one patch with enough generic hook solves everything.

 By contraries, I think the proposed prototype of the hook cannot inform
 the plugins anything except for OID and event type, even if necessary.

That is true.  But ISTM that it will handle a remarkably large number
of cases very well.  We could of course do more later, either by
adding additional hooks or by adding capabilities to this one.
However, you'd first need to make a convincing argument that those
capabilities are important.

 Some of permission checks needs its specific prototype to inform extra
 information rather than OIDs; such as new label in SECURITY LABEL hook,
 new schema in upcoming ALTER TABLE SET SCHEMA, and so on...

 Of course, we can implement some of permission checks with OID of the
 target object and event type collectly. E,g. I cannot image any extra
 information to check permission on COMMENT. I never deny it.

Why not?  If you're going to prohibit another plugin from relabeling
an object based on the provider and label, why not allow or disallow
comments based on the content of the comment?  A general problem with
your designs from the very beginning is that they involve the enhanced
security provider needing to know about absolutely everything that
goes on in core, and visca versa.  That's unmaintainable and we're not
doing it.

Incidentally, wanting to know the label that some other security
provider might try to assign to an object is a crystal-clear example
of moving the goal-posts.  You had a hook for that (which I removed)
in the security label patch, and it didn't provide the label anyway.
How can it be a requirement now if it wasn't two weeks ago?  You need
to stay focused on coming up with simple, easy-to-understand hooks
that ideally have use case cases that are broader than security, but
at least that are broadly applicable to security rather than very
narrowly tailored to extremely specific things which you want to do.

I think that the remit of this patch should be to add hooks for CREATE
and DROP to every single object type in the system that are generic
and can be used for any purpose, whether security related or
otherwise, with room for extension to additional operations in future
patches.

 Moreover,
 it's far from obvious that you actually do need the details that
 you're proposing anyway.  Are you really going to write an SE-Linux
 policy that allows people to change the schema of table A to schema B
 but not schema C?  Or that allows a hypothetical smack plugin to label
 a given object with one label but not another?  And if so, are those
 absolutely must-have features for the first version or are those
 things that would be nice to have in version 3 or 4?

 In your proposition, prototype of the security hook has four arguments:
 ObjectType, oid, subid and ObjectAccessType, doesn't it?

Yes.

 When user tries to change the schema of table from A to B, we can know
 the current schema of the table using syscache, but we need to inform
 the plugin that B is the new schema, because we have no way to pull out
 what schema was provided by the user.

 As LookupCreationNamespace() checks CREATE permission on the new schema,
 SELinux also want to check permission on the new schema, not only old one.
 So, I concerned about the prototype does not inform about new schema that
 user provided using ALTER TABLE SET SCHEMA statement.

You're not answering my question.  Are you going to write an SE-Linux
policy that allows table A to be moved to schema B but not to schema
C?  And if so, is that an essential feature for the 

Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Leonardo Francalanci
  Here's my post with a (very simple) performance test:
  http://archives.postgresql.org/pgsql-hackers/2010-02/msg00766.php
 I  think the 10M rows test is more in line with what we want (83s vs.  646).


Can someone else test the patch to see if what I found is still valid?
I don't think it makes much sense if I'm the only one that says
this is faster :)




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Stalled post to pgsql-committers

2010-09-29 Thread Magnus Hagander
On Wed, Sep 29, 2010 at 17:31, Marc G. Fournier scra...@hub.org wrote:
 On Wed, 29 Sep 2010, Alvaro Herrera wrote:

 Excerpts from Peter Eisentraut's message of mi? sep 29 04:08:35 -0400
 2010:

 On s?n, 2010-09-26 at 17:11 +0200, Magnus Hagander wrote:

 Yeah, that's what you need to do. I would guess you were previously
 subscribed as pe...@postgresql.org, but the git commit scrpit sends
 the email from pete...@gmx.net, so you need to subscribe from that one
 (with or without nomail).

 No, that address was not subscribed to that list.  There must have been
 some other mechanism at work.

 Yes.  Marc had a sublist with the addresses of all committers, which
 were accepted without moderation and without being subscribed.  See
 restrict_post in the moderate section of the Mj2 settings page for
 that list; it contains pgsql-committers:restricted.

 It would be trivial to add the new list of committer addresses to that
 list.  I don't know how that list is edited though; Marc would know.
 I think either Magnus or Dave should have enough privilege to do the
 edit itself.

 its a simple subscribe ... you jus reference the sublist vs just the list
 ...

 if someone can send me a list, I can easily add them ... should the old list
 be eliminated first though ... ?

You can find the list here:
http://github.com/mhagander/pggit_migrate/blob/master/cvs2git.options#L503



-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] documentation udpates to pgupgrade.html

2010-09-29 Thread Massa, Harald Armin
Colin,


 To query for Postgresql services on Windows use:

 sc query type= service | find postgresql


sad news is that (at least on my computer) it only finds running services.


Harald


-- 
GHUM GmbH
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607

Amtsgericht Stuttgart, HRB 734971
-
persuadere.
et programmare


Re: [HACKERS] Unable to generate man pages for translated sgml

2010-09-29 Thread Peter Eisentraut
On ons, 2010-09-29 at 23:22 +0900, Tatsuo Ishii wrote:
 Starting from 9.0, it seems unable to generate man pages for Japanese
 translated sgml(generating html is ok). Until 8.4 it worked fine. Does
 anybody succeeded in generating non English/multibyte translated man pages?

You leave a lot to be guessed here, but note that since DocBook SGML
always uses Latin-1 encoding, what you are describing is by definition
impossible and could only have worked by some accident.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] documentation udpates to pgupgrade.html

2010-09-29 Thread Colin 't Hart
Oops.

Apparently type= service is the default, so we can remove that bit.

Then we should add state= all. The default = active, a third option = inactive.

So:

sc query state= all

should list all services, in all states.

And then we pipe to find which is the Windows equivalent of grep, but
it needs to have its parameter in double quotes.

So:

sc query state= all | find postgresql


Regards,

Colin



On 29 September 2010 19:26, Massa, Harald Armin c...@ghum.de wrote:
 Colin,


 To query for Postgresql services on Windows use:

 sc query type= service | find postgresql

 sad news is that (at least on my computer) it only finds running services.

 Harald

 --
 GHUM GmbH
 Harald Armin Massa
 Spielberger Straße 49
 70435 Stuttgart
 0173/9409607

 Amtsgericht Stuttgart, HRB 734971
 -
 persuadere.
 et programmare


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Dimitri Fontaine
Robert Haas robertmh...@gmail.com writes:
 On Wed, Sep 29, 2010 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 I think keeping the status information in a transient text file may
 still be a good design choice.  If you push it into pg_control it will
 be impossible to modify by hand.

 It could be done with a trivial tool, though.

pg_ctl standby … ?

-- 
dim

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Postgres vs. intel ccNUMA on Linux

2010-09-29 Thread James Robinson

Hackers,

	Any tips / conventional wisdom regarding running postgres on large- 
ish memory ccNUMA intel machines, such as a 32G dual-quad-core,  
showing two NUMA nodes of 16G each? I expect each postgres backend's  
non-shared memory usage to remain nice and reasonably sized, hopefully  
staying within the confines of its processor's local memory region,  
but how will accesses to shared memory and / or buffer cache play out?  
Do people tune their backends via 'numactl' ?


	Furthermore, if one had more than one database being served by the  
machine, would it be advisable to do this via multiple clusters  
instead of a single cluster, tweaking the processor affinity of each  
postmaster accordingly, trying to ensure each cluster's shared memory  
segments and buffer cache pools remain local for the resulting backends?


Thanks!

James Robinson
Socialserve.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Stalled post to pgsql-committers

2010-09-29 Thread Marc G. Fournier


Done

On Wed, 29 Sep 2010, Magnus Hagander wrote:


On Wed, Sep 29, 2010 at 17:31, Marc G. Fournier scra...@hub.org wrote:

On Wed, 29 Sep 2010, Alvaro Herrera wrote:


Excerpts from Peter Eisentraut's message of mi? sep 29 04:08:35 -0400
2010:


On s?n, 2010-09-26 at 17:11 +0200, Magnus Hagander wrote:



Yeah, that's what you need to do. I would guess you were previously
subscribed as pe...@postgresql.org, but the git commit scrpit sends
the email from pete...@gmx.net, so you need to subscribe from that one
(with or without nomail).


No, that address was not subscribed to that list.  There must have been
some other mechanism at work.


Yes.  Marc had a sublist with the addresses of all committers, which
were accepted without moderation and without being subscribed.  See
restrict_post in the moderate section of the Mj2 settings page for
that list; it contains pgsql-committers:restricted.

It would be trivial to add the new list of committer addresses to that
list.  I don't know how that list is edited though; Marc would know.
I think either Magnus or Dave should have enough privilege to do the
edit itself.


its a simple subscribe ... you jus reference the sublist vs just the list
...

if someone can send me a list, I can easily add them ... should the old list
be eliminated first though ... ?


You can find the list here:
http://github.com/mhagander/pggit_migrate/blob/master/cvs2git.options#L503



--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/




Marc G. FournierHub.Org Hosting Solutions S.A.
scra...@hub.org http://www.hub.org

Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 3:09 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
 Robert Haas robertmh...@gmail.com writes:
 On Wed, Sep 29, 2010 at 10:02 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 I think keeping the status information in a transient text file may
 still be a good design choice.  If you push it into pg_control it will
 be impossible to modify by hand.

 It could be done with a trivial tool, though.

 pg_ctl standby … ?

Well, no.  I mean, you'd want some kind of pg_ctl utility for starting
in master mode vs. slave mode, and for promoting a running slave to
master.

pg_ctl start -m master
pg_ctl start -m slave
pg_ctl promote

But that's not what Tom is talking about, I don't think: you might
also want a way to explicitly whack the flag in pg_control around.
That would probably be along the lines of pg_resetxlog.  I'm not sure
how much use case there is for such a thing, but if it's needed it's
certainly wouldn't be hard to write.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] the way to get tupledesc from ArrayType

2010-09-29 Thread Pavel Stehule
Hello

What is the way to get tupledesc from array of records?

Regards

Pavel Stehule

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Using streaming replication as log archiving

2010-09-29 Thread Kevin Grittner
Magnus Hagander mag...@hagander.net wrote:
 
 Comments and contributions are most welcome.
 
This is probably too esoteric to be worked on yet, but for this to
be useful for us we would need to pass the resulting files through
pg_clearxlogtail and gzip in an automated fashion.  And we would
need to do regular log file archiving in parallel with it.
 
As background, our databases around the state archive to a directory
which is then pushed via rsync to a dumb backup location in the
same room as the database server (we're lucky to have rsync on the
target of this copy; any other executable is out of the question),
and the same directory is pulled via rsync to a central location. 
We would be interested in using streaming replication to a tool such
as you describe for the copy to the central location, but since we
would still be forcing a wal-file switch once per hour we would need
the current capability to shrink an empty file from 16MB to 16kB
using the above-mentioned tools.
 
Also, a the ability to limit bandwidth would be a nice feature for
us, preferably in a way which could be changed on the fly.
 
If you could keep the development friendly to such features, I may
get around to adding them to support our needs
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Unable to generate man pages for translated sgml

2010-09-29 Thread Tatsuo Ishii
 On ons, 2010-09-29 at 23:22 +0900, Tatsuo Ishii wrote:
 Starting from 9.0, it seems unable to generate man pages for Japanese
 translated sgml(generating html is ok). Until 8.4 it worked fine. Does
 anybody succeeded in generating non English/multibyte translated man pages?
 
 You leave a lot to be guessed here, but note that since DocBook SGML
 always uses Latin-1 encoding, what you are describing is by definition
 impossible and could only have worked by some accident.

Japanese community has been using the DocBook/SGML tool chain with
EUC-JP translated documents since SGML was emplyed by
PostgreSQL. Problem with 9.0 doc build system is now it's a mixture of
DocBook/SGML *and* DocBook/XML(used for man pages). The former *only*
accepts EUC-JP, the latter *only* accepts UTF-8. So we are stuck.

The leader of Japanse translation team is thinking about to hack 9.0's
doc system to get back to good old days 8.4's. Of course it's a waste
of time in the long term but it seems it's the only thing we can do as
for now. We need to publish complete Japanses docs as soon as possible
since its one of the most important factors to make PostgreSQL popular
in Japan.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] external pid file

2010-09-29 Thread Euler Taveira de Oliveira
Hi,

Is there any reason the postmaster.pid and external_pid_file contents to be
different?


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Unable to generate man pages for translated sgml

2010-09-29 Thread Itagaki Takahiro
On Thu, Sep 30, 2010 at 8:09 AM, Tatsuo Ishii is...@postgresql.org wrote:
 Japanese community has been using the DocBook/SGML tool chain with
 EUC-JP translated documents since SGML was emplyed by
 PostgreSQL. Problem with 9.0 doc build system is now it's a mixture of
 DocBook/SGML *and* DocBook/XML(used for man pages). The former *only*
 accepts EUC-JP, the latter *only* accepts UTF-8. So we are stuck.

Why don't we just use UTF-8? I'm not sure why EUC-JP is better than UTF-8.
Also, the original postgres' documentation contains characters not in
EUC-JP, but in UTF-8. Those characters are discarded in Japanese docs?

-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Patch to reindex primary keys

2010-09-29 Thread Gurjeet Singh
Attached is a patch that implements replacing a primary key with another
index. This would help overcome the limitation that primary keys cannot be
reindexed
without taking exclusive locks.

The use case is to create an identical index, concurrenlty, with the
same
structure as the primary key, and then use this feature to atomically
replace
the primary key's underlying index.

Before I dive into the internals, here's what this patch enables
Postgres to do:

/snip
postgres=# create table mytable( a int primary key );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
mytable_pkey for table mytable
CREATE TABLE
postgres=# insert into mytable select s from generate_series( 1, 100 ) as s;
 INSERT 0 100
postgres=# create unique index concurrently mysecond_key on mytable( a );
CREATE INDEX
postgres=#
postgres=# \d mytable
Table public.mytable
 Column |  Type   | Modifiers
+-+---
 a  | integer | not null
Indexes:
mytable_pkey PRIMARY KEY, btree (a)
mysecond_key UNIQUE, btree (a)

postgres=#
postgres=# begin;
 BEGIN
postgres=# alter table mytable drop constraint mytable_pkey;
ALTER TABLE
postgres=# alter table mytable add primary key (a) with (index =
'mysecond_key' );
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index
mysecond_key for table mytable
 ALTER TABLE
postgres=# commit
postgres-# ;
COMMIT
postgres=# \d mytable
Table public.mytable
 Column |  Type   | Modifiers
+-+---
 a  | integer | not null
 Indexes:
mysecond_key PRIMARY KEY, btree (a)

/snip

Internally, this patch this patch drops current primary key constraintm,
if any,
(currently not working, but rest of the feature is still usable), and then
creates a new constraint with the given index.

Here's the pseudocode I started with:

Check if cxt-pkey-options has a 'WITH INDEX' element
take an exclusive lock on that index

Does this table have a primary key
check if index mentioned in cxt-pkey matches that PKEY
definition,
Does column list match
Do the opclasses match
Does index type match (BTree for now)
Do they have the same owner

Append a new command to newcmds to drop the PKey constraint
use 'rel' variable to get primary key's OID ( modify and reuse
relationHasPrimaryKey() )
use relation_open() to get pkey's relation
use the returned Relation-rd_rel-relname to build DROP
CONSTRAINT command
set missingok member of the command so that this would work even
if there was already a DROP CONSTRAINT for the PKey.
push this command to newcmds

Chenge the 'WITH INDEX' element, and replace index name in Value* to
have decimal representation of index's OID.
This will be used by ATExecAddIndex().


The patch is based on REl9_0_STABLE from a few days ago. It is a bit
hackish,
and modifies the couple of internal APIs to get the work done. I still have
a few
TODO items in there, but wanted to throw this patch out there to get a few
eyeballs on it while I traveled.

PS: I am (going to bed and then traveling) for the next 20 hours or so, so
will
not be able to respond to emails until then.

I dedicate this work to

my dear brother-in-law, Sandeep Singh
and my dear friend, Mandeep Singh Sethi

Good men... you will be always in our hearts. RIP.
-- 
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device


replace_pkey_index.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


Re: [HACKERS] english parser in text search: support for multiple words in the same position

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 1:29 AM, Sushant Sinha sushant...@gmail.com wrote:
 Any updates on this?


 On Tue, Sep 21, 2010 at 10:47 PM, Sushant Sinha sushant...@gmail.com
 wrote:

  I looked at this patch a bit.  I'm fairly unhappy that it seems to be
  inventing a brand new mechanism to do something the ts parser can
  already do.  Why didn't you code the url-part mechanism using the
  existing support for compound words?

 I am not familiar with compound word implementation and so I am not sure
 how to split a url with compound word support. I looked into the
 documentation for compound words and that does not say much about how to
 identify components of a token. Does a compound word split by matching
 with a list of words? If yes, then we will not be able to use that as we
 do not know all the words that can appear in a url/host/email/file.

It seems to me that you need to familiarize yourself with this stuff
and then post an analysis, or a new patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Path question

2010-09-29 Thread Greg Stark
2010/9/23 Robert Haas robertmh...@gmail.com:

 All of this leaves me wondering why Greg ended up ifdefing out this
 code in the first place.  There's probably something I'm missing
 here...  but for now I can't think of a better idea than just removing
 the #ifdefs and hoping that whatever problem they were causing was
 limited to an earlier version of the code that no longer exists.


Sorry, I haven't gone completely AWOL, I just hadn't noticed this
thread. pgsql-hackers turns out to be kind of a lot of traffic if
you're not reading it continuously.

As you subsequently discovered I added these FIXMEs because without
them the paths just didn't compare equal when it was comparing the
paths of the children with the paths of the parent.

I think the reason you had difficulty demonstrating problems with at
least some of the FIXMEs was that they really aren't functionally
necessary. They're there because when Tom implemented the equivalence
classes he had a clear idea of what they were supposed to represent
and what variables they needed to include to represent that. And
including variables of child relations or subqueries of a UNION in an
equivalence class representing the parent relation just didn't fit
within that. It doesn't necessarily cause problems but it changes the
data structure representation invariant from what he had in mind.

I don't have a good grasp of exactly what the implications of changing
this data structure rep invariant are though. Is having hundreds or
thousands of variables in a single equivalence class (actually for a
whole bunch if the pathkey list is long) going to cause performance
problems? Is including variables that are only present for one child
of the relation going to limit the usefulness of the equivalence class
data structure for solving other problems where those columns really
aren't equivalent? Also, since I don't really understand what's going
on I wondered if there wasn't an obvious way to accomplish the same
thing perhaps more efficiently.



-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] is sync rep stalled?

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 3:56 AM, Fujii Masao masao.fu...@gmail.com wrote:
 On Wed, Sep 29, 2010 at 11:47 AM, Robert Haas robertmh...@gmail.com wrote:
 So we've got two patches that implement synchronous replication, and
 no agreement on which one, if either, should be committed.  We have no
 agreement on how synchronous replication should be configured, and at
 most a tenuous agreement that it should involve standby registration.

 This is bad.

 This feature is important, and we need to get it done.  How do we get
 the ball rolling again?

 ISTM that it still takes long to make consensus on standby registration.
 So, how about putting the per-standby parameters in recovery.conf, and
 focusing on the basic features in synchronous replication at first?
 During that time, we can deepen discussion on standby registration, and
 then we can implement that.

 The basic features that I mean is for most basic use case, that is, one
 master and one synchronous standby case. In detail,

 * Support multiple standbys with various synchronization levels.

 Not required for that case.

 * What happens if a synchronous standby isn't connected at the moment? 
 Return immediately vs. wait forever.

 The wait-forever option is not required for that case. Let's implement
 the return-immediately at first.

 * Per-transaction control. Some transactions are important, others are not.

 Not required for that case.

 * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers 
 can be seen as important special cases of this.

 Not required for that case.

 * async, recv, fsync and replay levels of synchronization.

 At least one of three synchronous levels should be included in the first
 commit. I think that either recv or fsync is suitable for first try
 because those don't require wake-up signaling from startup process to
 walreceiver and are relatively easy to implement.

I'm not sure this really gets us anywhere.  We already have two
patches; writing a third one won't fix anything.  We need to decide
which patch can be the basis for future work.  According to my
understanding, the most significant difference between the patches is
the way that ACKs get sent from standby to master.  Whose idea is
better, yours or Simon's?  And why?  Are there other reasons to prefer
one patch to the other?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Unable to generate man pages for translated sgml

2010-09-29 Thread Tatsuo Ishii
 On Thu, Sep 30, 2010 at 8:09 AM, Tatsuo Ishii is...@postgresql.org wrote:
 Japanese community has been using the DocBook/SGML tool chain with
 EUC-JP translated documents since SGML was emplyed by
 PostgreSQL. Problem with 9.0 doc build system is now it's a mixture of
 DocBook/SGML *and* DocBook/XML(used for man pages). The former *only*
 accepts EUC-JP, the latter *only* accepts UTF-8. So we are stuck.
 
 Why don't we just use UTF-8? I'm not sure why EUC-JP is better than UTF-8.

UTF-8 simply does not work with some of current tool chains.

 Also, the original postgres' documentation contains characters not in
 EUC-JP, but in UTF-8. Those characters are discarded in Japanese docs?

I'm not sure how other people deal with UTF-8 since it doesn't work.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread KaiGai Kohei
(2010/09/30 0:36), Robert Haas wrote:
 On Wed, Sep 29, 2010 at 9:59 AM, KaiGai Koheikai...@kaigai.gr.jp  wrote:
 (2010/09/29 22:00), Robert Haas wrote:

 On Wed, Sep 29, 2010 at 6:38 AM, KaiGai Koheikai...@kaigai.gr.jpwrote:

 I don't think it is an option to move the hook after the pollution
 of system catalogs, although we can pull out any information about
 the new relation from syscache.

 Why not?

 All the existing security checks applies before modifying system catalogs.

 At least, I cannot find out any constructive reason why we try to apply
 permission checks on object creation time with different manner towards
 the existing privilege mechanism...
 
 The reason would be so that you can apply security labels if you so
 desire.  If you choose to throw an error instead, transaction abort
 will clean everything up.  We could have two hooks - one earlier when
 we're checking DAC permisisons, and a second one later to apply
 labels, but I don't see that there's enough of a gain from that to be
 worth the additional complexity.  It's still simpler than your
 proposed design, though.
 
Hmm. My scheme of consideration might be affected by kernel programming
which does not have any transaction rollback, so I though it needed all
the checks before doing anything.

 So what?  The patch you submitted doesn't provide the OID of the new
 schema when someone does ALTER TABLE SET SCHEMA, either.  I proposed a
 design which was much more general than what you submitted, and you're
 now complaining that it's not general enough.  It's unrealistic to
 think you're going to solve every problem with one patch.

 Sorry, I never said one patch with enough generic hook solves everything.

 By contraries, I think the proposed prototype of the hook cannot inform
 the plugins anything except for OID and event type, even if necessary.
 
 That is true.  But ISTM that it will handle a remarkably large number
 of cases very well.  We could of course do more later, either by
 adding additional hooks or by adding capabilities to this one.
 However, you'd first need to make a convincing argument that those
 capabilities are important.
 
I now understand you are never suggesting a set of forever-fixed interfaces.
If we can fix up prototype of the security hooks later, I have less concern
for the approach.
It seems to me I misunderstood the intention of your proposition, sorry.

 Some of permission checks needs its specific prototype to inform extra
 information rather than OIDs; such as new label in SECURITY LABEL hook,
 new schema in upcoming ALTER TABLE SET SCHEMA, and so on...

 Of course, we can implement some of permission checks with OID of the
 target object and event type collectly. E,g. I cannot image any extra
 information to check permission on COMMENT. I never deny it.
 
 Why not?  If you're going to prohibit another plugin from relabeling
 an object based on the provider and label, why not allow or disallow
 comments based on the content of the comment?  A general problem with
 your designs from the very beginning is that they involve the enhanced
 security provider needing to know about absolutely everything that
 goes on in core, and visca versa.  That's unmaintainable and we're not
 doing it.
 
Indeed, we can assume such a security module which also checks content
of the comment (aside from its effectivity).

 Incidentally, wanting to know the label that some other security
 provider might try to assign to an object is a crystal-clear example
 of moving the goal-posts.  You had a hook for that (which I removed)
 in the security label patch, and it didn't provide the label anyway.
 How can it be a requirement now if it wasn't two weeks ago?  You need
 to stay focused on coming up with simple, easy-to-understand hooks
 that ideally have use case cases that are broader than security, but
 at least that are broadly applicable to security rather than very
 narrowly tailored to extremely specific things which you want to do.
 
The concern was also based on my misunderstanding.
I've agreed to the small-startup approach, so I believe this hook can
be eventually fixed up.

 I think that the remit of this patch should be to add hooks for CREATE
 and DROP to every single object type in the system that are generic
 and can be used for any purpose, whether security related or
 otherwise, with room for extension to additional operations in future
 patches.
 
I agree.

 Moreover,
 it's far from obvious that you actually do need the details that
 you're proposing anyway.  Are you really going to write an SE-Linux
 policy that allows people to change the schema of table A to schema B
 but not schema C?  Or that allows a hypothetical smack plugin to label
 a given object with one label but not another?  And if so, are those
 absolutely must-have features for the first version or are those
 things that would be nice to have in version 3 or 4?

 In your proposition, prototype of the security hook has four arguments:
 ObjectType, 

Re: [HACKERS] security hook on table creation

2010-09-29 Thread Robert Haas
2010/9/29 KaiGai Kohei kai...@ak.jp.nec.com:
 But with that exception,
 they seemed to think that coarse-grained permissions would be fine for
 a basic implementation: perhaps even just install something in
 ProcessUtility_hook and bounce DDL across the board, so long as it's
 controlled by reference to the security policy rather than by DAC.  I
 think we can do better than that in a pretty short period of time if
 we avoid getting side-tracked, but the key is that we have to avoid
 getting side-tracked.

 In this approach, we eventually need to deploy the hooks on object creation
 as we are currently working on. So, I don't think using ProcessUtility_hook
 for coarse-grained permissions is a right direction.

Well, it may be the easiest way to do certain things.  For example, if
you wanted to control access to a command such as LOAD (which
presumably you do since otherwise a loadable module could trivially
subvert the security policy), it's unclear to me that there's any need
for a new hook; ProcessUtility_hook might very well be the best way to
tackle that.  We need to consider the best way to handle each case.
In some cases, all of the necessary information may not be available
when ProcessUtility_hook is called, but where it is, we shouldn't
reinvent the wheel.

With respect to this patch, I think we are on the same page now, with
possibly some disagreement about how far it makes sense to go with
this that needn't concern us for the present.  I'm going to mark this
patch Returned with Feedback, because we need to move on to other
patches that are closer to being committable.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] patch: SQL/MED(FDW) DDL

2010-09-29 Thread Itagaki Takahiro
On Wed, Sep 29, 2010 at 11:09 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
 I'm not sure that it's a good idea to embed into the FDW API the set of
 operations known to the executor.  For example your proposal fails to
 consider bitmap scans.  Seems simpler and more general to hand the quals
 over saying I need to scan this relation with these quals, and have it
 return an opaque iterable object;

Agreed. If possible, we will avoid dedicated interfaces for seqscans and
index scans. However, bitmap scan is difficult anyway because foreign tables
might not have ctid columns. It's a challenging task to identify individual
tuples in foreign tables. It will be also used for UPDATE and DELETE.

 There doesn't to be much point in knowing the names of remote indexes
 either (if it came to referencing them, better use OIDs)

FYI, HiRDB, that implements FDW routines, has CREATE FOREIGN INDEX.
I think it is a little ugly and won't work in some cases -- for example,
index organized tables -- but evidently it's a realistic solution.

-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] security hook on table creation

2010-09-29 Thread KaiGai Kohei
(2010/09/30 10:28), Robert Haas wrote:
 2010/9/29 KaiGai Koheikai...@ak.jp.nec.com:
 But with that exception,
 they seemed to think that coarse-grained permissions would be fine for
 a basic implementation: perhaps even just install something in
 ProcessUtility_hook and bounce DDL across the board, so long as it's
 controlled by reference to the security policy rather than by DAC.  I
 think we can do better than that in a pretty short period of time if
 we avoid getting side-tracked, but the key is that we have to avoid
 getting side-tracked.

 In this approach, we eventually need to deploy the hooks on object creation
 as we are currently working on. So, I don't think using ProcessUtility_hook
 for coarse-grained permissions is a right direction.
 
 Well, it may be the easiest way to do certain things.  For example, if
 you wanted to control access to a command such as LOAD (which
 presumably you do since otherwise a loadable module could trivially
 subvert the security policy), it's unclear to me that there's any need
 for a new hook; ProcessUtility_hook might very well be the best way to
 tackle that.  We need to consider the best way to handle each case.
 In some cases, all of the necessary information may not be available
 when ProcessUtility_hook is called, but where it is, we shouldn't
 reinvent the wheel.
 
In the ideal world, I want to put a new hook to control LOAD command,
because the given library name is not expanded at ProcessUtility_hook
time (and expand_dynamic_library_name() is a static function), so
we cannot know enough information to apply fine-grained control;
such as per-libraries-control.

So, right-now, all we can do in coarse-grained permissions are to
prohibit LOAD command always when SE-PgSQL is installed.
(For more detail, it is not perfect because we can overwrite the
'local_shared_libraries' setting using connection string.)

However, we understood we need to prioritize our upcoming works,
and I think the security hooks on table creation has the highest
priority than others.

 With respect to this patch, I think we are on the same page now, with
 possibly some disagreement about how far it makes sense to go with
 this that needn't concern us for the present.  I'm going to mark this
 patch Returned with Feedback, because we need to move on to other
 patches that are closer to being committable.
 
OK. I'll refactor my patch set.

| #define InvokeObjectAccessHook(objtype, oid, subid, op) \
| if (object_access_hook != NULL) \
| object_access_hook(objtype, oid, subid, op);

One my preference is functions, rather than macros, because we
need a *.c file somewhere to put pointer variable of the hook
and it will become a good place to describe source code comments
of the hook.

In addition, I want to give these entrypoints its name which
represents an appropriate purpose of the hook, rather than
a uniformed one.

Example:

/*
 * This hook is ...
 */
object_access_hook_type object_access_hook = NULL;

/*
 * check_relation_create
 *
 * This hook is invoked when ...
 :
 :
 * If violated, guest of the hook can raise an error.
 */
void
check_relation_create(Oid oid)
{
if (object_access_hook != NULL)
object_access_hook(OBJECT_TABLE, oid, OAT_CREATE);
}


Thanks,
-- 
KaiGai Kohei kai...@ak.jp.nec.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Path question

2010-09-29 Thread Robert Haas
On Wed, Sep 29, 2010 at 11:01 AM, Robert Haas robertmh...@gmail.com wrote:
 Makes sense to me.  It seems that there are actually two halves to
 this problem: getting the child EMs to be generated in the first
 place, and then getting them to be examined at the appropriate time.

So I tried out the logic described in this email and, with a few
modifications, it seemed to work.  Updated patch attached, any review
appreciated.  There are still a bunch of other things that need to be
fixed here, but I think this is OK as far as this particular issue is
concerned.  I fixed a few other things:

- create_append_plan must call create_plan_recurse rather than
create_plan.  This appears to be an error introduced by rebasing; the
previous version of the patch seg faults when attempting to execute a
plan wherein an inner index scan has been pushed down through an
append node
- remove the hack to short-circuit the append node altogether if
there's only one child
- some miscellaneous code cleanup (more is needed)

 3. TGL: Speaking of sorting, it's not entirely clear to me how the
 patch ensures that all the child plans produce the necessary sort keys
 as output columns, and especially not how it ensures that they all get
 produced in the *same* output columns.  This might accidentally manage
 to work because of the throwaway call to make_sort_from_pathkeys(),
 but at the very least that's a misleading comment.  I'm not sure what
 needs to be done about this; I'm going to look at this further.

I spent some time looking at this complaint, and I'm still not sure
what needs to be done about it.  Experimentation reveals that the
neither the throwaway call to make_sort_from_pathkeys() nor any other
call to that function is creating the relevant target list entries.
It appears that they're getting created when set_append_rel_pathlist()
calls adjust_appendrel_attrs().  I'm not sure whether that's
sufficient or not.  make_sort_from_pathkeys() could add any missing
entries later, but I'm not too sure the order would match if that
happened.

Another awkwardness of this patch is that it makes
create_append_path() and consequently set_dummy_rel_pathlist() take an
additional root argument.  While there's nothing terribly
unreasonable about this on its face, it's only necessary so that
create_append_path() can call cost_sort(), which takes root but
doesn't actually use it.  I'm not sure whether it's better to leave
this as-is or to remove the root argument from cost_sort().

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


merge_append_2010_09_29.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


Re: [HACKERS] Fw: patch for pg_ctl.c to add windows service start-type

2010-09-29 Thread Itagaki Takahiro
Hi, I have a question about the latest patch.

On Sun, Aug 22, 2010 at 11:03 PM, Quan Zongliang
quanzongli...@gmail.com wrote:
 New patch attached. How about this?
 I don't see us ever using anything other than auto or demand. The
 others aren't for regular services

+ set_starttype(char *starttypeopt)
+ {
+   if (strcmp(starttypeopt, a) == 0 || strcmp(starttypeopt, auto) == 0)
+   pgctl_start_type = SERVICE_AUTO_START;
+   else if (strcmp(starttypeopt, d) == 0 || strcmp(starttypeopt,
demand) == 0)
+   pgctl_start_type = SERVICE_DEMAND_START;

It accepts only a and auto for auto, but au or aut are rejected.
Is is an intended behavior?  I think we can use prefix match here because
we use the logic in some places. For example,

postgres=# SELECT 'tru'::bool, 'fal'::bool;
 bool | bool
--+--
 t| f
(1 row)

-- 
Itagaki Takahiro

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: I: [HACKERS] About Our CLUSTER implementation is pessimal patch

2010-09-29 Thread Josh Kupershmidt
On Wed, Sep 29, 2010 at 11:55 AM, Leonardo Francalanci m_li...@yahoo.it wrote:
 Can someone else test the patch to see if what I found is still valid?
 I don't think it makes much sense if I'm the only one that says
 this is faster :)

I ran a few more performance tests on this patch. Here's what I got
for the tests Leonardo posted originally:

   * 2M rows:  22 seconds for seq. scan, 24 seconds for index scan
   * 5M rows:  139 seconds for seq. scan, 97 seconds for index scan
   * 10M rows: 256 seconds seq. scan, 611 seconds for index scan

(times are for the cluster operation only, not for the table
creations, etc. which took most of the time)

I tried a few more tests of creating a table with either 10M or 50M
rows, then deleting 90% of the rows and running a cluster. The patch
didn't fare so well here:

 * 10M rows: 84 seconds for seq. scan, 44 seconds for index scan

The seq. scan results here were obtained with the patch applied, and
without using planner hints (enable_seqscan or enable_indexscan). I
added in an ereport() call to check that use_sort was actually true.
The index scan results were obtained without the patch applied. The
SQL file I used is attached.

So I think there are definitely cases where this patch helps, but it
looks like a seq. scan is being chosen in some cases where it doesn't
help.

Test machine: MacBook Pro laptop, C2D 2.53 GHz, 4GB RAM.
Settings: shared_buffers = 16MB, work_mem and maintenance_work_mem set
from the SQL scripts.

Josh
\timing on

BEGIN;

set work_mem='100MB';
set maintenance_work_mem='100MB';

CREATE TABLE mybloat (
  myid   int,
  name   text
);

INSERT INTO mybloat (myid, name)
   SELECT a, a::text FROM generate_series(1,1000) AS a;

ALTER TABLE mybloat ADD CONSTRAINT myid_pkey PRIMARY KEY (myid);
DELETE FROM mybloat WHERE RANDOM()  0.9;

ANALYZE mybloat;

select attname, correlation from pg_stats where tablename='mybloat';

cluster verbose mybloat using myid_pkey;

drop table mybloat;

COMMIT;

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] recovery.conf location

2010-09-29 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 But that's not what Tom is talking about, I don't think: you might
 also want a way to explicitly whack the flag in pg_control around.
 That would probably be along the lines of pg_resetxlog.  I'm not sure
 how much use case there is for such a thing, but if it's needed it's
 certainly wouldn't be hard to write.

Right, but instead of having to provide such a tool, we could just
store the status as a text file.  There is a pretty time-honored
tradition for that, ya know.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] starting to review the Extend NOT NULL representation to pg_constraint patch

2010-09-29 Thread Andrew Geery
Reference: https://commitfest.postgresql.org/action/patch_view?id=312

The patch from 
http://archives.postgresql.org/message-id/ca2e4c4762eae28d68404...@amenophis
does not apply cleanly to the current git master:

$ patch -p1  extend_not_null.patch
patching file src/backend/catalog/heap.c
patching file q
Hunk #3 succeeded at 290 (offset 1 line).
Hunk #4 succeeded at 351 (offset 1 line).
Hunk #5 succeeded at 530 (offset 1 line).
Hunk #6 FAILED at 2709.
Hunk #7 succeeded at 2957 (offset 18 lines).
Hunk #8 succeeded at 4227 (offset 68 lines).
Hunk #9 succeeded at 4574 (offset 68 lines).
Hunk #10 succeeded at 4584 (offset 68 lines).
Hunk #11 succeeded at 4673 (offset 68 lines).
Hunk #12 succeeded at 6298 (offset 72 lines).
Hunk #13 succeeded at 6312 (offset 72 lines).
Hunk #14 succeeded at 6385 (offset 72 lines).
Hunk #15 succeeded at 7098 (offset 89 lines).
Hunk #16 succeeded at 7860 (offset 89 lines).
Hunk #17 succeeded at 7947 (offset 89 lines).
Hunk #18 succeeded at 8027 (offset 89 lines).
Hunk #19 succeeded at 8075 (offset 89 lines).
Hunk #20 succeeded at 8118 (offset 89 lines).
Hunk #21 succeeded at 8146 (offset 89 lines).
Hunk #22 succeeded at 8163 (offset 89 lines).
Hunk #23 succeeded at 8246 (offset 89 lines).
Hunk #24 succeeded at 8260 (offset 89 lines).
Hunk #25 succeeded at 8310 (offset 89 lines).
Hunk #26 succeeded at 8325 (offset 89 lines).
Hunk #27 succeeded at 8333 (offset 89 lines).
Hunk #28 succeeded at 8387 (offset 89 lines).
Hunk #29 succeeded at 8417 (offset 89 lines).
1 out of 29 hunks FAILED -- saving rejects to file
src/backend/commands/tablecmds.c.rej
patching file src/backend/parser/parse_utilcmd.c
patching file src/backend/port/pg_latch.c
patching file src/backend/utils/adt/ruleutils.c
patching file src/include/catalog/heap.h
patching file src/include/catalog/pg_constraint.h
patching file src/include/nodes/parsenodes.h
Hunk #1 succeeded at 1117 (offset 1 line).
patching file src/test/regress/expected/alter_table.out
patching file src/test/regress/expected/cluster.out

$ cat src/backend/commands/tablecmds.c.rej
*** src/backend/commands/tablecmds.c
--- src/backend/commands/tablecmds.c
*** ATPrepCmd(List **wqueue, Relation rel, A
*** 2709,2715 
break;
case AT_DropNotNull:/* ALTER COLUMN DROP NOT NULL */
ATSimplePermissions(rel, false);
!   ATSimpleRecursion(wqueue, rel, cmd, recurse, lockmode);
/* No command-specific prep needed */
pass = AT_PASS_DROP;
break;
--- 2752,2761 
break;
case AT_DropNotNull:/* ALTER COLUMN DROP NOT NULL */
ATSimplePermissions(rel, false);
!
!   if (recurse)
!   cmd-subtype = AT_DropNotNullRecurse;
!
/* No command-specific prep needed */
pass = AT_PASS_DROP;
break;

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Unable to generate man pages for translated sgml

2010-09-29 Thread Peter Eisentraut
On tor, 2010-09-30 at 08:09 +0900, Tatsuo Ishii wrote:
 Problem with 9.0 doc build system is now it's a mixture of
 DocBook/SGML *and* DocBook/XML(used for man pages). The former *only*
 accepts EUC-JP, the latter *only* accepts UTF-8. So we are stuck.

How do you get to the conclusion that DocBook XML only supports UTF-8?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers