[PATCHES] Docs patch for Confusing Names
As discussed on [Docs], some chapter renames... On Thu, 2005-10-20 at 17:59 -0400, Neil Conway wrote: > On Thu, 2005-20-10 at 22:21 +0100, Simon Riggs wrote: > > I like very much the split of that into two sections, but I think the > > new chapter names are somewhat confusing. > > Yeah, I wasn't really sure about how to name them myself. > > > My proposal would be to rename the chapters called > > > > Server Run-time Environment > > Run-time Configuration > > > > to be > > > > Server and Operating System Environment > > Server Configuration Parameters > > IMHO "Operating System Environment" and "Server Configuration" would be > more concise. Best Regards, Simon Riggs Index: doc/src/sgml/config.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/config.sgml,v retrieving revision 1.32 diff -c -c -r1.32 config.sgml *** doc/src/sgml/config.sgml 22 Oct 2005 21:56:07 - 1.32 --- doc/src/sgml/config.sgml 25 Oct 2005 23:35:32 - *** *** 2,8 $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.32 2005/10/22 21:56:07 tgl Exp $ --> ! Run-time Configuration configuration --- 2,8 $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.32 2005/10/22 21:56:07 tgl Exp $ --> ! Server Configuration configuration Index: doc/src/sgml/runtime.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v retrieving revision 1.355 diff -c -c -r1.355 runtime.sgml *** doc/src/sgml/runtime.sgml 16 Oct 2005 21:22:12 - 1.355 --- doc/src/sgml/runtime.sgml 25 Oct 2005 23:35:34 - *** *** 3,9 --> ! Server Run-time Environment This chapter discusses how to set up and run the database server --- 3,9 --> ! Operating System Environment This chapter discusses how to set up and run the database server ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] TODO item - tid <> operator
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Mark Kirkwood wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >
> >>Bruce Momjian writes:
> >>
> >>>This has been saved for the 8.2 release:
> >>> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >>
> >>Uh, why do we need this at all? "NOT (tid = tid)" covers the
> >>functionality already.
> >
> >
> > tid should be a fully functional type, at least for = and !=.
> >
> >
> >>I disagree strongly with renumbering existing hand-assigned OIDs for
> >>this. There's too much risk of breakage and no benefit.
> >
> >
> > Agreed.
> >
> >
> >>Also, you forgot to add the negator cross-links between the operators.
> >
> >
> > OK.
> >
>
> New patch, with no OID renumbering, plus the negators are there now :-)
> Thanks for the critique guys!
>
> regards
>
> Mark
>
>
> Index: src/backend/utils/adt/tid.c
> ===
> RCS file: /projects/cvsroot/pgsql/src/backend/utils/adt/tid.c,v
> retrieving revision 1.49
> diff -c -r1.49 tid.c
> *** src/backend/utils/adt/tid.c 27 May 2005 00:57:49 - 1.49
> --- src/backend/utils/adt/tid.c 26 Oct 2005 05:07:36 -
> ***
> *** 174,180
> arg1->ip_posid == arg2->ip_posid);
> }
>
> - #ifdef NOT_USED
> Datum
> tidne(PG_FUNCTION_ARGS)
> {
> --- 174,179
> ***
> *** 185,191
> BlockIdGetBlockNumber(&(arg2->ip_blkid)) ||
> arg1->ip_posid != arg2->ip_posid);
> }
> - #endif
>
> /*
>* Functions to get latest tid of a specified tuple.
> --- 184,189
> Index: src/include/utils/builtins.h
> ===
> RCS file: /projects/cvsroot/pgsql/src/include/utils/builtins.h,v
> retrieving revision 1.267
> diff -c -r1.267 builtins.h
> *** src/include/utils/builtins.h 18 Oct 2005 20:38:58 - 1.267
> --- src/include/utils/builtins.h 26 Oct 2005 05:07:37 -
> ***
> *** 530,535
> --- 530,536
> extern Datum tidrecv(PG_FUNCTION_ARGS);
> extern Datum tidsend(PG_FUNCTION_ARGS);
> extern Datum tideq(PG_FUNCTION_ARGS);
> + extern Datum tidne(PG_FUNCTION_ARGS);
> extern Datum currtid_byreloid(PG_FUNCTION_ARGS);
> extern Datum currtid_byrelname(PG_FUNCTION_ARGS);
>
> Index: src/include/catalog/pg_proc.h
> ===
> RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_proc.h,v
> retrieving revision 1.387
> diff -c -r1.387 pg_proc.h
> *** src/include/catalog/pg_proc.h 15 Oct 2005 02:49:42 - 1.387
> --- src/include/catalog/pg_proc.h 26 Oct 2005 05:07:40 -
> ***
> *** 1625,1630
> --- 1625,1632
> DATA(insert OID = 1291 ( array_length_coerce PGNSP PGUID 12 f f t f
> s 3 2277 "2277 23 16" _null_ _null_ _null_ array_length_coerce - _null_ ));
> DESCR("adjust any array to new element typmod");
>
> + DATA(insert OID = 2601 ( tidne PGNSP PGUID 12 f f t
> f i 2 16 "27 27" _null_ _null_ _null_ tidne - _null_ ));
> + DESCR("not equal");
> DATA(insert OID = 1292 ( tideq PGNSP PGUID 12 f f t
> f i 2 16 "27 27" _null_ _null_ _null_ tideq - _null_ ));
> DESCR("equal");
> DATA(insert OID = 1293 ( currtid PGNSP PGUID 12 f f t f v 2
> 27 "26 27" _null_ _null_ _null_ currtid_byreloid - _null_ ));
> Index: src/include/catalog/pg_operator.h
> ===
> RCS file: /projects/cvsroot/pgsql/src/include/catalog/pg_operator.h,v
> retrieving revision 1.137
> diff -c -r1.137 pg_operator.h
> *** src/include/catalog/pg_operator.h 15 Oct 2005 02:49:42 - 1.137
> --- src/include/catalog/pg_operator.h 26 Oct 2005 05:07:41 -
> ***
> *** 128,135
> DATA(insert OID = 389 ( "!!" PGNSP PGUID l f 0 20
> 1700 0 0 0 0 0 0 numeric_fac - - ));
> DATA(insert OID = 385 ( "=" PGNSP PGUID b t 29 29
> 16 385 0 0 0 0 0 cideq eqsel eqjoinsel ));
> DATA(insert OID = 386 ( "=" PGNSP PGUID b t 22 22
> 16 386 0 0 0 0 0 int2vectoreq eqsel eqjoinsel ));
> ! DATA(insert OID = 387 ( "=" PGNSP PGUID b f 27 27
> 16 387 0 0 0 0 0 tideq eqsel eqjoinsel ));
> #define TIDEqualOperator 387
>
> DATA(insert OID = 410 ( "="PGNSP PGUID b t 20 20
> 16 410 411 412 412 412 413 int8eq eqsel eqjoinsel ));
> DATA(insert OID = 411 ( "<>" PGNSP PGUID b f 20 20
> 16 411 410 0 0 0 0 int8ne neqsel neqjoinsel
Re: [PATCHES] [BUGS] Bug#333854: pg_group file update problems
This bug will be fixed in the next 8.0.X release. I have not fixed
7.4.X because the risk/benefit does not warrant it, and 8.1 does not
have this problem.
---
Bruce Momjian wrote:
>
> I have developed a small patch to 8.0.X that fixes your reported
> problem:
>
> test=> CREATE GROUP g1;
> CREATE GROUP
>
> test=> CREATE USER u1 IN GROUP g1;
> CREATE USER
> test=> \! cat /u/pg/data/global/pg_group
> "g1""u1"
>
> test=> CREATE USER u2 IN GROUP g1;
> CREATE USER
> test=> \! cat /u/pg/data/global/pg_group
> "g1""u1" "u2"
>
> test=> ALTER USER u2 RENAME TO u3;
> ALTER USER
> test=> \! cat /u/pg/data/global/pg_group
> "g1""u1" "u3"
>
> In the patch, notice the old comment that suggests we might need to use
> CommandCounterIncrement().
>
> This sesms safe to apply to back branches.
>
> ---
>
> Dennis Vshivkov wrote:
> > Package: postgresql-8.0
> > Version: 8.0.3-13
> > Severity: important
> > Tags: patch, upstream
> >
> > Here's the problem:
> >
> > db=# CREATE GROUP g1;
> > CREATE GROUP
> > db=# CREATE USER u1 IN GROUP g1;(1)
> > CREATE USER
> >
> > # cat /var/lib/postgresql/8.0/main/global/pg_group
> > #
> >
> > The file gets rewritten, but the group `g1' line does not get
> > added to the file. Continue:
> >
> > db=# CREATE USER u2 IN GROUP g1;(2)
> > CREATE USER
> >
> > # cat /var/lib/postgresql/8.0/main/global/pg_group
> > "g1""u1"
> > #
> >
> > Now the line is there, but it lacks the latest member. Consider
> > this also:
> >
> > db=# ALTER USER u2 RENAME TO u3;(3)
> > ALTER USER
> >
> > # cat /var/lib/postgresql/8.0/main/global/pg_group
> > "g1""u1" "u2"
> > #
> >
> > The problem is that the code that updates pg_group file resolves
> > group membership through the system user catalogue cache. The
> > file update happens shortly before the commit, but the caches
> > only see updates after the commit. Because of this, new users
> > or changes in users' names often do not make it to pg_group.
> > That leads to mysterious authentication failures subsequently.
> > The problem can also have security implications for certain
> > pg_hba.conf arrangements.
> >
> > The attached `98-6-pg_group-stale-data-fix.patch' makes the code
> > in question access the system user table directly and thus fixes
> > the cases (1) and (2), however (3) is doubly ill: the user
> > renaming code does not even trigger a pg_group file update.
> > Hence the other patch, `98-5-rename-user-update-pg_group.patch'.
> >
> > A byproduct of the main fix is removal of an unlikely system
> > cache reference leak which happens if a group member name
> > contains a newline.
> >
> > The problems were found and the fixes were done for PostgreSQL
> > 8.0.3 release. The flaws seem intact in 8.0.4 source code, too.
> >
> > Hope this helps.
> >
> > --
> > /Awesome Walrus <[EMAIL PROTECTED]>
>
> [ Attachment, skipping... ]
>
> [ Attachment, skipping... ]
>
> >
> > ---(end of broadcast)---
> > TIP 4: Have you searched our list archives?
> >
> >http://archives.postgresql.org
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup.| Newtown Square, Pennsylvania 19073
> Index: src/backend/commands/user.c
> ===
> RCS file: /cvsroot/pgsql/src/backend/commands/user.c,v
> retrieving revision 1.147
> diff -c -c -r1.147 user.c
> *** src/backend/commands/user.c 31 Dec 2004 21:59:42 - 1.147
> --- src/backend/commands/user.c 14 Oct 2005 15:42:17 -
> ***
> *** 175,183
>
> /*
>* Read pg_group and write the file. Note we use SnapshotSelf to
> ! * ensure we see all effects of current transaction. (Perhaps could
> ! * do a CommandCounterIncrement beforehand, instead?)
>*/
> scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
> while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
> {
> --- 175,183
>
> /*
>* Read pg_group and write the file. Note we use SnapshotSelf to
> ! * ensure we see all effects of current transaction.
>*/
> + CommandCounterIncrement();
> scan = heap_beginscan(grel, SnapshotSelf, 0, NULL);
> while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
> {
> ***
> *** 781,786
> --- 781,787
>* Set flag to update flat password file at commit.
>*/
> user_file_update_needed();
> + gro
Re: [PATCHES] [HACKERS] expanded \df+ display broken in beta4
Michael Paesold wrote:
> Bruce Momjian wrote:
> > Michael Paesold wrote:
> >
> >>Tom Lane wrote:
> >>
> >>>"Michael Paesold" <[EMAIL PROTECTED]> writes:
> >>>
> Robert Treat wrote:
>
> >ISTM even a GUC to enable/disable would have been better scheme than
> >what we have now; we are basically leaving no options for those who
> >found the old behavior useful, while what we had before would at least
> >let people switch back and forth.
> >>>
> I think Robert is right here and the new behaviour is a step backwards.
> >>>
> >>>Should we revert the patch for the time being, and take another go at it
> >>>in 8.2?
>
> > One idea is to hack \d not to honor \x, and let the others honor it.
> > That would probably hit most of the cases people will use in 8.1.
> >
> > In fact, \d is pretty special because it is more of a group of outputs,
> > unlike \df, which is a single table output.
>
> +1 from me. That seems like a workable compromise and should probably
> meet the needs of the author of the patch to change the \x behavior.
OK, here is a patch that disables expanded output only for \d tablename.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/bin/psql/common.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/common.c,v
retrieving revision 1.108
diff -c -c -r1.108 common.c
*** src/bin/psql/common.c 15 Oct 2005 02:49:40 - 1.108
--- src/bin/psql/common.c 27 Oct 2005 05:03:11 -
***
*** 795,802
{
printQueryOpt my_popt = pset.popt;
- my_popt.topt.normal_query = true;
-
/* write output to \g argument, if any */
if (pset.gfname)
{
--- 795,800
Index: src/bin/psql/describe.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.128
diff -c -c -r1.128 describe.c
*** src/bin/psql/describe.c 20 Oct 2005 05:15:09 - 1.128
--- src/bin/psql/describe.c 27 Oct 2005 05:03:12 -
***
*** 703,708
--- 703,711
retval = false;
+ /* This output looks confusing in expanded mode. */
+ myopt.disableExpanded = true;
+
initPQExpBuffer(&buf);
initPQExpBuffer(&title);
initPQExpBuffer(&tmpbuf);
Index: src/bin/psql/print.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/print.c,v
retrieving revision 1.78
diff -c -c -r1.78 print.c
*** src/bin/psql/print.c15 Oct 2005 02:49:40 - 1.78
--- src/bin/psql/print.c27 Oct 2005 05:03:12 -
***
*** 1491,1497
* normal (user-submitted) query, not a table we're printing for a slash
* command.
*/
! if (opt->expanded && opt->normal_query)
use_expanded = true;
else
use_expanded = false;
--- 1491,1497
* normal (user-submitted) query, not a table we're printing for a slash
* command.
*/
! if (opt->expanded && !opt->disableExpanded)
use_expanded = true;
else
use_expanded = false;
Index: src/bin/psql/print.h
===
RCS file: /cvsroot/pgsql/src/bin/psql/print.h,v
retrieving revision 1.29
diff -c -c -r1.29 print.h
*** src/bin/psql/print.h15 Oct 2005 02:49:40 - 1.29
--- src/bin/psql/print.h27 Oct 2005 05:03:12 -
***
*** 43,50
* decimal
marker */
char *tableAttr; /* attributes for HTML */
int encoding; /* character encoding */
! boolnormal_query; /* are we presenting the results of a
"normal"
!* query, or a
slash command? */
} printTableOpt;
--- 43,49
* decimal
marker */
char *tableAttr; /* attributes for HTML */
int encoding; /* character encoding */
! booldisableExpanded;/* Should we honor \x? Not for \d. */
} printTableOpt;
Index: src/bin/psql/startup.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.125
diff -c -c -r1.125 startup.c
*** src/bin/psql/startup.c 15 Oct 2005 02:49:40 - 1.125
--- src/bin/psql/startup.c 27 Oct 2005 05:03:12 -
***
*** 147,153
pset.queryFout = s
