Re: [BUGS] BUG #5895: Ability to match more than just CN in client certificate
On Thu, 3 Mar 2011 10:20:06 -0500 Robert Haas robertmh...@gmail.com wrote: [snip] It seems like there are a lot of possible combinations here that could be useful, so we'd want something that allowed a fairly flexible specification of what to match. Is this a problem you're interested in working on (i.e. contributing code)? I agree, it seems like something along the lines of a full distinguished name with the option to leave out fields would make the most sense, plus some way of specifying other fields not in the formal DN (serial #, fingerprint, or so). Thinking about it, serial number is not necessarily ideal either, since one could reasonably want to trust more than one CA. I feel like I'm pretty much saying I want to specify a single certificate, in which case the full PKI is really kind of pointless, but X.509 certificates are for better or worse the only sane way of doing non-password-based authentication over TLS right now, so that's what we've got to work with. As for contributing code, not right now, but sometime in the near future (next handful of months) I might be interested in hacking at this. Chris -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5916: PGAdmin crash
The following bug has been logged online: Bug reference: 5916 Logged by: Allan Registos Email address: allan.regis...@smpc.steniel.com.ph PostgreSQL version: 9.0.0-1-linux Operating system: Fedora 14 Description:PGAdmin crash Details: When I press the SQL query, the whole pgadmin will close. Although, it works previously. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Error mesage during installation
Good morning, I was to install latest installation of your application: postgresql-9.0.3-1-windows.exe to my PC , but there occored Error that you can see in attachment. I have Windows 7 - 32 bit system Thank you for answer. DOMČEKY-ZÁHRADNÉ Ing. Jozef Hrčka Jánskeho 12, 949 01 NITRA tel: +421 902 927 022 i...@domceky-zahradne.sk www.domceky-zahradne.sk _ Najvyhodnejsie povinne poistenie aut - http://poistenie.sme.sk attachment: Error.jpg -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Error mesage during installation
2011/3/5 Domčeky-Záhradné jozef.hr...@post.sk: Good morning, I was to install latest installation of your application: postgresql-9.0.3-1-windows.exe to my PC , but there occored Error that you can see in attachment. I have Windows 7 - 32 bit system Thank you for answer. That error comes from the Microsoft VC++ Runtimes installer. I have no idea what it means, or how to fix it, as it's Microsoft's code. You might try installing the runtimes manually - you can download them from http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2. If that works, you should be able to ignore the error from the installer. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5705: btree_gist: Index on inet changes query result
This is currently a TODO so at least we are tracking it. --- andreas wrote: On Tue, 2010-10-19 at 18:22 -0400, Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: On Mon, Oct 11, 2010 at 7:50 PM, Tom Lane t...@sss.pgh.pa.us wrote: Well, actually the btree_gist implementation for inet is a completely broken piece of junk: it thinks that convert_network_to_scalar is 100% trustworthy and can be used as a substitute for the real comparison functions, which isn't even approximately true. Are you planning to fix this? No. I don't understand why Teodor did it like that, so I'm not going to try to change it. I'd be willing to take responsibility for ripping out btree_gist's inet support altogether ... regards, tom lane That is the reason why I just reported it instead of trying to fix it myself first. Since I could not understand why it was done like that, I did not feel like fixing it. Best regards, Andreas Karlsson -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
On 04.03.2011 23:28, Kevin Grittner wrote:
I wrote:
I think what we're protecting against is disk I/O at COMMIT time,
not transaction startup.
One more thought on this -- on a properly configured server, this
code should rarely be exercised unless there is a long-running READ
WRITE transaction. The delay, if any, would be on the connection
which is committing that long running transaction.
What worries me most is that the cleanup happens while
SerializableXactHashLock is held. It's probably not a big deal in
practice, but it seems safer and probably more readable too to do the
cleanup at checkpoint.
Here's what I had in mind. Can you review, and do you have something to
test this with?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index b4eb4ac..760c0ad 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -48,6 +48,7 @@
#include storage/ipc.h
#include storage/latch.h
#include storage/pmsignal.h
+#include storage/predicate.h
#include storage/procarray.h
#include storage/reinit.h
#include storage/smgr.h
@@ -7813,6 +7814,7 @@ CheckPointGuts(XLogRecPtr checkPointRedo, int flags)
CheckPointCLOG();
CheckPointSUBTRANS();
CheckPointMultiXact();
+ CheckPointPredicate();
CheckPointRelationMap();
CheckPointBuffers(flags); /* performs all required fsyncs */
/* We deliberately delay 2PC checkpointing as long as possible */
diff --git a/src/backend/storage/lmgr/predicate.c b/src/backend/storage/lmgr/predicate.c
index 700c0db..9c40d4b 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -323,10 +323,9 @@ static SlruCtlData OldSerXidSlruCtlData;
typedef struct OldSerXidControlData
{
- int headPage;
- int tailSegment;
- TransactionId headXid;
- TransactionId tailXid;
+ int headPage; /* newest initialized page */
+ TransactionId headXid; /* newest valid Xid in the SLRU */
+ TransactionId tailXid; /* oldest xmin we might be interested in */
bool warningIssued;
} OldSerXidControlData;
@@ -711,7 +710,6 @@ OldSerXidInit(void)
* Set control information to reflect empty SLRU.
*/
oldSerXidControl-headPage = -1;
- oldSerXidControl-tailSegment = -1;
oldSerXidControl-headXid = InvalidTransactionId;
oldSerXidControl-tailXid = InvalidTransactionId;
oldSerXidControl-warningIssued = false;
@@ -722,10 +720,6 @@ OldSerXidInit(void)
* Record a committed read write serializable xid and the minimum
* commitSeqNo of any transactions to which this xid had a rw-conflict out.
* A zero seqNo means that there were no conflicts out from xid.
- *
- * The return value is normally false -- true means that we're about to
- * wrap around our space for tracking these xids, so the caller might want
- * to take action to prevent that.
*/
static void
OldSerXidAdd(TransactionId xid, SerCommitSeqNo minConflictCommitSeqNo)
@@ -733,7 +727,7 @@ OldSerXidAdd(TransactionId xid, SerCommitSeqNo minConflictCommitSeqNo)
TransactionId tailXid;
int targetPage;
int slotno;
- int page;
+ int firstZeroPage;
int xidSpread;
bool isNewPage;
@@ -745,30 +739,34 @@ OldSerXidAdd(TransactionId xid, SerCommitSeqNo minConflictCommitSeqNo)
/*
* If no serializable transactions are active, there shouldn't be anything
- * to push out to this SLRU. Hitting this assert would mean there's
+ * to push out to the SLRU. Hitting this assert would mean there's
* something wrong with the earlier cleanup logic.
*/
tailXid = oldSerXidControl-tailXid;
Assert(TransactionIdIsValid(tailXid));
+ /*
+ * If the SLRU is currently unused, zero out the whole active region
+ * from tailXid to headXid before taking it into use. Otherwise zero
+ * out only any new pages that enter the tailXid-headXid range as we
+ * advance headXid.
+ */
if (oldSerXidControl-headPage 0)
{
- page = OldSerXidPage(tailXid);
- oldSerXidControl-tailSegment = OldSerXidSegment(page);
- page = oldSerXidControl-tailSegment * OLDSERXID_ENTRIESPERPAGE;
+ firstZeroPage = OldSerXidPage(tailXid);
isNewPage = true;
}
else
{
- page = OldSerXidNextPage(oldSerXidControl-headPage);
- isNewPage = OldSerXidPagePrecedesLogically(oldSerXidControl-headPage, targetPage);
+ firstZeroPage = OldSerXidNextPage(oldSerXidControl-headPage);
+ isNewPage = OldSerXidPagePrecedesLogically(oldSerXidControl-headPage,
+ targetPage);
}
if (!TransactionIdIsValid(oldSerXidControl-headXid)
|| TransactionIdFollows(xid, oldSerXidControl-headXid))
oldSerXidControl-headXid = xid;
- if (oldSerXidControl-headPage 0
- || OldSerXidPagePrecedesLogically(oldSerXidControl-headPage, targetPage))
+ if (isNewPage)
oldSerXidControl-headPage = targetPage;
xidSpread = (((uint32) xid) - ((uint32) tailXid));
@@ -788,10 +786,10 @@ OldSerXidAdd(TransactionId xid, SerCommitSeqNo minConflictCommitSeqNo)
if (isNewPage)
