Re: [HACKERS] Alias hstore's ? to ~ so that it works with JDBC
On Wed, 6 Feb 2013, Seamus Abshere wrote: I personally don't know of any way around the conflict except changing JDBC or hstore, and I don't think JDBC is gonna change. I think changing JDBC is the way to go. Currently JDBC supports escape sequences for cross database portability and it seems reasonable to support an escape sequence that allowed passing ? to the backend instead of interpreting it as a parameter. This will be more complicated than you might hope because the escape processing currently happens prior to bind parameter detection so I'm not sure what a good patch would really look like, but given the feedback provided here, it's worth investigating. Kris Jurka -- 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] Alias hstore's ? to ~ so that it works with JDBC
On Fri, 8 Feb 2013, Dave Cramer wrote: Would this be an postgresql specific escape sequence ? I don't think the spec allows for this does it ? Yes, this would be a postgresql jdbc driver specific escape. The spec doesn't have a concept of private escape sequences, but that doesn't seem like the end of the world. Clearly the user here is writing postgresql specific code to use hstore operators, so there's not a portability loss here. Kris Jurka -- 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] Java LISTEN/NOTIFY client library work-around
On Wed, 30 Nov 2011, Joel Jacobson wrote: As you know, LISTEN/NOTIFY is broken in the Java client library. You have to do a SELECT 1 in a while-loop to receive the notifications. http://jdbc.postgresql.org/documentation/head/listennotify.html This documentation is out of date. Currently you can get notifications without polling the database if you are not using a SSL connection. You still must poll the driver, using PGConnection.getNotifications, but it will return new notifications received without an intermediate database query. This doesn't work over SSL and potentially some other connection types because it uses InputStream.available that not all implementations support. Kris Jurka -- 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] New copyright program
On 8/19/2011 10:51 AM, Bruce Momjian wrote: David Fetter wrote: [Here's a new copyright program.] Thanks. Applied to HEAD. I never liked putting scripts in git that only I could run, but I thought if something happened to me, it would be good to record what I did. The Perl solution is perfect. For me this fails with: Bareword Tie::File not allowed while strict subs in use at /home/jurka/pg/server/postgresql/src/tools/copyright.pl line 28. Using perl -v: This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64-linux-gnu-thread-multi Additionally it would be nice if this file was marked executable in git. Kris Jurka -- 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] New copyright program
On Fri, 19 Aug 2011, Kris Jurka wrote:
For me this fails with:
Bareword Tie::File not allowed while strict subs in use at
/home/jurka/pg/server/postgresql/src/tools/copyright.pl line 28.
This fixes things for me. The copyright matching wasn't working for me
either without escaping the parentheses.
Kris Jurkadiff --git a/src/tools/copyright.pl b/src/tools/copyright.pl
index 96b1f22..9531430 100644
--- a/src/tools/copyright.pl
+++ b/src/tools/copyright.pl
@@ -10,10 +10,11 @@
use strict;
use warnings;
+use Tie::File;
use File::Find;
my $pgdg = 'PostgreSQL Global Development Group';
-my $cc = 'Copyright (c) ';
+my $cc = 'Copyright \(c\) ';
# year-1900 is what localtime(time) puts in element 5
my $year = 1900 + ${[localtime(time)]}[5];
@@ -25,7 +26,7 @@ sub wanted {
return unless -f $File::Find::name;
my @lines;
-tie @lines, Tie::File, $File::Find::name;
+tie @lines, 'Tie::File', $File::Find::name;
foreach my $line (@lines) {
# We only care about lines with a copyright notice.
--
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] New copyright program
On Fri, 19 Aug 2011, Bruce Momjian wrote: Was able to reproduce the error you reported with Perl 5.10. I then tried the single-quote idea I got from Googling, but then got an error about TIEARRAY being missing, so I recoded it as a simple file open/close. I also incorported your regex fix. Path attached and applied. Thanks. Did you also try the use Tie::File addition in my fix because your current coding doesn't work at all. The tie operation is key to actually writing out the modified copyright notice. Your version just updates the copyright year in memory, but never gets it back to the file. Kris Jurka -- 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] New copyright program
On Fri, 19 Aug 2011, Bruce Momjian wrote: Andrew Dunstan wrote: It probably doesn't matter that much in this context, but I should point out that Tie::File is not universally available. Some years ago I had to revert its use in the buildfarm code for that reason. In general we should try to avoid adding extra dependencies wherever possible. I can easily change this to rewrite files that contain copyright changes --- should I? No. We don't need a super portable copyright year changing script. Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] [HACKERS] JDBC connections to 9.1
On Tue, 19 Apr 2011, Tom Lane wrote: Kris Jurka bo...@ejurka.com writes: On Mon, 18 Apr 2011, Mike Fowler wrote: As there seems to be a consensus forming for fixing the JDBC driver, I've taken the liberty do so at the risk of being shot down. The patch is fairly straightforward, just changing UNICODE to UTF8 in a number of files including the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7. For each database version I build and the tests running JDKs 1.4.2_19, 1.5.0_22 and 1.6.0_2. All on 32-bit. Thanks, applied, mostly. It's great to have a patch for a problem before you even know it exists. For purposes of the notes in the server-side fix, could you state which JDBC driver versions these changes will first appear in? This is in 9.1dev-900 and won't be backpatched. http://jdbc.postgresql.org/download.html#development Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [JDBC] [HACKERS] JDBC connections to 9.1
On Mon, 18 Apr 2011, Mike Fowler wrote: On 18/04/11 17:12, Tom Lane wrote: Dave Cramerp...@fastcrypt.com writes: Well initially my concern was that people would have a challenge in the case where they had to re-certify their application if we made this change, however I realize they will have to do this anyway since upgrading to 9.1 is what necessitates it. I don't see any backwards compatibility risk, if that's what you mean. Every backend release since 7.3 has treated client_encoding 'UTF8' and 'UNICODE' the same, and earlier releases didn't accept either one. regards, tom lane As there seems to be a consensus forming for fixing the JDBC driver, I've taken the liberty do so at the risk of being shot down. The patch is fairly straightforward, just changing UNICODE to UTF8 in a number of files including the translation files. I've tested this against 9.1devel (HEAD) and 8.4.7. For each database version I build and the tests running JDKs 1.4.2_19, 1.5.0_22 and 1.6.0_2. All on 32-bit. Thanks, applied, mostly. It's great to have a patch for a problem before you even know it exists. I didn't modify the .po files. I doubt this will change the adjacent translation wording, but directly patching .po files is only something to do in more dire circumstances (like needing to make a backpatch to an old branch that won't get translators to look at it before the next release.) I also discarded your changes to AbstractJdbc3Statement. Those Unicode mentions are from the interface Javadoc, so I left them alone. Kris Jurka -- 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] [JDBC] Support for JDBC setQueryTimeout, et al.
On Mon, 22 Nov 2010, Itagaki Takahiro wrote: On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura rsmog...@softperience.eu wrote: Regarding JDBC in the CF process -- other interfaces are handled there. I haven't seen one patch this size for JDBC since I've been involved, let alone two competing patches to implement the same feature. Small patches which can be quickly handled don't make sense to put into the process, but it seemed reasonable for these. In any way I'm sending this patch, and I will put this under Miscellaneous in CF. This cleared patch takes only 47k (in uncleared was some binary read classes) and about 50% it's big test case. I changed the patch's topic to JDBC. https://commitfest.postgresql.org/action/patch_view?id=399 I don't think it makes sense to try to manage anything other than core code in the commitfest app. The other patch touched the backend, so it made sense to put it in the commitfest, but as far as I understand it, this one is pure Java code. There is a backlog of JDBC issues to deal with, but I think it needs its own commitfest instead of trying to tack on to the main project's. Kris Jurka -- 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] [JDBC] Trouble with COPY IN
On Sat, 7 Aug 2010, Kris Jurka wrote:
On Fri, 6 Aug 2010, James William Pye wrote:
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I imagine.
Hmm, not quite sure why that is. That seems to imply that it's not using V3
protocol, but I thought binary copy could only be used with the V3 protocol.
In any case, I think this new patch is more bulletproof.
Oh, duh. It's a server side copy not going through the client at all.
Here's a hopefully final patch.
Kris Jurka*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
*** 2058,2069 CopyFrom(CopyState cstate)
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count) ||
! fld_count == -1)
{
done = true;
break;
}
if (fld_count != attr_count)
ereport(ERROR,
--- 2058,2088
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count))
{
done = true;
break;
}
+
+ if (fld_count == -1)
+ {
+ /*
+* Received EOF marker. Check to see if this
is really
+* the EOF and complain if we find any more
data.
+* In a V3 protocol copy, this also enforces
that we wait
+* for the protocol end of copy (CopyDone/Fail).
+*/
+ int8 unused;
+ if (CopyGetData(cstate, unused,
sizeof(unused), sizeof(unused)))
+ {
+ ereport(ERROR,
+
(errcode(ERRCODE_BAD_COPY_FILE_FORMAT),
+errmsg(received copy
data after EOF marker)));
+ }
+
+ done = true;
+ break;
+ }
if (fld_count != attr_count)
ereport(ERROR,
--
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] [JDBC] Trouble with COPY IN
On Fri, 6 Aug 2010, James William Pye wrote:
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
binary-copy-end-v2.patch
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I imagine.
Hmm, not quite sure why that is. That seems to imply that it's not using
V3 protocol, but I thought binary copy could only be used with the V3
protocol. In any case, I think this new patch is more bulletproof.
Kris Jurka
*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
*** 2058,2069 CopyFrom(CopyState cstate)
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count) ||
! fld_count == -1)
{
done = true;
break;
}
if (fld_count != attr_count)
ereport(ERROR,
--- 2058,2090
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count))
{
done = true;
break;
}
+
+ if (fld_count == -1)
+ {
+ /*
+* Reached EOF. In protocol version 3, we must
wait for
+* the protocol end of copy (CopyDone/Fail).
If we
+* receive any more copy data after EOF,
complain.
+*/
+ if (cstate-copy_dest == COPY_NEW_FE)
+ {
+ int8 unused;
+ if (CopyGetData(cstate, unused,
sizeof(unused), sizeof(unused)))
+ {
+ ereport(ERROR,
+
(errcode(ERRCODE_BAD_COPY_FILE_FORMAT),
+
errmsg(received copy data after EOF marker)));
+ }
+ }
+
+ done = true;
+ break;
+ }
if (fld_count != attr_count)
ereport(ERROR,
--
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] [JDBC] Trouble with COPY IN
On Wed, 28 Jul 2010, James William Pye wrote:
Not directly regarding your patch, but while the discussion is in the
general area. I think it would be wise to throw an error when non-empty
CopyData messages are received after CopyData(EOF). Chances are that the
user is making a mistake and should be notified of it.
As this is also the direction that Tom Lane indicated we should go, here
is a patch which errors out after receiving any more copy data past the
EOF marker. This also fixes the protocol problem I previously brought up
because the act of checking to see if there is any more data does ensure
that if there isn't any more data in the current buffer, that we wait for
the client to provide CopyDone/Fail.
Kris Jurka*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
*** 2058,2069 CopyFrom(CopyState cstate)
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count) ||
! fld_count == -1)
{
done = true;
break;
}
if (fld_count != attr_count)
ereport(ERROR,
--- 2058,2090
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count))
{
done = true;
break;
}
+
+ if (fld_count == -1)
+ {
+ /*
+* Reached EOF. In protocol version 3, we must
wait for
+* the protocol end of copy (CopyDone/Fail).
If we
+* receive any more copy data after EOF,
complain.
+*/
+ if (cstate-copy_dest == COPY_NEW_FE)
+ {
+ int8 unused;
+ if (CopyGetData(cstate, unused,
sizeof(unused), sizeof(unused)))
+ {
+ ereport(ERROR,
+
(errcode(ERRCODE_BAD_COPY_FILE_FORMAT),
+
errmsg(received copy data after EOF marker)));
+ } else {
+ done = true;
+ break;
+ }
+ }
+ }
if (fld_count != attr_count)
ereport(ERROR,
--
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] [JDBC] Trouble with COPY IN
On Wed, 28 Jul 2010, James William Pye wrote: hrm, I suppose a lazy way around that problem would be to suspend all client messages(client_min_messages) during COPY IN. Tho, I guess one would still have to contend with NotificationResponse, and ParameterStatus.. Technically you won't get NotificationResponse until transaction end, so you don't need to worry about that mid copy. I don't think you would have to peek in. If the interface were to always hold onto the last message or last n-bytes submitted to be sent, it would be able to send the possible CopyData(EOF) and CopyDone once the COPY operation (at the interface level) is closed/shutdown/terminated. Granted, this is dependent on CopyData(EOF) not being in the middle of regular CopyData, but I gather that that would end in an ErrorResponse anyways. One of the key points of confusion is that CopyData(EOF) does not result in an error. It results in ignoring any futher data. The problem I have is that for text mode it waits for CopyDone, but in binary mode it ends the copy sequence immediately. Additionally the interface exposed by the JDBC driver lets the user write arbitrary CopyData bytes to the server, so without parsing all of that we don't know whether they've issued CopyData(EOF) or not. Kris Jurka -- 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] [JDBC] Trouble with COPY IN
On Sat, 24 Jul 2010, James William Pye wrote: On Jul 23, 2010, at 7:11 AM, Tom Lane wrote: I can't help thinking that the JDBC driver must be being overly cute if this breaks it ... I was wondering the same thing when I first saw Kris' message. However, iff I understand what JDBC is trying to achieve, I don't think I would call it overly. Is this a problem because JDBC is trying to detect failures as early as possible during a COPY IN? Or, is it just JDBC's normal MO to always be reading? The JDBC driver reads server messages for multiple reasons. One of them is indeed to do early failure detection. Another is to pickup NoticeResponse messages to avoid a network buffer deadlock. If someone puts a trigger on the table you're copying data into that does RAISE NOTICE 'received row X' for each row, to avoid a full network buffer deadlock, the client must regularly read from the backend. So as we are reading along, supposing that we're still mid-copy, we get a command complete message. So this is possible to work around driver side by peeking into the network stream and delaying processing of the end of copy until the driver agrees that the copy is done, but I still maintain that this is a server bug. It is not OK for the server to assume that the client is done and move on, the client must tell the server what it wants done. Kris Jurka -- 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] [JDBC] Trouble with COPY IN
On Thu, 22 Jul 2010, Robert Haas wrote: On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka bo...@ejurka.com wrote: Attached is a patch to make the server continue to consume protocol data until instructed to stop by the client in the same way as copying text data to the server currently works. I guess the obvious question is whether we shouldn't instead change the docs to match the behavior. I suspect there's almost no chance we'd consider back-patching a change of this type, since it is a clear behavior change. And even if we did, there would still be people running servers with the old behavior with which JDBC and other drivers would have to cope. Having two different behaviors might be worse than the status quo. It is a clear behavior change, but that's what bug fixes are. I would advocate back-patching this because I doubt many people would be affected by this change and I think it would be awkward trying to document how things work differently in binary mode when sending a file end marker than in text mode or without a file end marker. If this was fixed server side and backpatched, I would not modify the JDBC driver to work with older server versions. The copy documentation is clear that you must call PQputCopyEnd or equivalent to end the copy sequence, so this would only affect people who are not doing that and using binary copy mode. I doubt many people are using binary copy at all because of the additional difficulty in generating binary format data and the potential for portability problems. Kris Jurka -- 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] [JDBC] Trouble with COPY IN
On 7/23/2010 6:40 AM, Tom Lane wrote: Kris Jurkabo...@ejurka.com writes: Attached is a patch to make the server continue to consume protocol data until instructed to stop by the client in the same way as copying text data to the server currently works. I believe this is a misunderstanding of the protocol spec. The spec is (intended to say that) we'll continue to accept data after reporting an error, not that we will silently swallow an incorrect data stream and not complain about it. Which is what this patch will do. All this does is make binary mode match text mode. Are you planning on changing text mode to match binary mode instead? Currently text mode parsing ends at the data end marker (\.) and throws away any further data which may or may not be ill formatted. For example there's no complaint about copying the following data file into a single column integer table even though there is bogus data after the file end marker 3 4 \. asdf aff 5 qq Kris Jurka -- 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] [JDBC] Trouble with COPY IN
On Fri, 23 Jul 2010, Tom Lane wrote: Kris Jurka bo...@ejurka.com writes: On 7/23/2010 6:40 AM, Tom Lane wrote: I believe this is a misunderstanding of the protocol spec. The spec is (intended to say that) we'll continue to accept data after reporting an error, not that we will silently swallow an incorrect data stream and not complain about it. Which is what this patch will do. All this does is make binary mode match text mode. The fact that text mode eats data after \. is a backwards-compatibility kluge to match the behavior of pre-7.4 COPY. It could very legitimately be argued to be a bug in itself. I don't think that we should make binary mode match it. The main concrete reason why not is that binary mode has almost no redundancy. It would be really easy for the code change you suggest to result in data being silently discarded with no hint of what went wrong. Binary copy mode already does this (eat data silently after -1 field count). The patch I sent just made it follow the fe/be protocol while it does so. jurka=# create table copytest (a int); CREATE TABLE jurka=# insert into copytest values (1); INSERT 0 1 jurka=# \copy copytest to copydata with binary jurka=# \! echo garbage copydata jurka=# \copy copytest from copydata with binary jurka=# select * from copytest; a --- 1 1 (2 rows) After some reflection, I think the real issue here is that the JDBC driver is depending on a behavior not stated in the protocol, which is the relative timing of FE-to-BE and BE-to-FE messages. Once you've sent the EOF marker, the only correct follow-on for a spec-compliant frontend is a CopyEnd message. So the backend is just sending its response a bit sooner. There's nothing in the protocol spec forbidding that. What about CopyFail? The protocol docs say nothing about the message contents only about the messages themselves. Kris Jurka -- 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] [JDBC] Trouble with COPY IN
Per discussion and investigation on the -jdbc list, the server appears to
violate the frontend/backend protocol when binary copy data is sent to the
server. Upon receiving the binary copy end of data marker (a -1 field
count), the server immediately responds with CommandComplete and
ReadyForQuery without waiting for the frontend to issue CopyDone or
CopyFail. This confuses the JDBC driver as it doesn't think the command
sequence should have finished yet.
Attached is a patch to make the server continue to consume protocol data
until instructed to stop by the client in the same way as copying text
data to the server currently works.
http://www.postgresql.org/docs/8.4/static/protocol-flow.html#PROTOCOL-COPY
http://www.postgresql.org/docs/8.4/static/sql-copy.html
Kris Jurka*** a/src/backend/commands/copy.c
--- b/src/backend/commands/copy.c
***
*** 2058,2069 CopyFrom(CopyState cstate)
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count) ||
! fld_count == -1)
{
done = true;
break;
}
if (fld_count != attr_count)
ereport(ERROR,
--- 2058,2087
int16 fld_count;
ListCell *cur;
! if (!CopyGetInt16(cstate, fld_count))
{
done = true;
break;
}
+
+ if (fld_count == -1)
+ {
+ /*
+* Reached EOF. In protocol version 3, we
should ignore
+* anything after the end of copy data marker
up to the
+* protocol end of copy data (CopyDone/Fail).
+*/
+ if (cstate-copy_dest == COPY_NEW_FE)
+ {
+ do
+ {
+ cstate-raw_buf_index =
cstate-raw_buf_len;
+ } while (CopyLoadRawBuf(cstate));
+ continue;
+ }
+ done = true;
+ break;
+ }
if (fld_count != attr_count)
ereport(ERROR,
--
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] Server crash while trying to read expression using pg_get_expr()
On Wed, 9 Jun 2010, Heikki Linnakangas wrote: Are you thinking we should retrict pg_get_expr() to superusers then? That seems like it will cause problems for both pg_dump and drivers which want to return metadata as pg_get_expr has been the recommended way of fetching this information. The JDBC driver uses pg_get_expr to decode both pg_attrdef.adbin and pg_index.indpred. Kris Jurka -- 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] TCP keepalive support for libpq
On Thu, 11 Feb 2010, Andrew Chernow wrote: Although, I think Dave's comments have made me change my mind about this patch. Looks like it serves a good purpose. That said, there is no guarentee the driver will implement the new feature ... JDBC seems to lack the ability to get the backing Socket object but java can set socket options. Maybe a JDBC kong fu master knows how to do this. Use the tcpKeepAlive connection option as described here: http://jdbc.postgresql.org/documentation/84/connect.html#connection-parameters Java can only enable/disable keep alives, it can't set the desired timeout. http://java.sun.com/javase/6/docs/api/java/net/Socket.html#setKeepAlive%28boolean%29 Kris Jurka -- 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] Avoiding bad prepared-statement plans.
On Tue, 9 Feb 2010, Mark Mielke wrote: In a current commercial app we have that uses JDBC and prepared plans for just about everything, it regularly ends up with execution times of 30+ milliseconds when a complete plan + execute would take less than 1 millisecond. PostgreSQL planning is pretty fast. In terms of not over thinking things - I think I would even prefer an option that said always re-plan prepared statements as a starting point. If it happened to become smarter over time, such that it would have invalidation criteria that would trigger a re-plan, that would be awesome, but in terms of what would help me *today* - being able to convert prepared plans into just a means to use place holders would help me today on certain real applications in production use right now. The JDBC driver has two methods of disabling permanently planned prepared statements: 1) Use the version two frontend/backend protocol via adding protocolVersion=2 to your URL. This interpolates all parameters into the query on the client side. 2) Execute PreparedStatements using the unnamed statement rather than a named statement via adding prepareThreshold=0 to your URL. A named statement is expected to be re-used for later execution and ignores the passed parameters for planning purposes. An unnamed statement may be re-used, but it doesn't expect to be. The unnamed statement uses the passed parameters for planning purposes, but still cannot make certain optimatizations based on the parameter values because it may be re-executed again later with different parameters. For example a LIKE query with a parameter value of 'ABC%' cannot be transformed into range query because the next execution may use a different parameter value for which the transform is not valid. By default the driver switches to using a named statement after the same PreparedStatement object is executed five times. http://jdbc.postgresql.org/documentation/84/connect.html#connection-parameters http://jdbc.postgresql.org/documentation/84/server-prepare.html Kris Jurka -- 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] Cancelling idle in transaction state
On Thu, 31 Dec 2009, Simon Riggs wrote: On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote: I still think that we should have three transaction cancel modes, one to cancel an idle transaction, another one to cancel a running query and a third one that just cancels the transaction regardless of it being idle or not. This last one is what you are implementing now, and it is what HS wants to do. pg_cancel_backend() is currently conditional on whether a statement is active or not, so should really be called pg_cancel_if_active(). What people want is an unconditional way to stop a transaction. I don't see the need for 3 modes (and that has nothing to do with HS). The JDBC driver does want cancel if active behavior. The JDBC API specifies Statement.cancel() where Statement is running one particular backend query. So it really does want to cancel just that one query. Already this is tough because of the asynchronous nature of the cancel protocol and the inability to say exactly what should be cancelled. Kris Jurka -- 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] Cancelling idle in transaction state
On Tue, 29 Dec 2009, Simon Riggs wrote: The proposal is to send an additional NOTICE to the client and abort all open transactions and subtransactions (this is what I got from the previous discussion). Would this work with JDBC driver and/or general protocol clients? A Notice would be easy to overlook. The JDBC driver wraps that as a SQLWarning which callers need to explicitly check for (and rarely do in my experience). So when they run their next statement they'll get an error saying that the current transaction is aborted, but they'll have no idea why as the warning was silently eaten. I'd prefer the transaction cancellation to come as an Error because that's what it really is. The only downside I can see is that a client would get confused if: 1) Transaction starts. 2) Idle transaction is killed and error message is given. 3) Client issues rollback 4) Client gets error message from saying the transaction was cancelled. Kris Jurka -- 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] Cancelling idle in transaction state
On Wed, 30 Dec 2009, Simon Riggs wrote: http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-ASYNC It is possible for NoticeResponse messages to be generated due to outside activity; for example, if the database administrator commands a fast database shutdown, the backend will send a NoticeResponse indicating this fact before closing the connection. Accordingly, frontends should always be prepared to accept and display NoticeResponse messages, even when the connection is nominally idle. The problem is that frontends won't check the backend connection until they've already been given the next command to execute at which point it's too late. I think a lot of the discussion on this thread is wishful thinking about when a frontend will see the message and what they'll do with it. You would either need a multithreaded frontend that had some type of callback mechanism for these notices, or you'd need to poll the socket every so often to see if you'd received a notice. I don't think that describes most applications or client libraries. Can JDBC accept a NOTICE, yet throw an error? NOTICEs have a SQLState field just like ERRORs do, so you should be able to special case that. Yes, that's possible. The only downside I can see is that a client would get confused if: 1) Transaction starts. 2) Idle transaction is killed and error message is given. 3) Client issues rollback 4) Client gets error message from saying the transaction was cancelled. Are you saying that the client should send rollback and that it should generate no message? No, I'm saying if for some business logic reason the client decided it needed to rollback as it hadn't seen the error message yet. Kris Jurka -- 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] Cancelling idle in transaction state
On Wed, 30 Dec 2009, Heikki Linnakangas wrote: Could we send an asynchronous notification immediately when the transaction is cancelled, but also change the error message you get in the subsequent commands. Clients that ignore the async notification would still see a proper error message at the ERROR. +1 Kris Jurka -- 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] exec_execute_message crush
On Tue, 29 Dec 2009, Tatsuo Ishii wrote:
parse
bind
describe
execute
normaly done
parse invalid SQL thus abort a transaction
bind (error)
describe (error)
execute (crush)
Please note that without pgpool backend does not crush. This is
because JDBC driver does not do execute() if prior parse, bind
etc. failed, I think.
The JDBC driver will fire away parse, bind, and execute all at once before
a sync, to avoid network roundtrips, so your assumption of what's going on
here without pgpool doesn't seem accurate. Attached is a test case that
tries to duplicate what you've described and it errors out normally.
Below is the JDBC driver's protocol level logging.
21:41:39.407 (1) FE= Parse(stmt=S_1,query=BEGIN,oids={})
21:41:39.407 (1) FE= Bind(stmt=S_1,portal=null)
21:41:39.407 (1) FE= Execute(portal=null,limit=0)
21:41:39.408 (1) FE= Parse(stmt=null,query=SELECT $1 ,oids={23})
21:41:39.408 (1) FE= Bind(stmt=null,portal=null,$1='1')
21:41:39.408 (1) FE= Describe(portal=null)
21:41:39.408 (1) FE= Execute(portal=null,limit=0)
21:41:39.408 (1) FE= Parse(stmt=null,query= SELECT SELECT $1
,oids={23})
21:41:39.408 (1) FE= Bind(stmt=null,portal=null,$1='2')
21:41:39.409 (1) FE= Describe(portal=null)
21:41:39.409 (1) FE= Execute(portal=null,limit=0)
21:41:39.409 (1) FE= Sync
21:41:39.443 (1) =BE ParseComplete [S_1]
21:41:39.443 (1) =BE BindComplete [null]
21:41:39.443 (1) =BE CommandStatus(BEGIN)
21:41:39.443 (1) =BE ParseComplete [null]
21:41:39.443 (1) =BE BindComplete [null]
21:41:39.444 (1) =BE RowDescription(1)
21:41:39.444 (1) =BE DataRow
21:41:39.444 (1) =BE CommandStatus(SELECT)
21:41:39.454 (1) =BE ErrorMessage(ERROR: syntax error at or near
SELECT
Position: 9)
So this shows everything working as expected. Perhaps enabling this
logging on your JDBC client would show more clearly what it is trying to
do.
Kris Jurkaimport java.sql.*;
public class Crash {
public static void main(String args[]) throws Exception {
Class.forName(org.postgresql.Driver);
Connection conn =
DriverManager.getConnection(jdbc:postgresql://localhost:5844/jurka?loglevel=2,jurka,);
conn.setAutoCommit(false);
PreparedStatement pstmt = conn.prepareStatement(SELECT ? ;
SELECT SELECT ? );
pstmt.setInt(1, 1);
pstmt.setInt(2, 2);
pstmt.execute();
}
}
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Hot Standy introduced problem with query cancel behavior
The JDBC driver's regression test suite has revealed a change in behavior
introduced by the hot standy patch. Previously when a client sent a
cancel request on an idle connection, nothing happened. Now it sends an
error message ERROR: canceling statement due to user request. This
confuses the driver's protocol handling and it thinks that the error
message is for the next statement issued.
Attached is a test case.
Kris Jurka
import java.sql.*;
public class Cancel {
public static void main(String args[]) throws Exception {
Class.forName(org.postgresql.Driver);
Connection conn =
DriverManager.getConnection(jdbc:postgresql://localhost:5851/jurka, jurka,
);
Statement stmt = conn.createStatement();
stmt.cancel();
ResultSet rs = stmt.executeQuery(SELECT 1);
}
}
--
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] [COMMITTERS] pgsql: /home/peter/commit-msg
On Fri, 20 Nov 2009, Magnus Hagander wrote: I've cleaned up the git repo, and re-enabled the mirror script. From what I can tell it works fine. In theory you will need to use force mode if you pulled the broken commit that was removed (the one with the wrong message), but it seems this is not necessarily required. Just to clarify here, what was the point of stopping the sync script? Unless the sync was stopped prior to the modified commit there's no difference for an end user here. If they pulled the modified commit they've got a semi-broken repo. All that's happened is that they weren't able to pull newer updates as well which seems like a net loss. Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] byteain for new hex escaped data
Looking at how byteain detects whether the input it is passed is the new hex format escape or the old octal escape, it uses: char *inputText = PG_GETARG_CSTRING(0); if (inputText[0] == '\\' inputText[1] == 'x') Doesn't this read off the end of inputText in the case of SELECT ''::bytea, or is there some padding happening somewhere that makes this legal? Kris Jurka -- 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] Parsing config files in a directory
On Mon, 26 Oct 2009, Greg Stark wrote: Actually I think the include directory came from another use case which we've also discussed. Namely modules which need some configuration themselves. So for example when you install PostGIS it could drop a postgis.conf in the directory which you could then either edit yourself or override with SET PERSISTENT. For modules that want to touch custom_variable_classes, they would still need to touch the global config. While there was some discussion about the ability to append/prepend/filter search_path, is there something simpler (because order doesn't matter) we can do for custom_variable_classes? Kris Jurka -- 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] Client application name
On Tue, 13 Oct 2009, Dave Page wrote: A useful feature found in other DBMSs such as MS SQL Server that has been requested on these lists a few times, is the ability for a client application to report its name to the server. This information may then be presented in logs, activity reports and so on to aid debugging and help the sysadmin/DBA see easily what activity is coming from where on their server. As a point of reference the JDBC API specifies the following which allows multiple properties that are similar to the desired request which are useful in a multi-tier application. http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#setClientInfo(java.lang.String,%20java.lang.String) Kris Jurka -- 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 port number handling
On Thu, 24 Sep 2009, Tom Lane wrote: Sam Mason s...@samason.me.uk writes: + if (portnum 1 || portnum 65535) BTW, it strikes me that we could tighten this even more by rejecting target ports below 1024. Restricting the target port seems like a bad idea. What about a firewall (or ssh tunnel) that did port forwarding. What PG binds to and what a client connects to may not be the same thing. Kris Jurka -- 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] gettext version problem exposed by buildfarm failures on canary
Tom Lane wrote: I see buildfarm member canary (NetBSD 1.6) was recently resurrected, but is failing to build HEAD, because msgfmt fails like this: po/es.po:8039: keyword msgid_plural unknown po/es.po:8036: missing `msgstr' section po/es.po:8039: parse error This indicates (1) canary needs a newer version of gettext, and (2) our configure test for a sufficiently new gettext installation is not in fact correct, because it didn't complain. NetBSD has an odd mix of a BSD libintl and GNU msgfmt, so the library provides both ngettext and bind_textdomain_codeset, but that has no implications about what msgfmt supports. pgf...@netbsd:~$ msgfmt --version msgfmt (GNU gettext) 0.10.35 Also, the man page for libintl says, bind_textdomain_codeset() does not work at this moment (always fail). So perhaps this platform is just a lost cause. -- 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] gettext version problem exposed by buildfarm failures on canary
Tom Lane wrote: What I'd suggest Kris do is temporarily disable the NLS option on that build, so we can get at least some useful testing from the machine. After a proposed configure fix has been installed, re-enable NLS, verify configure fails as expected, *then* upgrade msgfmt. I disabled NLS, got a clean test run, and have now re-enabled nls so that people can test things if they care. Kris Jurka -- 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] It's June 1; do you know where your release is?
On Mon, 1 Jun 2009, Robert Haas wrote: Regarding this item: * Consider reverting preventing regular users from base type creation You raise this point: tgl says: whether or not we think PL/Java is bulletproof, there are other problems, for instance this one http://archives.postgresql.org/message-id/87zlnwnvjg@news-spur.riddles.org.uk That's a pretty overwhelming argument for leaving it as-is. I think we should remove this from the list of open items. Yes, that makes sense to me as the original requester of this open item. I thought it had been taken off a while ago. Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [Pljava-dev] [HACKERS] Re: Should creating a new base type require superuser status?
On Wed, 18 Feb 2009, Kris Jurka wrote: I have reviewed pljava's handling of misrepresented alignment, length, and by value parameters [and it doesn't all work.] I have fixed pljava to now correctly handle all of these being defined incorrectly. So a trusted language can be used to create type input and output functions safely. I think the restriction that only superusers can create types should be reverted. Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [Pljava-dev] [HACKERS] Re: Should creating a new base type require superuser status?
On Sat, 2 Aug 2008, Tom Lane wrote: So what exactly does happen when the user deliberately specifies wrong typlen/typbyval/typalign info when creating a type based on PL/Java functions? I have reviewed pljava's handling of misrepresented alignment, length, and by value parameters 1) Alignment: pljava reads and writes data a byte at a time, so all types effectively have char alignment. Reading an integer will read four bytes out of memory and then put those together. Therefore the alignment cannot be misspecified. 2) Length: For fixed length types, pljava correctly detects trying to read or write too much data and not supplying enough data on write. Pljava does not correctly handle variable length types. It should be setting and reading the length header itself rather than leaving that up to the user, but it is not. 3) By value: pljava does not correctly handle passed by value types correctly, allowing access to random memory. So yes, pljava has a security problem, but I still object to the statement that no PL can do this securely. I will work on fixing pljava, but I request the change for superuser requirement for type creation be reverted. The fact that no PL currently does it correctly is not a reason to prohibit a PL from doing it correctly. Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [Pljava-dev] [HACKERS] Re: Should creating a new base type require superuser status?
Thomas Hallgren wrote:
Kris Jurka wrote:
3) By value: pljava does not correctly handle passed by value types
correctly, allowing access to random memory.
This is simply not true. There's no way a Java developer can access
random memory through PL/Java.
No, the point is that the Java developer can provide some data which can
convince postgresql to fetch random data for the user.
Consider the attached type which is simply an int4 equivalent.
Depending on how you define it as passed by value or passed by reference
it will or will not work (attached).
This looks like it works:
jurka=# select '1'::intbyref, '2'::intbyval;
intbyref | intbyval
--+--
1| 2
(1 row)
But it doesn't really:
jurka=# create table inttest (a intbyref, b intbyval);
CREATE TABLE
jurka=# insert into inttest values ('1', '2');
INSERT 0 1
jurka=# select * from inttest;
a | b
---+
1 | 2139062143
(1 row)
You can also get:
jurka=# select * from inttest;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Kris Jurka
package types;
import java.io.IOException;
import java.sql.SQLData;
import java.sql.SQLException;
import java.sql.SQLInput;
import java.sql.SQLOutput;
import java.util.logging.Logger;
public class Int implements SQLData
{
private static Logger s_logger = Logger.getAnonymousLogger();
private int m_i;
private String m_typeName;
public static Int parse(String input, String typeName) throws SQLException
{
try
{
int i = Integer.parseInt(input);
return new Int(i, typeName);
}
catch(NumberFormatException e)
{
throw new SQLException(e.getMessage());
}
}
public Int()
{
}
public Int(int i, String typeName)
{
m_i = i;
m_typeName = typeName;
}
public String getSQLTypeName()
{
return m_typeName;
}
public void readSQL(SQLInput stream, String typeName) throws SQLException
{
s_logger.info(typeName + from SQLInput);
m_i = stream.readInt();
m_typeName = typeName;
}
public void writeSQL(SQLOutput stream) throws SQLException
{
s_logger.info(m_typeName + to SQLOutput);
stream.writeInt(m_i);
}
public String toString()
{
s_logger.info(m_typeName + toString);
return Integer.toString(m_i);
}
}
CREATE TYPE intbyval;
CREATE FUNCTION intbyval_in(cstring)
RETURNS intbyval
AS 'UDT[types.Int] input'
LANGUAGE java IMMUTABLE STRICT;
CREATE FUNCTION intbyval_out(intbyval)
RETURNS cstring
AS 'UDT[types.Int] output'
LANGUAGE java IMMUTABLE STRICT;
CREATE FUNCTION intbyval_recv(internal)
RETURNS intbyval
AS 'UDT[types.Int] receive'
LANGUAGE java IMMUTABLE STRICT;
CREATE FUNCTION intbyval_send(intbyval)
RETURNS bytea
AS 'UDT[types.Int] send'
LANGUAGE java IMMUTABLE STRICT;
CREATE TYPE intbyval (
internallength = 4,
input = intbyval_in,
output = intbyval_out,
receive = intbyval_recv,
send = intbyval_send,
passedbyvalue
);
CREATE TYPE intbyref;
CREATE FUNCTION intbyref_in(cstring)
RETURNS intbyref
AS 'UDT[types.Int] input'
LANGUAGE java IMMUTABLE STRICT;
CREATE FUNCTION intbyref_out(intbyref)
RETURNS cstring
AS 'UDT[types.Int] output'
LANGUAGE java IMMUTABLE STRICT;
CREATE FUNCTION intbyref_recv(internal)
RETURNS intbyref
AS 'UDT[types.Int] receive'
LANGUAGE java IMMUTABLE STRICT;
CREATE FUNCTION intbyref_send(intbyref)
RETURNS bytea
AS 'UDT[types.Int] send'
LANGUAGE java IMMUTABLE STRICT;
CREATE TYPE intbyref (
internallength = 4,
input = intbyref_in,
output = intbyref_out,
receive = intbyref_recv,
send = intbyref_send
);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: pgsql: Properly unregister OpenSSL callbacks when libpq is done with
Magnus Hagander wrote: Log Message: --- Properly unregister OpenSSL callbacks when libpq is done with it's connection. This is required for applications that unload the libpq library (such as PHP) in which case we'd otherwise have pointers to these functions when they no longer exist. Breaks the build with --enable-thread-safety and --with-openssl because of this typo. Kris Jurka *** a/src/interfaces/libpq/fe-secure.c --- b/src/interfaces/libpq/fe-secure.c *** *** 918,925 destroy_ssl_system(void) * This means we leak a little memory on repeated load/unload * of the library. */ ! free(pqlockarray); ! pqlockarray = NULL; } } --- 918,925 * This means we leak a little memory on repeated load/unload * of the library. */ ! free(pq_lockarray); ! pq_lockarray = NULL; } } -- 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] What's going on with pgfoundry?
On Wed, 26 Nov 2008, Dave Page wrote: It's the same IP address - but try port 35 for ssh. Marc changed it (temporarily) due to a vast number of malicious connection attempts. Why wasn't this change communicated to anyone, not even gforge-admins? How temporary is temporary? Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] don't use MAKE_PTR/OFFSET for shmem pointers
Since we require every process to map the shared memory region to the same
address, we don't need the MAKE_PTR/OFFSET code that was needed when that
was not the case. This patch makes shared memory pointers just like
regular pointers.
http://archives.postgresql.org/pgsql-general/2007-08/msg01510.php
Kris Jurka*** a/src/backend/access/transam/twophase.c
--- b/src/backend/access/transam/twophase.c
***
*** 122,128 typedef struct GlobalTransactionData
typedef struct TwoPhaseStateData
{
/* Head of linked list of free GlobalTransactionData structs */
! SHMEM_OFFSET freeGXacts;
/* Number of valid prepXacts entries. */
int numPrepXacts;
--- 122,128
typedef struct TwoPhaseStateData
{
/* Head of linked list of free GlobalTransactionData structs */
! void * freeGXacts;
/* Number of valid prepXacts entries. */
int numPrepXacts;
***
*** 184,190 TwoPhaseShmemInit(void)
int i;
Assert(!found);
! TwoPhaseState-freeGXacts = INVALID_OFFSET;
TwoPhaseState-numPrepXacts = 0;
/*
--- 184,190
int i;
Assert(!found);
! TwoPhaseState-freeGXacts = NULL;
TwoPhaseState-numPrepXacts = 0;
/*
***
*** 197,203 TwoPhaseShmemInit(void)
for (i = 0; i max_prepared_xacts; i++)
{
gxacts[i].proc.links.next = TwoPhaseState-freeGXacts;
! TwoPhaseState-freeGXacts = MAKE_OFFSET(gxacts[i]);
}
}
else
--- 197,203
for (i = 0; i max_prepared_xacts; i++)
{
gxacts[i].proc.links.next = TwoPhaseState-freeGXacts;
! TwoPhaseState-freeGXacts = gxacts[i];
}
}
else
***
*** 243,249 MarkAsPreparing(TransactionId xid, const char *gid,
TwoPhaseState-prepXacts[i] =
TwoPhaseState-prepXacts[TwoPhaseState-numPrepXacts];
/* and put it back in the freelist */
gxact-proc.links.next = TwoPhaseState-freeGXacts;
! TwoPhaseState-freeGXacts = MAKE_OFFSET(gxact);
/* Back up index count too, so we don't miss scanning
one */
i--;
}
--- 243,249
TwoPhaseState-prepXacts[i] =
TwoPhaseState-prepXacts[TwoPhaseState-numPrepXacts];
/* and put it back in the freelist */
gxact-proc.links.next = TwoPhaseState-freeGXacts;
! TwoPhaseState-freeGXacts = gxact;
/* Back up index count too, so we don't miss scanning
one */
i--;
}
***
*** 263,275 MarkAsPreparing(TransactionId xid, const char *gid,
}
/* Get a free gxact from the freelist */
! if (TwoPhaseState-freeGXacts == INVALID_OFFSET)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg(maximum number of prepared
transactions reached),
errhint(Increase max_prepared_transactions
(currently %d).,
max_prepared_xacts)));
! gxact = (GlobalTransaction) MAKE_PTR(TwoPhaseState-freeGXacts);
TwoPhaseState-freeGXacts = gxact-proc.links.next;
/* Initialize it */
--- 263,275
}
/* Get a free gxact from the freelist */
! if (TwoPhaseState-freeGXacts == NULL)
ereport(ERROR,
(errcode(ERRCODE_OUT_OF_MEMORY),
errmsg(maximum number of prepared
transactions reached),
errhint(Increase max_prepared_transactions
(currently %d).,
max_prepared_xacts)));
! gxact = (GlobalTransaction)TwoPhaseState-freeGXacts;
TwoPhaseState-freeGXacts = gxact-proc.links.next;
/* Initialize it */
***
*** 452,458 RemoveGXact(GlobalTransaction gxact)
/* and put it back in the freelist */
gxact-proc.links.next = TwoPhaseState-freeGXacts;
! TwoPhaseState-freeGXacts = MAKE_OFFSET(gxact);
LWLockRelease(TwoPhaseStateLock);
--- 452,458
/* and put it back in the freelist */
gxact-proc.links.next = TwoPhaseState-freeGXacts;
! TwoPhaseState-freeGXacts = gxact;
LWLockRelease(TwoPhaseStateLock
Re: [HACKERS] Any reason to have heap_(de)formtuple?
On Tue, 28 Oct 2008, Zdenek Kotala wrote:
Kris Jurka napsal(a):
Here's a patch that changes everything over to the the new API and
implements the old API by calling the new API.
It seems to me OK. I have only one comment. I prefer to pfree allocated
memory for temporary nulls array. I think that caller could call old API
many times without memory context cleanup.
Here's an incremental patch to add the suggested pfreeing.
Kris Jurka*** a/src/backend/access/common/heaptuple.c
--- b/src/backend/access/common/heaptuple.c
***
*** 801,806 heap_formtuple(TupleDesc tupleDescriptor,
--- 801,808
tuple = heap_form_tuple(tupleDescriptor, values, boolNulls);
+ pfree(boolNulls);
+
return tuple;
}
***
*** 894,899 heap_modifytuple(HeapTuple tuple,
--- 896,902
{
int numberOfAttributes = tupleDesc-natts;
int attnum;
+ HeapTuple result;
bool *replNulls = (bool *) palloc(numberOfAttributes *
sizeof(bool));
bool *replActions = (bool *) palloc(numberOfAttributes *
sizeof(bool));
***
*** 903,909 heap_modifytuple(HeapTuple tuple,
replActions[attnum] = replCharActions[attnum] == 'r';
}
! return heap_modify_tuple(tuple, tupleDesc, replValues, replNulls,
replActions);
}
/*
--- 906,917
replActions[attnum] = replCharActions[attnum] == 'r';
}
! result = heap_modify_tuple(tuple, tupleDesc, replValues, replNulls,
replActions);
!
! pfree(replNulls);
! pfree(replActions);
!
! return result;
}
/*
***
*** 1051,1056 heap_deformtuple(HeapTuple tuple,
--- 1059,1066
charNulls[attnum] = boolNulls[attnum] ? 'n' : ' ';
}
+ pfree(boolNulls);
+
}
/*
--
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] Any reason to have heap_(de)formtuple?
On Thu, 23 Oct 2008, Kris Jurka wrote: The problem with trying to deprecate it is that the vast majority of the backend is still using the old interfaces, so people looking for inspiration for their external modules will likely end up using the old interface. Like Alvaro I started this conversion a while ago, got bored, and forgot about it. If people do want this conversion done while keeping the old interface around, I can track down that patch, update it and finish it up for the next CommitFest. Here's a patch that changes everything over to the the new API and implements the old API by calling the new API. Kris Jurka use-new-heaptuple-api.patch.gz 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] Any reason to have heap_(de)formtuple?
On Thu, 23 Oct 2008, Tom Lane wrote: Well, aside from the gruntwork needed to convert all the core code that still uses the old APIs, there's the prospect of breaking extension modules that still use the old APIs. It's kind of annoying to have two copies of that code, but less annoying than removing it would be ... The problem with trying to deprecate it is that the vast majority of the backend is still using the old interfaces, so people looking for inspiration for their external modules will likely end up using the old interface. Like Alvaro I started this conversion a while ago, got bored, and forgot about it. If people do want this conversion done while keeping the old interface around, I can track down that patch, update it and finish it up for the next CommitFest. Kris Jurka -- 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] There's some sort of race condition with the new FSM stuff
On Mon, 13 Oct 2008, Tom Lane wrote: I notice now that kudu and dragonfly are actually the same machine ... could this be an OS-specific problem? Kris, has there been any system-software change on that machine recently? This is a VM that I haven't touched in some time. It was turned off after a host kernel upgrade no longer allowed vmware to work on it. I recently turned it back on after switching from vmware workstation 5.5 to vmware server 2.0. On the VM itself the only change I've made was to switch the timezone from Mountain to Pacific. http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=dragonflybr=HEAD Kris Jurka -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Fixes for psql describeOneTableDetails
Attached are two and a half fixes for problems in psql's describeOneTableDetails function. 1) After PQclear(res) we must null res out, so that later error handling cleanup doesn't try to PQclear it again. 2) In error cleanup we cannot call printTableCleanup unless we've called printTableInit. 3) When describing a sequence it queries the sequence by name and was not schema qualifying it which is necessary when describing objects not in the search path. This is still busted because it does not correctly quote the identifiers. Kris JurkaIndex: src/bin/psql/describe.c === RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v retrieving revision 1.185 diff -c -r1.185 describe.c *** src/bin/psql/describe.c 23 Sep 2008 09:20:38 - 1.185 --- src/bin/psql/describe.c 8 Oct 2008 23:28:48 - *** *** 826,831 --- 826,832 PGresult *res = NULL; printTableOpt myopt = pset.popt.topt; printTableContent cont; + bool printTableInitialized = false; int i; char *view_def = NULL; char *headers[6]; *** *** 887,892 --- 888,894 tableinfo.tablespace = (pset.sversion = 8) ? atooid(PQgetvalue(res, 0, 6)) : 0; PQclear(res); + res = NULL; /* * This is used to get the values of a sequence and store it in an *** *** 902,909 start_value, increment_by, \n max_value, min_value, cache_value, \n log_cnt, is_cycled, is_called \n ! FROM \%s\, ! relationname); result = PSQLexec(buf.data, false); if (!result) --- 904,911 start_value, increment_by, \n max_value, min_value, cache_value, \n log_cnt, is_cycled, is_called \n ! FROM \%s\.\%s\, ! schemaname, relationname); result = PSQLexec(buf.data, false); if (!result) *** *** 1000,1005 --- 1002,1008 } printTableInit(cont, myopt, title.data, cols, numrows); + printTableInitialized = true; for (i = 0; i cols; i++) printTableAddHeader(cont, headers[i], true, 'l'); *** *** 1593,1599 error_return: /* clean up */ ! printTableCleanup(cont); termPQExpBuffer(buf); termPQExpBuffer(title); termPQExpBuffer(tmpbuf); --- 1596,1603 error_return: /* clean up */ ! if (printTableInitialized) ! printTableCleanup(cont); termPQExpBuffer(buf); termPQExpBuffer(title); termPQExpBuffer(tmpbuf); -- 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 creating a new base type require superuser status?
On Wed, 30 Jul 2008, Alvaro Herrera wrote: I think being able to return cstring from a user defined function is quite dangerous already. I doubt we would ever give that capability to non-superusers. I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). pl/java already allows non-superusers to create functions returning cstring and base types built off of these functions. It seems safe to me if pl/java is doing the construction of cstring from a user provided java.lang.String. http://wiki.tada.se/display/pljava/Creating+a+Scalar+UDT+in+Java Kris Jurka -- 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] sh - pl
On Tue, 17 Jun 2008, Alvaro Herrera wrote: Maybe, or maybe not. Do these platforms all have Perl? Of course. They're all buildfarm clients and the buildfarm script is perl. Kris Jurka -- 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] Options for protocol level cursors
On Fri, 13 Jun 2008, James William Pye wrote: My thoughts for creating a HOLD and/or SCROLL cursor on Bind would be to add YA GUC stating the cursor options for Bind cursors. Something along the lines of default_bind_options=HOLD,SCROLL. 2. I'm the only one asking/looking for it. (I'm so lonely ;) The JDBC driver would also like this ability, but a GUC is a pretty ugly hack. Also, since you still have to go to the SQL level to issue the MOVE or FETCH BACKWARD, you're still not all the way there to a full protocol solution. Kris Jurka -- 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] Protection from SQL injection
On Tue, 29 Apr 2008, Josh Berkus wrote: Did you guys miss Tom's comment up-thread? Postgres already does this if you use PQExecParams(). Keen. Now we just need to get the driver developers to implement it. I imagine Java does. The JDBC driver takes a multi-command statement and splits it up to be able to use the extended query protocol. So the JDBC driver is actually doing the reverse of your suggestion. For us it was a decision to ease the transition from V2 to V3 protocol and not break code that used to work. Kris Jurka -- 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] [Pljava-dev] stack depth limit exceeded - patch possible?
On Mon, 14 Apr 2008, Alexander Wöhrer wrote: am I understanding this correctly that pl/java sets it for the main Java thread, so other threads spawned by this main thread and using postgres SPI functionality will run into stack_depth_problems? pljava sets the stack_base_ptr for each thread just before it calls into the backend using SPI and resets it when that thread finishes using SPI. Only one thread can access the backend at a time, so multi-threaded pljava code is safe and this mangling of the stack_base_ptr keeps the backend happy. Can you suggest another workaround? Are you having any actual problems or is this all theoretical? I don't believe you should be having any issues, but if you're having a real problem, please post a self-contained test case so we can look into it. Kris Jurka -- 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] [Pljava-dev] stack depth limit exceeded - patch possible?
On Sat, 12 Apr 2008, Alexander W?hrer wrote: I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed successfully my application (doing some external Web service calling) inside PostGre 8.3.0. Unfortunatelly, the application needs at least 3 Threads and will run for quite some time. I found this comment http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html by Thomas Hallgren where he mentioned that PostGre only defines one stack and therefor pl/java has no way of telling PostGre about multiple thread stack pointers. My question is now if there is a patched version available of PostGre 8.3.0 having this stack_depth check disabled? This was fixed in postgresql/pljava shortly after the referenced discussion. As requested, postgresql 8.1+ allows modification of stack_base_ptr so pljava can set it as desired. Kris Jurka -- 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] Need -fwrapv or -fno-strict-overflow for gcc-4.3
On Mon, 10 Mar 2008, Tom Lane wrote: I am wondering if these checks have been no-ops in Postgres builds done with gcc 4.1 and up, and we're only just now being told about it. Since gcc 4.2 supports -Wstrict-overflow, I rebuilt pg with that to see what it's doing currently. I'm not sure what -Wstrict-overflow level -Wall implies with gcc 4.3, but I cranked it up to 5 on 4.2 to get the most details out of it. I don't see any of the warnings I saw on 4.3 and I get the attached list which looks less dangerous spot checking a couple items, but I haven't gone through the whole list. Additionally the comments in the blog posting[1] I linked to previously, a user asks, how come I don't see any warnings with -Wstrict-overflow on gcc 4.2.3 and it's answered I think the full effects only come in on gcc mainline. At least, gcc 4.2 does not eliminate the loop, but gcc 4.3 will. So clearly 4.3 is doing something new here, but that doesn't prove we're safe on previous versions. [1] http://www.airs.com/blog/archives/120 Kris Jurka exec.c:245: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 exec.c:245: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 localtime.c:322: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 localtime.c:814: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 pgtz.c:480: warning: assuming signed overflow does not occur when distributing negation across division pgtz.c:492: warning: assuming signed overflow does not occur when distributing negation across division pgtz.c:503: warning: assuming signed overflow does not occur when distributing negation across division zic.c:862: warning: assuming signed overflow does not occur when simplifying conditional to constant heaptuple.c:1018: warning: assuming signed overflow does not occur when simplifying / or % to or heaptuple.c:1845: warning: assuming signed overflow does not occur when simplifying / or % to or heaptuple.c:907: warning: assuming signed overflow does not occur when simplifying / or % to or gram.y:9471: warning: assuming signed overflow does not occur when simplifying conditional to constant gistutil.c:185: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 gistutil.c:307: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 gistutil.c:417: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 parse_node.c:70: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 copy.c:2613: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 gistsplit.c:494: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 tuptoaster.c:1017: warning: assuming signed overflow does not occur when simplifying / or % to or tuptoaster.c:590: warning: assuming signed overflow does not occur when simplifying / or % to or nbtutils.c:74: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 freespace.c:1567: warning: assuming signed overflow does not occur when simplifying division freespace.c:1568: warning: assuming signed overflow does not occur when simplifying division freespace.c:1637: warning: assuming signed overflow does not occur when simplifying division freespace.c:1638: warning: assuming signed overflow does not occur when simplifying division arrayfuncs.c:2837: warning: assuming signed overflow does not occur when simplifying / or % to or arrayfuncs.c:2701: warning: assuming signed overflow does not occur when simplifying / or % to or dict.c:63: warning: assuming signed overflow does not occur when simplifying multiplication arrayfuncs.c:314: warning: assuming signed overflow does not occur when simplifying / or % to or cash.c:312: warning: assuming signed overflow does not occur when negating a division spell.c:1181: warning: assuming signed overflow does not occur when simplifying multiplication deadlock.c:790: warning: assuming signed overflow does not occur when simplifying conditional to constant spell.c:1119: warning: assuming signed overflow does not occur when simplifying conditional to constant s_lock.c:150: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 s_lock.c:155: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 datetime.c:2072: warning: assuming signed overflow does not occur when simplifying conditional to constant format_type.c:408: warning: assuming signed overflow does not occur when simplifying / or % to or int.c:1130: warning: assuming signed overflow does not occur when simplifying
[HACKERS] Need -fwrapv or -fno-strict-overflow for gcc-4.3
A while back Tom Lane presented the potential problem with gcc signed overflow handling, but now it's not just a theoretical problem. http://archives.postgresql.org/pgsql-hackers/2005-12/msg00635.php Gcc 4.3 has started to perform optimizations based on the denial of the existence of signed overflow. Building CVS HEAD with gcc 4.3rc2 I get the following warnings: localtime.c:1223: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false localtime.c:1227: warning: assuming signed overflow does not occur when assuming that (X - c) X is always false array_userfuncs.c:100: warning: assuming signed overflow does not occur when assuming that (X - c) X is always false float.c:2696: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false float.c:2712: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false oracle_compat.c:1479: warning: assuming signed overflow does not occur when assuming that (X + c) X is always false I don't understand the difference between -fwrapv and -fno-strict-aliasing, but it seems we need at least one of them. http://www.airs.com/blog/archives/120 Kris Jurka -- 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] NetBSD/dtime_t
On Fri, 15 Feb 2008, Michael Meskes wrote: Could anyone please tell me how NetBSD defines dtime_t? We have a buildfarm failure on canary. /usr/include/sys/types.h says: typedef int32_t dtime_t;/* on-disk time_t */ Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GSSAPI and V2 protocol
On Tue, 5 Feb 2008, Tom Lane wrote: The problem seems to be that AuthenticationGSSContinue messages carry a variable-length payload, and the V2 protocol doesn't really cope with that because it doesn't have a message length word. 1. If the GSSContinue payload is self-identifying about its length, qwe could teach fe-connect.c how to determine that. The GSS data is supposed to be opaque to the caller, so this doesn't seem likely or a good idea. 2. We could retroactively redefine the contents of AuthenticationGSSContinue as carrying a length word after the authentication type code, but only in V2 protocol (so as not to break existing working cases). This is pretty ugly but certainly possible. I see no harm in doing this. What's there now can't work and the change is self contained. Is there any problem with the password message taking a String datatype instead of Byte[n] with a null byte? Kris Jurka ---(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: [HACKERS] GSSAPI and V2 protocol
On Tue, 5 Feb 2008, Magnus Hagander wrote: On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Honestly - don't know :-) Never looked at that part. I mean, the V2 protocol is *really* old by now, isn't it? Do you actually need it for something? The JDBC driver exposes an option to connect via either protocol version. I was looking at adding GSSAPI support and it seemed orthogonal to the protocol version used, but I couldn't get it working under V2. People still use the V2 protocol to connect because it uses string interpolation for ? in prepared statements while V3 passes them out of line. So for apps that do things like SELECT timestamp ? that will only work under V2. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GSSAPI and V2 protocol
On Tue, 5 Feb 2008, Magnus Hagander wrote: Does this mean you have GSSAPI auth working for protocol v3? :-) Yes, but since I'm not terribly familiar with GSSAPI or JAAS, I'm not sure what configuration options need to get exposed to the user. http://archives.postgresql.org/pgsql-jdbc/2008-01/threads.php#00144 Kris Jurka ---(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
[HACKERS] GSSAPI and V2 protocol
Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Pl/Java broken since Postgresql 8.3-rc1
On Mon, 14 Jan 2008, Josh Berkus wrote: Juergen, Is a pljava.dll for version 8.2.6 out? It's very important for me, need it for my office. Try e-mailing pgsql-jdbc mailing list and asking there. The correct list is actually [EMAIL PROTECTED] The JDBC driver and the server side language have little in common. I've put up a new pljava build against 8.2.6 for windows here: http://www.ejurka.com/pgsql/pljava/826/ In this case you need the new pljava.jar as well as the .dll because it's had some updates since the previous release as well. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Make pg_dump suppress COMMENT ON SCHEMA public ?
On Sun, 13 Jan 2008, Magnus Hagander wrote: Could we dump it when it's non-default only? That way the people that *have* set a custom comment on it will still get it restored, just a failure in this case. The majority of people who *haven't* set a comment will not have the problem at all. The easiest thing to do would be to drop the default comment. Then only custom comments would be dumped at all (at least for 8.3+ dbs). It's not like Standard public schema is particularly enlightening. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Pl/Java broken since Postgresql 8.3-rc1
On Thu, 10 Jan 2008, Jan Ischebeck wrote: 8.3beta3 and 4 have worked perfectly with the provided pljava ddl, just with 8.3-rc1 it doesn't work anymore. 8.3RC1 changed the function definition for SetUserId, so it pljava needs some changes and a rebuild. Will fix. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Pl/Java broken since Postgresql 8.3-rc1
On Thu, 10 Jan 2008, Kris Jurka wrote: On Thu, 10 Jan 2008, Jan Ischebeck wrote: 8.3beta3 and 4 have worked perfectly with the provided pljava ddl, just with 8.3-rc1 it doesn't work anymore. 8.3RC1 changed the function definition for SetUserId, so pljava needs some changes and a rebuild. Will fix. Turns out it's not just 83RC1, but all of the security releases, which will require different pljava packages for the patch versions before/after the security changes. I've committed a fix to CVS for this, and I guess I'll try to respin those this weekend and try to convince the windows installer folks to include them in the next point release. For the moment you can pull the pljava.dll from here and it should work for you. http://www.ejurka.com/pgsql/pljava/83rc1/ Kris Jurka ---(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: [HACKERS] Pl/Java broken since Postgresql 8.3-rc1
On Thu, 10 Jan 2008, Tom Lane wrote: Just out of curiosity, what was pljava doing calling SetUserId? If I'd known about that I'd have thought harder about removing the function; but it's not clear to me why a PL should be doing that. pljava wants to run code as the session user when inside a security definer function. The sqlj spec has an install_jar function which installs a library of java code and has an optional deployment descriptor which can create functions against the library and tables for it to use. The install_jar function is security definer to be able to register the jar file in various sqlj tables that the calling user may not be able to write to, but it wants to create the tables and function specified in the deployement descriptor with the ownership of the user calling install_jar, not the person who initially installed pljava. Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Release Note Changes
On Mon, 10 Dec 2007, Joshua D. Drake wrote: 3. It was grunt work that should have been done with the original patch that didn't get done. Stefan picked up the ball and ran with it and produced something that will make our product more usable for the end user. Then why not list Stefan as a contributor to the original feature rather than calling it out as a separate item? Kris Jurka ---(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: [HACKERS] Is postgres.gif missing in cvs?
On Mon, 3 Dec 2007, Devrim G?ND?Z wrote: I tried to run make postgres.pdf (PostgreSQL 8.3beta4), and got this error: You need to say make postgres-US.pdf or -A4. The .gif file is coming from make's default rules. Perhaps we should provide a real target matching postgres.pdf and error out with a helpful message as this isn't the first time people have been bitten by that change. Kris Jurka ---(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: [HACKERS] compiling postgres in winxp
On Sat, 1 Dec 2007, Jaime Casanova wrote: i'm trying to compile postgres in winxp for the first time in order to try recent Magnus patch discussed here http://archives.postgresql.org/pgsql-hackers/2007-11/msg01307.php /mingw/lib/gcc/mingw32/3.4.5/../../../../include/sys/time.h:27: error: redefinition of `struct timezone' /mingw/lib/gcc/mingw32/3.4.5/../../../../include/sys/time.h:40: error: conflicting types for 'gettimeofday' .../../src/include/port.h:292: error: previous declaration of 'gettimeofday' was here Only very recently can the 8.2 release be built with recent mingw releases. Upgrade pg to the top of REL8_2_STABLE or downgrade mingw. http://archives.postgresql.org/pgsql-committers/2007-11/msg00566.php Kris Jurka ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
On Thu, 29 Nov 2007, Andrew Dunstan wrote: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I've got a 5.6.1 perl here, but it wasn't built shared, so I can't test plperl. I ran the test case Greg posted to the perl bug tracker and it doesn't fail, so unless you're concerned that your change will break 5.6, then it doesn't look like 5.6 needs a fix. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] String encoding during connection handshake
On Wed, 28 Nov 2007, [EMAIL PROTECTED] wrote: I consider this matter closed from my point of view and I have modified the JDBC driver according to my needs. Could you explain in more detail what you've done to the JDBC driver in case it is generally useful or other people have the same problem? Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [pgsql-www] [HACKERS] Time to update list of contributors
Magnus Hagander wrote: Where in the US? We generally list at least the state for ppl int he US - most often both city+state. (shows up only for people listed as major developers for the time being, which is why nobody asked for it before) Denver, CO Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Time to update list of contributors
On Tue, 27 Nov 2007, Josh Berkus wrote: Kris Jurka, Finland USA actually. Kris Jurka ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pgsql: New versions of mingw have gettimeofday(), so add an autoconf
Magnus Hagander wrote: Log Message: --- New versions of mingw have gettimeofday(), so add an autoconf test for this. Can we backport this fix? I'm trying to setup a new windows build environment and this is currently halting my progress for back branches. Kris Jurka ---(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: [HACKERS] Not *quite* there on ecpg fixes
On Thu, 4 Oct 2007, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: It's still not working. Don't have time right now to diagnose why. For now, since Michael doesn't have a windows machine to play with, I have switched brown_bat's schedule so it runs HEAD 6 times a day (not exactly every 4 hours, the intervals vary between 3 and 4 1/2 hours). I wonder if we could get trout back in the rotation, too? Both trout and eel are permanently dead due to a drive failure. I can potentially setup new animals next week, but these are gone. Kris Jurka ---(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
[HACKERS] CVS corruption/mistagging?
Looking into recent buildfarm failures on the 7.4 branch: http://www.pgbuildfarm.org/cgi-bin/show_status.pl It looks like parts of the CVS repository have been mistagged as belonging to REL7_4_STABLE or have been corrupted somehow: http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE I'm not sure what's going on here, but something has gone bad. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compiler warnings on the buildfarm
On Fri, 13 Jul 2007, Zdenek Kotala wrote: Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: So pam_message ** isn't const. Ah, thanks. I see luna_moth is giving the same warning, so it's still not const in Solaris 11 either. Is it worth working around this? It's strictly cosmetic AFAICS. The main issue in my mind would be how to determine whether to use const or not. If all Solaris releases are like this, and can be expected to stay that way, I think yes. It is defined as X/Open standard says. Not according to the link you sent earlier. My reading says that Solaris has it defined wrong and pg has it right. Kris Jurka ---(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: [HACKERS] compiler warnings on the buildfarm
On Thu, 12 Jul 2007, Tom Lane wrote:
static int pam_passwd_conv_proc(int num_msg, const struct pam_message ** msg,
struct pam_response ** resp, void *appdata_ptr);
which exactly matches what my Fedora 6 pam header file says it should
be. What is it on those Solaris machines?
struct pam_conv {
int (*conv)(int, struct pam_message **,
struct pam_response **, void *);
void *appdata_ptr; /* Application data ptr */
};
So pam_message ** isn't const.
Kris Jurka
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Weird ecpg failures on buildfarm NetBSD members
On Mon, 9 Jul 2007, Tom Lane wrote: Today's puzzler for the curious: Last night the buildfarm reported two ECPG-Check failures http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=salamanderdt=2007-07-08%2017:30:00 http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=canarydt=2007-07-08%2017:30:01 which promptly went away again. Judging by the timestamps these must have been induced by Joe's PQconnectionUsedPassword() patch and fixed by my subsequent tweaking, but how the heck did that result in an ecpg failure? I think that the cause must have had something to do with his inclusion of postgres_fe.h into libpq-fe.h, which I took out on the grounds that it was an unacceptable pollution of client code namespace. But exactly why/how did that break ecpg, and why did the failure only manifest on NetBSD machines? It turns out that this failure was caused by pulling in pg's own printf implementation to the resulting ECPG program. The failing test (dyntest.pgc) prints its output using: printf (%.*f\n, PRECISION, DOUBLEVAR); Calling printf(%.*f\n, -1, 14.7) results in 14 from pg_printf and 14.70 from NetBSD's. This would only happen on machines where we don't use the system provided printf which is why it was only seen on NetBSD although in could have been seen on mingw as well. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Why so many out-of-disk-space failures on buildfarm machines?
On Tue, 3 Jul 2007, Tom Lane wrote: I realize that a lot of these members are running on old underpowered machines with not so much disk, but is it possible that the buildfarm itself is leaking disk space? Not cleaning up log files for instance? No, the buildfarm does not leak disk space. It is possible that members are configured with --keepall, which keeps the entire directory tree if a failure occurs. That can fill up a lot of space quickly when you get a failure. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
On Mon, 4 Jun 2007, Kris Jurka wrote:
On Mon, 4 Jun 2007, Andrew Dunstan wrote:
turnip_moth is also a Solaris 9 box and doesn't seem have the same issue.
Kris, is there anything unusual installed on the box that would make it
behave like this?
Not sure what's going on here. I did a manual run of the ecpg tests and it
completed normally. This machine is quite out of date and it has a large mix
of GNU tools with the solaris ones. Since turnip_moth is maintained by Sun I
would expect it to be up to date on patches and have few non-Sun tools
installed. So it could be using a different interpreter or it could be using
a broken tool for which a patch has been released. I'll try doing a run with
the buildfarm client later today to try and reproduce this.
Running ecpg's pg_regress script with -x yields:
+ cp connect/test2.c results/connect-test2.c
+ connect/test2
+ mv results/connect-test2.c results/connect-test2.c.tmp
+ cat results/connect-test2.c.tmp
+ sed -e s,^\(#line [0-9]*\) .*/\([^/]*\),\1 \2,
+ rm results/connect-test2.c.tmp
+ [ yes = yes ]
./pg_regress: bad substitution
So it looks like it's bailing on this line:
if [ $enable_threading = yes ] [ ${i%%/*} = thread ]; then
and it doesn't like the ${i%%/*} construct. Still not sure why it happens
some places and not others.
Kris Jurka
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Selecting a constant question
On Mon, 11 Jun 2007, Larry McGhaw wrote: I think perhaps we have lost sight of the main issue: 2) libpq can properly describe the maximum internal data size of any varchar column via Pqfmod SELECT cola || colb FROM tab; 3) libpq can properly describe the maximum internal data size of any numeric constant in a SQL statement via Pqfsize SELECT 3::numeric; Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] So, why isn't *every* buildfarm member failing ecpg right now?
On Mon, 4 Jun 2007, Andrew Dunstan wrote: turnip_moth is also a Solaris 9 box and doesn't seem have the same issue. Kris, is there anything unusual installed on the box that would make it behave like this? Not sure what's going on here. I did a manual run of the ecpg tests and it completed normally. This machine is quite out of date and it has a large mix of GNU tools with the solaris ones. Since turnip_moth is maintained by Sun I would expect it to be up to date on patches and have few non-Sun tools installed. So it could be using a different interpreter or it could be using a broken tool for which a patch has been released. I'll try doing a run with the buildfarm client later today to try and reproduce this. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [JDBC] JDBC driver reports a protocol error for a CVS HEAD server
On Tue, 24 Apr 2007, Ned T. Crigler wrote: The JDBC driver does not connect successfully to a CVS HEAD server (updated as of today) when using a database set to UTF8 encoding; enabling the debug messages in the driver shows that it is sending client_encoding=UNICODE in the startup packet, but the server is reporting client_encoding=UTF8 back to the driver, causing the driver to complain: Indeed, referring to -hackers as this is a recent backend change. The backend is reporting the database encoding as the client encoding. When a connection is created with a startup packet sending client_encoding = UNICODE the server responds with a ParameterStatus message of client_encoding = server encoding. So something has gone wrong here. It's not just a UNICODE/UTF-8 problem as I see the server responding with LATIN1 with a LATIN1 database. Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Hacking on PostgreSQL via GIT
Tom Lane wrote: It shouldn't be a big problem, assuming the checkout preserves the file dates --- they'll look older than the source files and so a rebuild will happen anyway in such a checkout. Actually this is a problem with at least SVN. A svn export will create files with the original repository dates, but a svn checkout will use the current time unless you enable a config option for your local svn client. Kris Jurka ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [JDBC] problems with plan invalidation
On Thu, 29 Mar 2007, Tom Lane wrote: Kris Jurka [EMAIL PROTECTED] writes: Running the JDBC driver's regression test suite for the first time in a while I got a lot of failures that I would have to guess are related to plan invalidation work. Attached is a self contained test case and the JDBC driver's log of what protocol messages it is sending. I've committed a fix for this case --- please give it another try to see if you find any other problems. That seems to fix all of them. Thanks. Kris Jurka ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] problems with plan invalidation
Running the JDBC driver's regression test suite for the first time in a
while I got a lot of failures that I would have to guess are related to
plan invalidation work. Attached is a self contained test case and the
JDBC driver's log of what protocol messages it is sending.
The end result is:
ERROR: cache lookup failed for type 2139062143
Kris Jurka17:49:35.382 (1) PostgreSQL 8.3devel JDBC3g with SSL (build 600)
17:49:35.390 (1) Trying to establish a protocol version 3 connection to
localhost:5830
17:49:35.413 (1) FE= StartupPacket(user=jurka, database=jurka,
client_encoding=UNICODE, DateStyle=ISO)
17:49:35.417 (1) =BE AuthenticationOk
17:49:35.432 (1) =BE ParameterStatus(client_encoding = UNICODE)
17:49:35.432 (1) =BE ParameterStatus(DateStyle = ISO, MDY)
17:49:35.433 (1) =BE ParameterStatus(integer_datetimes = off)
17:49:35.433 (1) =BE ParameterStatus(is_superuser = on)
17:49:35.433 (1) =BE ParameterStatus(server_encoding = LATIN1)
17:49:35.433 (1) =BE ParameterStatus(server_version = 8.3devel)
17:49:35.433 (1) =BE ParameterStatus(session_authorization = jurka)
17:49:35.433 (1) =BE ParameterStatus(standard_conforming_strings = off)
17:49:35.433 (1) =BE ParameterStatus(TimeZone = Navajo)
17:49:35.433 (1) =BE BackendKeyData(pid=27730,ckey=216493403)
17:49:35.434 (1) =BE ReadyForQuery(I)
17:49:35.434 (1) compatible = 8.3
17:49:35.434 (1) loglevel = 2
17:49:35.434 (1) prepare threshold = 5
getConnection returning driver[className=org.postgresql.Driver,[EMAIL PROTECTED]
17:49:35.459 (1) simple execute, [EMAIL PROTECTED], maxRows=0, fetchSize=0,
flags=17
17:49:35.460 (1) FE= Parse(stmt=null,query=CREATE TEMP TABLE nulltest (a
int),oids={})
17:49:35.460 (1) FE= Bind(stmt=null,portal=null)
17:49:35.460 (1) FE= Describe(portal=null)
17:49:35.461 (1) FE= Execute(portal=null,limit=0)
17:49:35.461 (1) FE= Sync
17:49:35.482 (1) =BE ParseComplete [null]
17:49:35.482 (1) =BE BindComplete [null]
17:49:35.482 (1) =BE NoData
17:49:35.482 (1) =BE CommandStatus(CREATE TABLE)
17:49:35.483 (1) =BE ReadyForQuery(I)
17:49:35.484 (1) simple execute, [EMAIL PROTECTED], maxRows=0, fetchSize=0,
flags=21
17:49:35.484 (1) FE= Parse(stmt=null,query=INSERT INTO nulltest (a) VALUES
($1),oids={23})
17:49:35.485 (1) FE= Bind(stmt=null,portal=null,$1=NULL)
17:49:35.485 (1) FE= Describe(portal=null)
17:49:35.485 (1) FE= Execute(portal=null,limit=1)
17:49:35.485 (1) FE= Sync
17:49:35.487 (1) =BE ParseComplete [null]
17:49:35.489 (1) =BE ErrorMessage(ERROR: cache lookup failed for type
2139062143)
org.postgresql.util.PSQLException: ERROR: cache lookup failed for type
2139062143
at
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548)
at
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316)
at
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:351)
at
org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:305)
at TestSetNull.main(TestSetNull.java:16)
SQLException: SQLState(XX000)
17:49:35.491 (1) =BE ReadyForQuery(I)
import java.sql.*;
public class TestSetNull {
public static void main(String args[]) throws Exception {
Class.forName(org.postgresql.Driver);
Connection conn =
DriverManager.getConnection(jdbc:postgresql://localhost:5830/jurka?loglevel=2,jurka,);
Statement stmt = conn.createStatement();
stmt.execute(CREATE TEMP TABLE nulltest (a int));
stmt.close();
PreparedStatement ps = conn.prepareStatement(INSERT INTO
nulltest (a) VALUES (?));
ps.setNull(1, Types.INTEGER);
ps.executeUpdate();
conn.close();
}
}
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.x horology regression test on Solaris buildfarm machines
On Tue, 27 Feb 2007, Tom Lane wrote: I see that kudu and dragonfly are now failing regression in the 7.3 and 7.4 branches, as a consequence of this patch: http://archives.postgresql.org/pgsql-committers/2007-02/msg00491.php Is it reasonable to assume that that machine will soon be patched to know about the new US DST rules? If not, I suppose we could install variant horology-solaris-1947_1.out files to allow either result to succeed, but it seems a bit silly ... I'll look at an upgrade. Eel is failing as well, but surprisingly canary is not. Canary hasn't had any updates applied, so why isn't it failing as well: [EMAIL PROTECTED]:~$ zdump -v /etc/localtime | grep 2007 /etc/localtime Sun Apr 1 08:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 MST isdst=0 /etc/localtime Sun Apr 1 09:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 MDT isdst=1 /etc/localtime Sun Oct 28 07:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 MDT isdst=1 /etc/localtime Sun Oct 28 08:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 MST isdst=0 Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 7.x horology regression test on Solaris buildfarm machines
On Tue, 27 Feb 2007, Kris Jurka wrote: I'll look at an upgrade. Eel is failing as well, but surprisingly canary is not. Canary hasn't had any updates applied, so why isn't it failing as well: Shouldn't all of the buildfarm members be failing either before or after the patch? That doesn't seem to be the case for any of them. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 7.x horology regression test on Solaris buildfarm machines
On Tue, 27 Feb 2007, Tom Lane wrote: No, because for the standard regression behavior we have variant result files both with and without the DST law change: see horology and horology_1. The issue only comes up for machines that were matching to horology-no-DST-before-1970.out (which may be only old HPUX) or horology-solaris-1947.out (which I suppose is only Solaris). The reason I got around to making the patch now is I recently updated my old HPUX machine for the law change, and so 7.x started to fail for me ... OK, kudu + dragonfly updated. I probably won't get around to fixing eel (cygwin) for some time though. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 5 Weeks till feature freeze or (do you know where your patch is?)
On Tue, 27 Feb 2007, Henry B. Hotz wrote: Question: are there any corresponding deadlines for the Java client code that I need to worry about? The JDBC driver will release a new version at the same time as the server, but we don't have nearly as strict rules about feature freeze/beta. We don't need multiple months of beta so as long as the patch isn't terribly complicated we'll accept it close to the release. Kris Jurka ---(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: [HACKERS] Column storage positions
On Thu, 22 Feb 2007, Zeugswetter Andreas ADI SD wrote: And I also see a lot of unhappiness from users of system tables when column numbers all over the system tables would not be logical column positions any more. Right now the fact that attnum presents the logical order but not the logical position is a problem for the JDBC driver. In the presence of dropped columns there is no easy way to get from a pg_attribute entry to logical position. I would hope that a new logical position column would reflect the actual position and solve this problem. Kris Jurka ---(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: [HACKERS] Column storage positions
On Thu, 22 Feb 2007, Alvaro Herrera wrote: Zeugswetter Andreas ADI SD escribió: I agree, I haven't thought of drop column :-( Drop column should have relabeled attnum. Since it was not done then, my comments are probably moot. We can correct this problem now. How? If attnum is serving as both physical position and logical order, how can you make it be logical position without breaking physical position? Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal: Commit timestamp
Richard Troy wrote: It'd be great if Jan considers the blending of replication; any given DB instance shouldn't be only a master/originator or only a slave/subscriber. A solution that lets you blend replication strategies in a single db is, from my point of view, very important. Perhaps if more people read Jan's posts he wouldn't be so frustrated. http://archives.postgresql.org/pgsql-hackers/2007-01/msg01302.php He clearly describes that the master/slave setting is per session, not per database. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Referential Integrity and SHARE locks
On Sat, 3 Feb 2007, Simon Riggs wrote: There are issues, yes. Dropping PKs is a very irregular occurrence nor is it likely to be part of a complex transaction. It wouldn't bother me to say that if a transaction already holds a RowExclusiveLock or a RowShareLock it cannot upgrade to an AccessExclusiveLock. Actually, since rearranging PKs is such a drastic change I would expect them only to be part of a large complex transaction. I know for apps I work on it would be part of a single transaction script that updated whole chunks of data and schema. Kris Jurka ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] log ssl mode with connections?
On Tue, 30 Jan 2007, Andrew Dunstan wrote: If I am allowing both SSL and non-SSL I might like to know which is used by a particular connection. Other places I've heard people ask for this info: 1) pg_stat_activity to see who's currently connected and how. 2) Via a function (boolean am_i_using_ssl()) so they can make security decisions in views or procedural code. Kris Jurka ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] pg_dump exclusion switches and functions/types
Testing out the new pg_dump exclusion switches I've found that excluding a table means that no functions or types will be dumped. Excluding one table shouldn't exclude these objects. My real use case for this functionality is that I have a database that has 99% of its space used by one big table and I'd like to be able to dump the rest of the database quickly. If I lose function/type information it's useless. Kris Jurka ---(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: [HACKERS] JAVA Support
On Thu, 28 Sep 2006, Henry B. Hotz wrote: It appears that the JDBC client doesn't include the Kerberos support that the C clients do. Java doesn't have accessible Kerberos support. It wraps Kerberos in GSSAPI which requires the server to support GSSAPI instead of plain Kerberos. So, two questions: 1) Is there an alternative JDBC client that's just a glue layer instead of a complete re-implementation? No, there aren't any Type 2 drivers around. Requiring native code is a giant pain. Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] JAVA Support
On Thu, 28 Sep 2006, Henry B. Hotz wrote: I take it you're not volunteering to help with my second request. ;-) I would if we could get some -hackers buy in on the idea. Adding more and more auth methods is something they're not excited about unless there's a good reason (which I think this is). Kris Jurka ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Buildfarm alarms
On Wed, 27 Sep 2006, Andrew Dunstan wrote: The settings are in hours, so this says that if we haven't seen a HEAD build in 1 day or a stable branch build in 1 week, alert the owner by email, and keep repeating the alert in each case every 2 days. How does this know if there wasn't a build because nothing in CVS changed over that time period? Especially on the back branches it is normal to go weeks without a build. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Draft release notes
Bruce Momjian wrote: Here is an early draft of the release notes. It needs more polish and review: http://momjian.us/cgi-bin/pgrelease I will catch up on my email tomorrow, update the open items list for 8.2, and then return to the release notes for cleanup. Add support for Windows codepages 1253, 1254, 1255, and 1257 (Peter) This was actually me. http://archives.postgresql.org/pgsql-patches/2006-02/msg00039.php Kris Jurka ---(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
