Re: [pgsql-patches] Lock compatibility matrix
> representations, both redundant with the textual description. I don't Docs patch is in SGML table representation, text view is a demonstration in mail. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [pgsql-patches] [PATCHES] pg_standby
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Simon Riggs wrote: > On Wed, 2007-01-17 at 16:15 +, Simon Riggs wrote: > > On Wed, 2007-01-17 at 10:05 -0500, Merlin Moncure wrote: > > > On 12/28/06, Simon Riggs <[EMAIL PROTECTED]> wrote: > > > > On Thu, 2006-12-28 at 19:26 +, Simon Riggs wrote: > > > > > On Thu, 2006-12-14 at 12:04 +, Simon Riggs wrote: > > > > > > pg_standby and test framework, in separate .tar files > > > > > > > > > > New version (v2), following further testing. > > > > > > > > > > Signal handling not included in this version. > > > > > > > > Signal handling now added, tested and working correctly in version 3, > > > > attached. > > > > > > > > pg_standby is an example program for a warm standby script as discussed > > > > on -hackers: > > > > http://archives.postgresql.org/pgsql-hackers/2006-08/msg00407.php > > > > > > > > Program looks complete and ready for review, to me. > > > > > > I double checked and re-ran all my test and confirmed that pg_standby > > > move (-m) mode is definitely busted in v3 in the sense that a restart > > > of the standby will not resume recovery and requires a pg_resetxlog to > > > become operational -- it needs one more WAL file back than the oldest > > > one available. > > > > new v4 > > > > Changes > > - removed -m command, design flaw in original spec, use -l instead > > - added -k N command to cleanup archive and leave max N files > > - fflush() points added to allow Windows debug > > - bug fix: when .history file present > > - bug fix: command line switch cleanup > > - readme updated > > new v6 (v5 was Windows dev release) > > Changes > > - added -r option to specify maxretries > - -l option for Windows Vista (only) using mklink > - Windows examples and docs added to readme > - code restructured to allow more easy customization > - bug fix: -k 0 error fixed > > - successful port report from Dave Page on Windows XP > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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: [pgsql-patches] Lock compatibility matrix
On Tue, 2007-01-30 at 21:33 +0100, Peter Eisentraut wrote: > Simon Riggs wrote: > > > Why would we want to have two redundant copies of the same > > > information? > > > > The lock information is not available anywhere in the form of a > > matrix. > > But it will be. A patch for the documentation has been proposed. Cool. When that's done, we probably don't need the code version. Would've been helpful if you'd explained what you meant... not many people read all posts on all lists. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] Lock compatibility matrix
Simon Riggs wrote: > > Why would we want to have two redundant copies of the same > > information? > > The lock information is not available anywhere in the form of a > matrix. But it will be. A patch for the documentation has been proposed. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] Lock compatibility matrix
"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Tue, 2007-01-30 at 11:09 +0100, Peter Eisentraut wrote: >> Why would we want to have two redundant copies of the same information? > The lock information is not available anywhere in the form of a matrix. Sure, but at this point we have proposals for adding two different matrix representations, both redundant with the textual description. I don't mind adding one of the two, but both seems overkill. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-patches] Lock compatibility matrix
On Tue, 2007-01-30 at 11:09 +0100, Peter Eisentraut wrote: > Pavan Deolasee wrote: > > I had this in a different form, but reworked so that it matches the > > doc patch that Teodor submitted earlier. I think it would be good to > > have this information in the lock.h file as well. > > Why would we want to have two redundant copies of the same information? The lock information is not available anywhere in the form of a matrix. I've personally found a matrix useful for application design, though that hasn't influenced Pavan's independent creation of exactly that. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [pgsql-patches] pg_dump pretty_print
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane wrote: > The original definition of the prettyprint flag was that it'd produce a > version that was nice to look at but not guaranteed to parse back > exactly the same; in particular it might omit parentheses that perhaps > were really needed to ensure the same parsing. (I think there might be > some other issues too ... but whitespace is NOT one of them.) It's > possible that the current prettyprint code is smart enough to never make > such an error --- and then again it's possible that it isn't. Like > Peter, I've not got much confidence in that code, and don't want to > trust pg_dump's correctness to it. Can we perhaps add to the TODO to get the pretty print functions audited and tested out? I'm sure people are already using the pretty print option today via psql so it seems like this should be a high priority. Plus of course I'd like to see it added to pg_dump once Peter, yourself, and others have more confidence in it working as one would expect. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200701301509 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFFv6YcvJuQZxSWSsgRA1ujAKDqfH1lAUcba0ce8wBjN/PIRzfNxACgnVWf XnusK0UcywWnaBDF6KE/x4E= =WoFo -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [pgsql-patches] [HACKERS] [BUGS] BUG #2907: pg_get_serial_sequence quoting
Bruce Momjian wrote:
Adriaan van Os wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I presume the reason for that is that the first paramater can be
qualified:
select pg_get_serial_sequence('"public"."FOO"', 'Ff1');
Would someone explain why qualification makes us lowercase the first
parameter by default? I don't understand it well enough to document it.
The point is that we have to parse the first parameter, whereas the
second one can be taken literally.
It still looks inconsistent and ugly. I think the design mistake of pg_get_serial_sequence is that
it takes two parameters rather than one (a fully qualified doublequoted columnname path) or three
(optionally empty schema, tablename, columnname, all three literal).
I did my best to document the behavior of pg_get_serial_sequence().
There actually is a technical reason why we can't auto-quote the first
parameter. Patch applied to HEAD and 8.2.X.
Thanks for the doc change.
Adriaan van Os
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [pgsql-patches] Phantom Command IDs, updated patch
Heikki Linnakangas wrote: Is there any regression tests for the PL languages? Certainly. See sql and expected directories for each PL. Works using standard pg_regress. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[pgsql-patches] Phantom Command IDs, updated patch
Here's an updated version of the phantom command ids patch.
I found one more subtle safety issue. The array and hash table for
phantom command ids is dynamically grown when HeapTupleHeaderSetCmax is
called. Unfortunately, since HeapTupleHeaderSetCmax is used inside a
critical sections, running out of memory while trying to grow them would
cause a PANIC. That's why I moved the SetXmax/SetCmax calls outside
critical sections in heapam.c. I believe that's safe; if a backend
aborts after setting the xmax/cmax, no-one is going to care about the
xid of an aborted transaction in there.
Per Tom's suggestion, I replaced the function cache code in fmgr.c and
similar code in plperl.c, pltcl.c, plpgsql/pl_comp.c and plpython.c to
use xmin+tid instead of xmin+cmin for the up-to-dateness check. I don't
have any tcl, perl or python test cases handy to test them, but the
change is small and essentially same for all of the above. Is there any
regression tests for the PL languages?
I made cmin and cmax system attributes aliases for the same physical
commandid field. I support the idea of a complete overhaul of those
system attributes, but let's do that in a separate patch.
To measure the overhead, I ran a plpgsql test case that updates a single
row 1 times in a loop, generating a new phantom command id in each
iteration. The test took ~5% longer with the patch, so I think that's
acceptable. I couldn't measure a difference with pgbench (as expected).
I think the patch is ready. Please remove the PHANTOMCID_DEBUG define
and ifdef blocks before applying.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index: src/backend/access/common/heaptuple.c
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/common/heaptuple.c,v
retrieving revision 1.114
diff -c -r1.114 heaptuple.c
*** src/backend/access/common/heaptuple.c 9 Jan 2007 22:00:59 - 1.114
--- src/backend/access/common/heaptuple.c 29 Jan 2007 18:01:52 -
***
*** 563,568
--- 563,569
heap_getsysattr(HeapTuple tup, int attnum, TupleDesc tupleDesc, bool *isnull)
{
Datum result;
+ CommandId commandId;
Assert(tup);
***
*** 582,596
case MinTransactionIdAttributeNumber:
result = TransactionIdGetDatum(HeapTupleHeaderGetXmin(tup->t_data));
break;
case MinCommandIdAttributeNumber:
! result = CommandIdGetDatum(HeapTupleHeaderGetCmin(tup->t_data));
break;
case MaxTransactionIdAttributeNumber:
result = TransactionIdGetDatum(HeapTupleHeaderGetXmax(tup->t_data));
break;
- case MaxCommandIdAttributeNumber:
- result = CommandIdGetDatum(HeapTupleHeaderGetCmax(tup->t_data));
- break;
case TableOidAttributeNumber:
result = ObjectIdGetDatum(tup->t_tableOid);
break;
--- 583,598
case MinTransactionIdAttributeNumber:
result = TransactionIdGetDatum(HeapTupleHeaderGetXmin(tup->t_data));
break;
+ /* cmin and cmax are now both aliases for the same commandid field,
+ * which can in fact also be a phantom command id */
case MinCommandIdAttributeNumber:
! case MaxCommandIdAttributeNumber:
! commandId = tup->t_data->t_choice.t_heap.t_field4.t_commandid;
! result = CommandIdGetDatum(commandId);
break;
case MaxTransactionIdAttributeNumber:
result = TransactionIdGetDatum(HeapTupleHeaderGetXmax(tup->t_data));
break;
case TableOidAttributeNumber:
result = ObjectIdGetDatum(tup->t_tableOid);
break;
Index: src/backend/access/heap/heapam.c
===
RCS file: /home/hlinnaka/pgcvsrepository/pgsql/src/backend/access/heap/heapam.c,v
retrieving revision 1.225
diff -c -r1.225 heapam.c
*** src/backend/access/heap/heapam.c 25 Jan 2007 02:17:25 - 1.225
--- src/backend/access/heap/heapam.c 30 Jan 2007 10:18:20 -
***
*** 1407,1414
tup->t_data->t_infomask |= HEAP_XMAX_INVALID;
HeapTupleHeaderSetXmin(tup->t_data, xid);
HeapTupleHeaderSetCmin(tup->t_data, cid);
! HeapTupleHeaderSetXmax(tup->t_data, 0); /* zero out Datum fields */
! HeapTupleHeaderSetCmax(tup->t_data, 0); /* for cleanliness */
tup->t_tableOid = RelationGetRelid(relation);
/*
--- 1407,1413
tup->t_data->t_infomask |= HEAP_XMAX_INVALID;
HeapTupleHeaderSetXmin(tup->t_data, xid);
HeapTupleHeaderSetCmin(tup->t_data, cid);
! HeapTupleHeaderSetXmax(tup->t_data, 0);
tup->t_tableOid = RelationGetRelid(relation);
/*
***
*** 1725,1732
return result;
}
- START_CRIT_SECTION();
-
/* store transaction information of xact deleting the tuple */
tp.t_data->t_infomask &= ~(HEAP_XMAX_COMMITTED |
HEAP_XMAX_INVALID |
--- 1724,1729
***
*** 1734,1743
HEAP_IS_LOCKED |
HEAP_MOVED);
HeapTupleHeaderSetXmax(tp.t_data, xid);
! HeapTupleHeaderSetCmax
Re: [pgsql-patches] Lock compatibility matrix
On 1/30/07, Peter Eisentraut <[EMAIL PROTECTED]> wrote: Pavan Deolasee wrote: > I had this in a different form, but reworked so that it matches the > doc patch that Teodor submitted earlier. I think it would be good to > have this information in the lock.h file as well. Why would we want to have two redundant copies of the same information? IMHO its useful to have this information in the source code, just like many other comments. It improves the readability of the code while documentation acts as a reference. But I am not sure whats the generally accepted practice for PostgresQL, so I may be wrong here. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [pgsql-patches] Lock compatibility matrix
Pavan Deolasee wrote: > I had this in a different form, but reworked so that it matches the > doc patch that Teodor submitted earlier. I think it would be good to > have this information in the lock.h file as well. Why would we want to have two redundant copies of the same information? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[pgsql-patches] Lock compatibility matrix
I had this in a different form, but reworked so that it matches the doc patch that Teodor submitted earlier. I think it would be good to have this information in the lock.h file as well. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com lock-compatibility.patch Description: Binary data ---(end of broadcast)--- TIP 6: explain analyze is your friend
