Re: [HACKERS] SSI bug?
I think I see what is going on now. We are sometimes failing to set the
commitSeqNo correctly on the lock. In particular, if a lock assigned to
OldCommittedSxact is marked with InvalidSerCommitNo, it will never be
cleared.
The attached patch corrects this:
TransferPredicateLocksToNewTarget should initialize a new lock
entry's commitSeqNo to that of the old one being transferred, or take
the minimum commitSeqNo if it is merging two lock entries.
Also, CreatePredicateLock should initialize commitSeqNo for to
InvalidSerCommitSeqNo instead of to 0. (I don't think using 0 would
actually affect anything, but we should be consistent.)
I also added a couple of assertions I used to track this down: a
lock's commitSeqNo should never be zero, and it should be
InvalidSerCommitSeqNo if and only if the lock is not held by
OldCommittedSxact.
Takashi, does this patch fix your problem with leaked SIReadLocks?
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index f6e49fe..d166da3 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -2067,7 +2067,7 @@ CreatePredicateLock(const PREDICATELOCKTARGETTAG *targettag,
SHMQueueInsertBefore((target-predicateLocks), (lock-targetLink));
SHMQueueInsertBefore((sxact-predicateLocks),
(lock-xactLink));
- lock-commitSeqNo = 0;
+ lock-commitSeqNo = InvalidSerCommitSeqNo;
}
LWLockRelease(partitionLock);
@@ -2500,6 +2500,7 @@ TransferPredicateLocksToNewTarget(const PREDICATELOCKTARGETTAG oldtargettag,
SHM_QUEUE *predlocktargetlink;
PREDICATELOCK *nextpredlock;
PREDICATELOCK *newpredlock;
+ SerCommitSeqNo oldCommitSeqNo = oldpredlock-commitSeqNo;
predlocktargetlink = (oldpredlock-targetLink);
nextpredlock = (PREDICATELOCK *)
@@ -2544,8 +2545,17 @@ TransferPredicateLocksToNewTarget(const PREDICATELOCKTARGETTAG oldtargettag,
(newpredlock-targetLink));
SHMQueueInsertBefore((newpredlocktag.myXact-predicateLocks),
(newpredlock-xactLink));
-newpredlock-commitSeqNo = InvalidSerCommitSeqNo;
+newpredlock-commitSeqNo = oldCommitSeqNo;
}
+ else
+ {
+if (newpredlock-commitSeqNo oldCommitSeqNo)
+ newpredlock-commitSeqNo = oldCommitSeqNo;
+ }
+
+ Assert(newpredlock-commitSeqNo != 0);
+ Assert((newpredlock-commitSeqNo == InvalidSerCommitSeqNo)
+ || (newpredlock-tag.myXact == OldCommittedSxact));
oldpredlock = nextpredlock;
}
@@ -3130,6 +3140,8 @@ ClearOldPredicateLocks(void)
offsetof(PREDICATELOCK, xactLink));
LWLockAcquire(SerializableXactHashLock, LW_SHARED);
+ Assert(predlock-commitSeqNo != 0);
+ Assert(predlock-commitSeqNo != InvalidSerCommitSeqNo);
canDoPartialCleanup = (predlock-commitSeqNo = PredXact-CanPartialClearThrough);
LWLockRelease(SerializableXactHashLock);
@@ -3254,6 +3266,8 @@ ReleaseOneSerializableXact(SERIALIZABLEXACT *sxact, bool partial,
errhint(You might need to increase max_pred_locks_per_transaction.)));
if (found)
{
+Assert(predlock-commitSeqNo != 0);
+Assert(predlock-commitSeqNo != InvalidSerCommitSeqNo);
if (predlock-commitSeqNo sxact-commitSeqNo)
predlock-commitSeqNo = sxact-commitSeqNo;
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] FDW state from plan time
Hi, I can't help thinking I must be missing something obvious here, but is there any way to persist some data from PlanForeignScan to at least BeginForeignScan in an FDW? I'm aware of fdwplan-fdw_private, but at that needs to be copyObject compatible, it's not much use to me. The issue I have is that in order to properly plan my remote scan, I need to connect to the remote database to try to calculate some stats for the query. I'm currently then disconnecting and freeing all the data associated with that connection, and then reconnecting again in BeginForeignScan in order to do the actual work. I'd like to avoid the connect/reconnect, as we all know they can be expensive! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL 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] Should psql support URI syntax?
On fre, 2011-04-01 at 09:12 +0200, Adrian von Bidder wrote: Since URI stings are popular, it might really make sense if pg could recommend a preferred form of postgres URI strings (and obviously implement it in libpq). For the non-libpq APIs (there's at least http://python.projects.postgresql.org/, don't know about others), it would still be just a recommendation that they could follow or not follow, so the situation wouldn't change too much from today, I fear. Well, there isn't any requirement that URIs be prot://hostname:port/something They just have to be prot:something So you could just turn the existing conninfo syntax into a URI by doing something like postgresql:dbname=foo%20hostname=bar -- 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] psql 9.1 alpha5: connection pointer is NULL
On Sat, 2011-04-02 at 18:10 -0400, Tom Lane wrote: It could explain Devrim's report if the parameters passed by psql had some problem that was detectable by conninfo_array_parse(). That seems a bit unlikely, but I did think of one possibility: if Devrim was testing 9.1 psql with a 9.0 libpq (perhaps due to an rpath issue) then 9.0 libpq would spit up on client_encoding, which wasn't a legal connection parameter in 9.0. Bingo: LD_LIBRARY_PATH=/usr/pgsql-9.1/lib/ psql -p 5433 worked. Let me fix the rpms. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Windows build issues
On Thu, Mar 31, 2011 at 22:10, Peter Eisentraut pete...@gmx.net wrote: On tor, 2011-03-31 at 16:00 -0400, Andrew Dunstan wrote: On 03/31/2011 03:38 PM, Peter Eisentraut wrote: So is 2010 supported, and where is the vcbuild program supposed to come from? Not that I know of. But VS 2008 is, and should be readily available. In fact, I recently made patches to allow it to to be used to build all the live branches. The documentation appears to claim that the Platform/Windows SDK without any Visual Studio should be enough. Is there also an upper limit on the supported SDK version then? It certainly used to be enough, so I guess if they have bounced the version of the VC compiler that's included in the SDK then yes, there needs to be an upper bound on it. What version is the compiler that comes along with the SDK reporting? (not the VS Express one, the one in the SDK itself) Guessing fromhttp://en.wikipedia.org/wiki/Microsoft_Windows_SDK, maybe we need to say up to v6.1 for now? -- 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] FDW state from plan time
Dave Page dp...@pgadmin.org writes: I can't help thinking I must be missing something obvious here, but is there any way to persist some data from PlanForeignScan to at least BeginForeignScan in an FDW? I'm aware of fdwplan-fdw_private, but at that needs to be copyObject compatible, it's not much use to me. The issue I have is that in order to properly plan my remote scan, I need to connect to the remote database to try to calculate some stats for the query. I'm currently then disconnecting and freeing all the data associated with that connection, and then reconnecting again in BeginForeignScan in order to do the actual work. I'd like to avoid the connect/reconnect, as we all know they can be expensive! I'd suggest that you reference your open connections with an integer index, which you could then store in the plan node. Plans don't have to survive longer than the current backend, so this would be perfectly safe so long as you don't re-use the indexes within a session. Or you could use a hash of some other identifying information (perhaps the OID of the foreign server would be sufficient ID for a connection?). 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] Should psql support URI syntax?
Peter Eisentraut pete...@gmx.net writes: Well, there isn't any requirement that URIs be prot://hostname:port/something They just have to be prot:something So you could just turn the existing conninfo syntax into a URI by doing something like postgresql:dbname=foo%20hostname=bar True, but the need for those %20's is annoying. I tend to agree with the suggestion that adopting the JDBC syntax would be the way to go, assuming that we can use it 100%-as-is (any incompatibility defeats the purpose). 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] Compiling a static libpq
Dear PostgreSQL developers, After having done extensive web search and not found anybody to solve the problem of interest on the general PostgreSQL mailing list, in the PostgreSQL newsgroup on usenet or on the PostgreSQL IRC channel, I would like to ask you how to compile a static libpq working without a dynamic libpq. So far, I've compiled libpq (from PostgreSQL version 8.4.6, 8.4.7 and 9.0.3) on my own under Linux (Ubuntu 10.4), Mac OS X 10.4 and Windows 7 using GCC. Indeed, I always succeeded in producing libpq.a, but linking this library to a minimal application resulted in a program which only ran with libpq.dylib (libpq.dll or libpq.so - depending on the platform) being present and not without it. It seems like the libpq.a produced by compiling PostgreSQL with ./configure and make still imports the dynamic libpq. Is there a way to get rid of the dependence on the dynamic libpq library in PostgreSQL client applications? Thanks in advance, Julia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
GUC assign hooks (was Re: [HACKERS] wal_buffers = -1 and SIGHUP)
I wrote: Robert Haas robertmh...@gmail.com writes: I had intended to commit Greg's patch with a show hook and an assign hook and the calculated value stored separately from the GUC variable, which I believe would avoid this is a problem, but Tom thought this way was better. Unfortunately, my knowledge of the GUC machinery is insufficient to think of a way to avoid it, other than the one Tom already rejected. Mph ... I think this shows the error of my thinking :-(. We at least need an assign hook here. Will fix, since it was my oversight to begin with. After thinking about this for awhile, I think the fundamental problem is in the is_newvalue_equal() function, which as its comment states is pretty cheesy: /* * Attempt (badly) to detect if a proposed new GUC setting is the same * as the current value. * * XXX this does not really work because it doesn't account for the * effects of canonicalization of string values by assign_hooks. */ If you hold your head at a funny angle you can see replacement of -1 with a suitable default value as a form of canonicalization, so the behavior Bernd complained of is exactly what the comment is talking about. We've not had complaints previously because is_newvalue_equal() is only used for PGC_POSTMASTER variables, and few of those have assign hooks that do any canonicalization. But it is possible to trigger the problem with unix_socket_directory, for example: try setting it to something like '/tmp/bogus/..', and you'll see that pg_ctl reload triggers a log message: LOG: parameter unix_socket_directory cannot be changed without restarting the server Robert had suggested fixing this by kluging up wal_buffers' assign and show hooks, but IIRC he never actually got that to work; I doubt it's possible to make it work in the EXEC_BACKEND case without some additional hacks to get the state to be properly replicated into child processes. Even if we could make it work, wal_buffers is not likely to be the last variable that we'll want to allow auto-tuning of. So I think we ought to address the underlying problem instead of trying to work around it in the variable-specific code for wal_buffers. IMO the real problem is essentially that GUC assign hooks have two functions, checking and canonicalization of the value-to-be-stored versus executing secondary actions when an assignment is made; and there's no way to get at just the first one. So we cannot canonicalize the value first and then see if it's equal to the current setting. I think the only real fix is to change the API for assign hooks. This is a bit annoying but it's not like we haven't ever done that before. I'm thinking about splitting assign hooks into two functions, along the lines of bool check_hook (datatype *new_value, GucSource source) bool assign_hook (datatype new_value, GucSource source) check_hook would validate the new value, and possibly change it (hence the pass-by-reference parameter). assign_hook would only be responsible for executing secondary actions needed when an assignment is done. The doit flag can go away since we'd not call the assign_hook at all unless we actually want the assignment to occur. I think most of the existing uses might only need one or the other of these hooks, but haven't gone through them yet. It might be appropriate to change the signatures some more while we're at it, in particular pass the desired elog message level explicitly instead of making hooks infer it from the source parameter. It would probably take less than a day to flesh out this idea and make it happen, but it does seem like a rather large change for late alpha. If people don't want to do this now, I suggest that we just live with the problem for 9.1. It's purely cosmetic, and easy enough to work around (just don't uncomment the default value). 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] FDW state from plan time
On 03.04.2011 19:38, Tom Lane wrote: Dave Pagedp...@pgadmin.org writes: I can't help thinking I must be missing something obvious here, but is there any way to persist some data from PlanForeignScan to at least BeginForeignScan in an FDW? I'm aware of fdwplan-fdw_private, but at that needs to be copyObject compatible, it's not much use to me. If you have to, you can encapsulate arbitrary data in a bytea const. Or you could use a hash of some other identifying information (perhaps the OID of the foreign server would be sufficient ID for a connection?). Foreign server + user id, probably. That's what I would recommend in this case. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PG 9.0.3. How to select rows from xml
Hi all!
What i need is transform xml document to table like that:
insert into tmp(Name, Value)
select t.Name, t.Value from myxml.Nodes(/doc/person) as
t('Name:varchar|Value:int')
or similar. In fact I have many rows with many columns.
How I can do it with PG 9.0.3 where I can't find xpath_table?
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/PG-9-0-3-How-to-select-rows-from-xml-tp4278076p4278076.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.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: GUC assign hooks (was Re: [HACKERS] wal_buffers = -1 and SIGHUP)
On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: IMO the real problem is essentially that GUC assign hooks have two functions, checking and canonicalization of the value-to-be-stored versus executing secondary actions when an assignment is made; and there's no way to get at just the first one. Yes, I think that's right. A related point is that the API for assign hooks is not consistent across all data types: string assign hooks can return a replacement value, whereas everyone else can only succeed or fail. It would probably take less than a day to flesh out this idea and make it happen, but it does seem like a rather large change for late alpha. If people don't want to do this now, I suggest that we just live with the problem for 9.1. It's purely cosmetic, and easy enough to work around (just don't uncomment the default value). I think it's a pretty ugly wart, so I'm inclined to say go ahead and fix it. I'm not sure what alpha is for if it's not cleaning up the detritus of all the stuff we've committed in the last 9 months. AIUI, what we're trying to avoid is committing new stuff that may require additional cleanup, not cleaning up the stuff we already did commit. Once we get to beta I'll be less enthusiastic about making changes like this, but I think most of the testing that will get done is still in front of us. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: GUC assign hooks (was Re: [HACKERS] wal_buffers = -1 and SIGHUP)
Robert Haas robertmh...@gmail.com writes: On Sun, Apr 3, 2011 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote: IMO the real problem is essentially that GUC assign hooks have two functions, checking and canonicalization of the value-to-be-stored versus executing secondary actions when an assignment is made; and there's no way to get at just the first one. Yes, I think that's right. A related point is that the API for assign hooks is not consistent across all data types: string assign hooks can return a replacement value, whereas everyone else can only succeed or fail. Right. In the original design we only foresaw the need to canonicalize string values, so that's why it's like that. This change will make it more consistent. 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] Process local hint bit cache
On Sat, Apr 2, 2011 at 8:37 PM, Tom Lane t...@sss.pgh.pa.us wrote: Merlin Moncure mmonc...@gmail.com writes: On Thu, Mar 31, 2011 at 5:38 PM, Merlin Moncure mmonc...@gmail.com wrote: working on exanding the cache to # xid 1. patch attached. this is essentially my original idea except it's injected directly in to tqual.c as a kind of a expansion of the 'last seen' concept. Because the cache loops are inlined and very tight (4 int compares), it's actually cheaper than jumping out of line into clog to test this_int = that_int; This seems like a mess. Why is the criterion for caching commit states different from whether the hint bit can be set? And why are you The hint bits are always set. The page is flagged dirty if and only if you have to dip below the process local cache to get it. The rationale for this is simple: it caps your downside because unlike hint bit removal or BM_UNTIDY, you only have to dip into clog and pay the i/o once per page -- so that your downside is limited to pre-cache behavior (minus the overhead of maintaining the cache). cluttering tqual.c with it? Based on the initial description I'd expected to find this enlarging the single-entry cache in transam.c to have multiple entries. This was my original idea --- abstracting it all under transam. For simplicity's sake I was playing with a dynahash of the transaction commit status, hit count, and log position keyed around the xid, and a small sweeper that came around every N misses and purged out the entries that did not have enough hit counts (or a defined minimum). The problem with that approach at least according to my initial testing was that putting two non-inline functions after the hint bit test into HeapTuplesSatisifiesMVCC ate up a lot of the savings I was looking for. I was testing on a VM, which maybe penalizes out of line code execution more than on hardware, but I wasn't happy with it and tried working the hint bit check angle. If you look upthread you can see my skepticism that a non-line cache lookup is going to work. You can trivially test this yourself if you're curious, my test was to just run: drop table t; create table t as select v from generate_series(1,50) v; and repeatedly do select count(*) from v; If you disable the hint bit action, you should see a non insignificant difference in time even though the current last xid cache in transam is there. hm. If the exposure to transam is not to your liking (I'm not happy with it either), I could make an inline stub to TransactionIdDidCommit which checks the cache and failing anything useful there, moves to out of line logic. merlin -- 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] corner case about replication and shutdown
On Sat, Apr 2, 2011 at 4:51 AM, Fujii Masao masao.fu...@gmail.com wrote: On Fri, Apr 1, 2011 at 11:11 PM, Robert Haas robertmh...@gmail.com wrote: On Thu, Mar 31, 2011 at 11:12 PM, Fujii Masao masao.fu...@gmail.com wrote: Another simple fix is to make walsender send SIGUSR1 to postmaster so that it calls PostmasterStateMachine() in sigusr1_handler(), when it marks itself as walsender. The attached patch does this. Thought? That looks OK to me. Have you tested it? Yes. I added the sleep just before MarkPostmasterChildWalSender() in walsender.c, compiled, started replication, and then requested smart shutdown as soon as walsender was forked (i.e., during the sleep). Without the patch, the server got stuck infinitely. With the patch, smart shutdown worked as expected. Cool. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [DOCS] found a very confusing and maybe outdated sentence
On Sat, Apr 2, 2011 at 3:31 AM, Susanne Ebrecht susa...@2ndquadrant.com wrote: Is man really working on Windows? Also the sentence says that the whole product isn't correct installed just because docs aren't installed. Which also isn't really true. Honesty, I just would like to drop the whole sentences. What do you think? +1 for deleting the entire sentence. Here is the patch for removing the whole sentence. Hmm... this actually removes two sentences. I've committed the removal of the one we talked about; I don't particularly see any reason to remove the following one also. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] maximum digits for NUMERIC
On Fri, Apr 1, 2011 at 7:51 AM, Noah Misch n...@leadboat.com wrote: On Fri, Apr 01, 2011 at 11:44:23AM +0100, Gianni Ciolli wrote: Please find attached v2 of the numeric-doc patch, which takes into account your remarks. In particular, numeric limits are now correct and documented only in that table. This version looks sound to me. Thank you. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] BUG #5856: pg_attribute.attinhcount is not correct.
On Fri, Apr 1, 2011 at 12:56 AM, Noah Misch n...@leadboat.com wrote: On Thu, Mar 31, 2011 at 11:11:49AM -0400, Robert Haas wrote: On Thu, Mar 31, 2011 at 6:06 AM, Noah Misch n...@leadboat.com wrote: I think this is a manifestation the same problem mentioned here: http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=31b6fc06d83c6de3644c8f2921eb7de0eb92fac3 I believe this requires some refactoring to fix. ?It would be good to do that. The best way I can see is to make ATExecAddColumn more like ATExecDropColumn, ATAddCheckConstraint, and ATExecDropConstraint. ?Namely, recurse at Exec-time rather than Prep-time, and cease recursing when we satisfy the ADD COLUMN with a merge. ?Did you have something else in mind? I had exactly what you just said in mind. Patch attached, then. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cast from integer to money
On Fri, Apr 1, 2011 at 10:33 PM, Joseph Adams joeyadams3.14...@gmail.com wrote: On Thu, Mar 31, 2011 at 6:39 PM, Stephen Frost sfr...@snowman.net wrote: Going just integer-money, with the 1 - $1.00, seems completely reasonable to me. As for being too late in the cycle.. if someone's willing to do the work, I can't imagine it breaking anything, so I wouldn't be against putting it in. It really should be before the first beta tho. Attached is a patch which enables casting int2/int4/int8 to money, with the same scaling as numeric uses. Hence, 1::money yields '$1.00' Thanks for the patch, but I think you forgot to worry about overflow: rhaas=# select 9223372036854775807::money; money -$1.00 (1 row) . The only other numeric types (other than oid, cardinal_number, etc.) that can't be casted directly to money are float4 and float8, and I suspect this is intentional. Agreed. The patch includes tests, but does not update the documentation. Should the docs be updated where it reads Values of the numeric data type can be cast to money. Other numeric types can be converted to money by casting to numeric first ? Yes. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Finding a flow when query is fired in postgresql
On Sat, Apr 2, 2011 at 5:41 AM, bschaudhari972 bschaudhari...@gmail.com wrote: i edited postgreql file so that i can check the flow of .c files invoked when we fire a query but only what i am getting is just parse trees ,rewritten trees and plan but no names of .c files invoked... plz help me asap ...its very important for me. what additional changes are required to see the names of .c files when query is fired.. I don't think you can do that just by changing settings. You could attach a debugger... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cast from integer to money
Robert Haas robertmh...@gmail.com writes: On Fri, Apr 1, 2011 at 10:33 PM, Joseph Adams joeyadams3.14...@gmail.com wrote: The only other numeric types (other than oid, cardinal_number, etc.) that can't be casted directly to money are float4 and float8, and I suspect this is intentional. Agreed. BTW, I think inclusion of int2 in this patch is just a waste of code space. The main argument for supporting these casts seems to be that integer literals produced by the parser should be castable to money without special pushups. But the parser never produces native int2 constants. So int4 and int8 will cover all the useful cases. 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
