Re: [HACKERS] pgindent run coming
On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote: It is time to run pgindent on CVS HEAD for 8.4. I am thinking of running it at zero-hour GMT tomorrow, meaning five hours from now. Any objections? Why don't we do this automatically after each individual commit? That way each commit would be associated directly with any required tidy-up that must occur because of it. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH 0/2] SIGPIPE masking in local socket connections, v2
A new approach to avioding manipulating the signal mask during for every
send - this time round, use SO_NOSIGPIPE and MSG_NOSIGNAL if available.
The patches have been tested on Linux and OSX, and I've confirmed that
'struct foo { };' will compile with a MSVC compiler. I'd still like a
little more testing though, is there a machine that allows both
SO_NOSIGPIPE and MSG_NOSIGNAL?
Again, comments most welcome,
Jeremy
---
Jeremy Kerr (2):
[libpq] rework sigpipe-handling macros
[libpq] Try to avoid manually masking SIGPIPEs on every 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] [PATCH 1/2] [libpq] rework sigpipe-handling macros
Currently, the sigpipe-masking code in libpq is implemented as
a set of macros, which depend on declaring local variables.
This change adds a (private) struct sigpipe_info to contain the
compile-dependent data required for sigpipe masking and restoring.
The caller can then declare a struct sigpipe info explicitly, and
pass this to the subsequent sigpipe-masking code.
This allows us to separate the variable declarations from the code,
and gives the caller more flexibility for controlling the scope of
these variables.
Also, since we don't need to declare variables in the macros, we
can change the code to be implemented as static inlines.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
src/interfaces/libpq/fe-secure.c | 88 ---
1 file changed, 55 insertions(+), 33 deletions(-)
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index ee0a91e..13c97ac 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -119,45 +119,62 @@ static long win32_ssl_create_mutex = 0;
/*
* Macros to handle disabling and then restoring the state of SIGPIPE handling.
- * Note that DISABLE_SIGPIPE() must appear at the start of a block.
*/
#ifndef WIN32
#ifdef ENABLE_THREAD_SAFETY
-#define DISABLE_SIGPIPE(failaction) \
- sigset_tosigmask; \
- boolsigpipe_pending; \
- boolgot_epipe = false; \
-\
- if (pq_block_sigpipe(osigmask, sigpipe_pending) 0) \
- failaction
+struct sigpipe_info {
+ sigset_toldsigmask;
+ boolsigpipe_pending;
+ boolgot_epipe;
+};
-#define REMEMBER_EPIPE(cond) \
- do { \
- if (cond) \
- got_epipe = true; \
- } while (0)
+static inline int disable_sigpipe(struct sigpipe_info *info)
+{
+ info-got_epipe = false;
+ return pq_block_sigpipe(info-oldsigmask, info-sigpipe_pending) 0;
+}
-#define RESTORE_SIGPIPE() \
- pq_reset_sigpipe(osigmask, sigpipe_pending, got_epipe)
+static inline void remember_epipe(struct sigpipe_info *info, bool cond)
+{
+ if (cond)
+ info-got_epipe = true;
+}
+
+static inline void restore_sigpipe(struct sigpipe_info *info)
+{
+ pq_reset_sigpipe(info-oldsigmask, info-sigpipe_pending,
info-got_epipe);
+}
#else /* !ENABLE_THREAD_SAFETY */
-#define DISABLE_SIGPIPE(failaction) \
- pqsigfunc oldsighandler = pqsignal(SIGPIPE, SIG_IGN)
+struct sigpipe_info {
+ pqsigfunc oldhandler;
+};
-#define REMEMBER_EPIPE(cond)
+static inline int disable_sigpipe(struct sigpipe_info *info)
+{
+ info-oldhandler = pqsignal(SIGPIPE, SIG_IGN);
+ return 0;
+}
+
+static inline void remember_epipe(struct sigpipe_info *info, bool cond)
+{
+}
-#define RESTORE_SIGPIPE() \
- pqsignal(SIGPIPE, oldsighandler)
+static inline void restore_sigpipe(struct sigpipe_info *info)
+{
+ pqsignal(SIGPIPE, info-oldhandler);
+}
#endif /* ENABLE_THREAD_SAFETY */
#else /* WIN32 */
-#define DISABLE_SIGPIPE(failaction)
-#define REMEMBER_EPIPE(cond)
-#define RESTORE_SIGPIPE()
+struct sigpipe_info { };
+static inline int disable_sigpipe(struct sigpipe_info *info) { return 0; }
+static inline void remember_epipe(struct sigpipe_info *info, bool cond) { }
+static inline void restore_sigpipe(struct sigpipe_info *info) { }
#endif /* WIN32 */
@@ -286,9 +303,11 @@ pqsecure_read(PGconn *conn, void *ptr, size_t len)
if (conn-ssl)
{
int err;
+ struct sigpipe_info info;
/* SSL_read can write to the socket, so we need to disable
SIGPIPE */
- DISABLE_SIGPIPE(return -1);
+ if (disable_sigpipe(info))
+ return -1;
rloop:
n = SSL_read(conn-ssl, ptr, len);
@@ -315,7 +334,7 @@ rloop:
if (n == -1)
{
- REMEMBER_EPIPE(SOCK_ERRNO ==
EPIPE);
+ remember_epipe(info,
SOCK_ERRNO == EPIPE);
printfPQExpBuffer(conn-errorMessage,
libpq_gettext(SSL SYSCALL error: %s\n),
SOCK_STRERROR(SOCK_ERRNO, sebuf, sizeof(sebuf)));
@@ -351,7 +370,7 @@ rloop:
break;
}
- RESTORE_SIGPIPE();
+ restore_sigpipe(info);
}
else
#endif
@@ -367,8 +386,10 @@ ssize_t
pqsecure_write(PGconn *conn, const void *ptr, size_t len)
{
ssize_t n;
+ struct sigpipe_info info;
- DISABLE_SIGPIPE(return -1);
+ if (disable_sigpipe(info))
+ return -1;
#ifdef USE_SSL
if
[HACKERS] [PATCH 2/2] [libpq] Try to avoid manually masking SIGPIPEs on every send()
Currently, libpq will wrap each send() call on the connection with
two system calls to mask SIGPIPEs. This results in 3 syscalls instead
of one, and (on Linux) can lead to high contention on the signal
mask locks in threaded apps.
We have a couple of other methods to avoid SIGPIPEs:
sockopt(SO_NOSIGPIPE) and the MSG_NOSIGNAL flag to send().
This change attempts to use these if they're available at compile-
and run-time. If not, we drop back to manipulating the signal mask as
before.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
src/interfaces/libpq/fe-connect.c | 39 +
src/interfaces/libpq/fe-secure.c | 83 +-
src/interfaces/libpq/libpq-int.h |2
3 files changed, 106 insertions(+), 18 deletions(-)
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 7f4ae4c..8265268 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -1085,6 +1085,7 @@ keep_going:
/* We will come back to here until there is
while (conn-addr_cur != NULL)
{
struct addrinfo *addr_cur =
conn-addr_cur;
+ int optval;
/* Remember current address for
possible error msg */
memcpy(conn-raddr.addr,
addr_cur-ai_addr,
@@ -1149,6 +1150,44 @@ keep_going:
/* We will come back to here until there is
}
#endif /* F_SETFD */
+ /* We have three methods of blocking
sigpipe during
+* send() calls to this socket:
+*
+* - setsockopt(sock, SO_NOSIGPIPE)
+* - send(sock, ..., MSG_NOSIGNAL)
+* - setting the signal mask to
SIG_IGN during send()
+*
+* The first two reduce the number of
syscalls (for the
+* third, we require three syscalls to
implement a send()),
+* so use them if they're available.
Their availability is
+* flagged in the following members of
PGconn:
+*
+* conn-sigpipe_so - we
have set up SO_NOSIGPIPE
+* conn-sigpipe_flag - we're
specifying MSG_NOSIGNAL
+*
+* If we can use SO_NOSIGPIPE, then set
sigpipe_so here and
+* we don't need to care about anything
else. Otherwise,
+* try MSG_NOSIGNAL by setting
sigpipe_flag. If we get an
+* error with MSG_NOSIGNAL, we clear
the flag and revert
+* to manual masking.
+*/
+ conn-sigpipe_so = false;
+#ifdef MSG_NOSIGNAL
+ conn-sigpipe_flag = true;
+#else /* !MSG_NOSIGNAL */
+ conn-sigpipe_flag = false;
+#endif /* MSG_NOSIGNAL */
+
+#ifdef SO_NOSIGPIPE
+ if (!setsockopt(conn-sock, SOL_SOCKET,
SO_NOSIGPIPE,
+ (char *)optval,
sizeof(optval)))
+ {
+ conn-sigpipe_so = true;
+ conn-sigpipe_flag = false;
+ }
+#endif /* SO_NOSIGPIPE */
+
+
/*
* Start/make connection. This should
not block, since we
* are in nonblock mode. If it does,
well, too bad.
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 13c97ac..949cd0f 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -122,6 +122,18 @@ static long win32_ssl_create_mutex = 0;
*/
#ifndef WIN32
+
+static inline int sigpipe_masked(PGconn *conn)
+{
+ /* If we're on an SSL connection, we can only use SO_NOSIGPIPE masking.
+* Otherwise, we can handle SO_NOSIGPIPE or the MSG_NOSIGNAL flag */
+#ifdef USE_SSL
+ if (conn-ssl)
+ return conn-sigpipe_so;
+#endif
+ return conn-sigpipe_so || conn-sigpipe_flag;
+}
+
#ifdef
Re: [HACKERS] postmaster recovery and automatic restart suppression
Hi, On Wed, Jun 10, 2009 at 4:21 AM, Simon Riggssi...@2ndquadrant.com wrote: On Tue, 2009-06-09 at 20:59 +0200, Kolb, Harald (NSN - DE/Munich) wrote: There are some good reasons why a switchover could be an appropriate means in case the DB is facing troubles. It may be that the root cause is not the DB itsself, but used resources or other things which are going crazy and hit the DB first ( we've seen a lot of these unbelievable things which made us quite sensible for robustness aspects). Therefore we want to have control on the DB recovery. If you don't want to see this option as a GUC parameter, would it be acceptable to have it as a new postmaster cmd line option ? Even if you had this, you still need to STONITH just in case the failover happens by mistake. Yes. On second thought, probably we should solve this kind of problem outside of Postgres. Is there a possibility to deactivate the restart and to force the postmaster to simply exit at the end ? The background is that we will have a watchdog process which will in this case perform a fast switchover to the standby side (in case of syncronous replication) or will restart the db by its own and in addition will perform some specific actions. To return to the original Harald's problem, the watchdog process can shoot postmaster before doing the next action. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Tom Lane wrote: Drat. Okay, that easy solution probably won't fly. Anyone with AIX access want to try to develop a patch that covers this case without breaking the other ones? I can try, but I only have AIX 5.3 to test with, so I won't be able to test for bugs in other versions. I would need to know what the problems with getaddrinfo on AIX are. Is this an exhaustive list? http://archives.postgresql.org/pgsql-hackers/2009-01/msg01705.php http://archives.postgresql.org/pgsql-hackers/2006-10/msg01069.php http://archives.postgresql.org/pgsql-general/2006-10/msg00909.php http://archives.postgresql.org/pgsql-hackers/2004-07/msg01018.php http://archives.postgresql.org/pgsql-hackers/2004-04/msg00474.php I'll also try to investigate known bugs in AIX' getaddrinfo. AIX 4.3 has been out of support for some time - if it makes the task easier, would it be an option to desupport it? Yours, Laurenz Albe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc..
Getting error while trying to insert date with the format 'dd-month-' , 'day-mm-' (format which add the space in between the date ) etc.. Testcase: postgres=# \d t Table public.t Column | Type | Modifiers +--+--- a | date | postgres=# insert into t values ( to_char(current_date+2, 'day-mm-')::date); ERROR: invalid input syntax for type date: friday -06-2009 postgres=# insert into t values ( to_char(current_date+2, 'dd-month-')::date); ERROR: invalid input syntax for type date: 12-june -2009 Debugged the issue and found that error coming from date_in() - DecodeDateTime(). Problem here is whenever any space comes in the date ParseDateTime() unable to break string into tokens based on a date/time context. -- Rushabh Lathia www.EnterpriseDB.com
Re: [HACKERS] Plan time Improvement - 64bit bitmapset
Hi,
On 06/03/2009 06:42 PM, Tom Lane wrote:
Andres Freundand...@anarazel.de writes:
On 06/03/2009 06:21 PM, Tom Lane wrote:
I find this *really* hard to believe, because I've never seen the bitmap
support operations show up noticeably at all in profiles. What sort of
queries are you testing?
Many left joins from one base relation to additional dimensions. All the
dimensions are relatively complex views consisting out of multiple joins
or subselects.
Some correlated subqueries and some [NOT] EXISTS() are also included in
some of the queries.
Hmmm, could you provide a complete test case? I'm thinking the behavior
might indicate some other performance issue, ie an unreasonable number
of bitmapset calls in some particular planning path.
Ok. I tried to reproduce it using only pg_catalog and suceeded to some
degree:
- The query is pointless, pointless, pointless
- The effect is only around 5-10% instead of the 15-20% I have measured
(fewer tables involved - fewer cache misses?)
- The query is crazy, but so is the one on the schema in question
- I could get more consistent results with geqo disabled, but the
results are in the same ballpark whether enabled or not
- Sometimes adding a single join more/less dropped the planning time to
a fraction - strange.
- The same with changing {join,from}_collapse_limit - sometimes changing
it yields plan times different by orders of magnitudes in both directions.
On the real data its naturally not only one view but multiple ones...
And there are fewer views involved, but they are more complex (including
EXISTS(), and some subqueries).
Plan time (averaged) without change:
cnt: 40 (4 times per session)
avg: 4572ms
Plan time (averaged) with change:
cnt: 40 (4 times per session)
avg: 4236ms
~7% difference. Same with higher number of repetitions and with most
other planner settings I tried
Now thats not a lot of change, but again, this is smaller than with the
original queries.
Does that help?
Andres
SET geqo = on;
SET geqo_effort = 5;
SET geqo_threshold = 12;
SET join_collapse_limit = 8;
SET from_collapse_limit = 8;
--/*
DROP VIEW IF EXISTS public.pg_class_with_attributes;
CREATE VIEW public.pg_class_with_attributes AS
SELECT pg_class.oid, pg_class.relnamespace, pg_class.reltype,
pg_attribute.atttypid, other.oid AS otheroid
FROM pg_class
JOIN pg_attribute ON
pg_class.oid = pg_attribute.attrelid
JOIN pg_type ON
pg_attribute.atttypid = pg_type.oid
JOIN pg_constraint ON
pg_constraint.conrelid = pg_class.oid
JOIN pg_class other ON
other.oid = pg_constraint.confrelid
JOIN pg_locks ON
pg_locks.relation = pg_class.oid
OR
pg_locks.relation = other.oid
JOIN pg_stat_activity ON
pg_locks.pid = pg_stat_activity.procpid
JOIN pg_tablespace ON
pg_class.reltablespace = pg_tablespace.oid
OR
other.reltablespace = pg_tablespace.oid
LEFT JOIN pg_stat_all_tables ON
pg_stat_all_tables.relid = pg_class.oid
OR
pg_stat_all_tables.relid = other.oid
LEFT JOIN pg_stat_all_indexes ON
pg_stat_all_indexes.relid = pg_class.oid
OR
pg_stat_all_indexes.relid = other.oid
JOIN pg_attrdef ON
pg_attribute.attrelid = pg_attrdef.adrelid
AND
pg_attribute.attnum = pg_attrdef.adnum;
;
--*/
PREPARE bench_1 AS
SELECT *
FROM pg_class
JOIN pg_class_with_attributes AS pg_class_with_attributes_1 ON
pg_class.oid = pg_class_with_attributes_1.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_2 ON
pg_class.oid = pg_class_with_attributes_2.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_3 ON
pg_class.oid = pg_class_with_attributes_3.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_4 ON
pg_class.oid = pg_class_with_attributes_4.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_5 ON
pg_class.oid = pg_class_with_attributes_5.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_6 ON
pg_class.oid = pg_class_with_attributes_6.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_7 ON
pg_class.oid = pg_class_with_attributes_7.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_8 ON
pg_class.oid = pg_class_with_attributes_8.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_9 ON
pg_class.oid = pg_class_with_attributes_9.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_10 ON
pg_class.oid = pg_class_with_attributes_10.oid
JOIN pg_class_with_attributes AS pg_class_with_attributes_11 ON
[HACKERS] Re: [PATCH 2/2] [libpq] Try to avoid manually masking SIGPIPEs on every send()
On 6/10/09, Jeremy Kerr j...@ozlabs.org wrote: + int optval; + if (!setsockopt(conn-sock, SOL_SOCKET, SO_NOSIGPIPE, + (char *)optval, sizeof(optval))) optval seems used without initialization. But generally, I like it. +1 -- marko -- 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] Plan time Improvement - 64bit bitmapset
Andres Freund and...@anarazel.de writes: Plan time (averaged) without change: cnt: 40 (4 times per session) avg: 4572ms Plan time (averaged) with change: cnt: 40 (4 times per session) avg: 4236ms ~7% difference. Same with higher number of repetitions and with most other planner settings I tried What are you comparing here? -- 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] Plan time Improvement - 64bit bitmapset
Hi, On 06/10/2009 01:38 PM, Gregory Stark wrote: Andres Freundand...@anarazel.de writes: Plan time (averaged) without change: cnt: 40 (4 times per session) avg: 4572ms Plan time (averaged) with change: cnt: 40 (4 times per session) avg: 4236ms ~7% difference. Same with higher number of repetitions and with most other planner settings I tried What are you comparing here? 32bit and 64bit bitmapsets with the attached query. 32beeing the default and the slower one. Does that answer the question? Andres -- 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] [PATCH 2/2] [libpq] Try to avoid manually masking SIGPIPEs on every send()
Marko, optval seems used without initialization. Dang, I was checking for the SO_NOSIGPIPE flag, and didn't check for optval. New patch coming... Cheers, Jeremy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH v2] [libpq] Try to avoid manually masking SIGPIPEs on every send()
Currently, libpq will wrap each send() call on the connection with
two system calls to mask SIGPIPEs. This results in 3 syscalls instead
of one, and (on Linux) can lead to high contention on the signal
mask locks in threaded apps.
We have a couple of other methods to avoid SIGPIPEs:
sockopt(SO_NOSIGPIPE) and the MSG_NOSIGNAL flag to send().
This change attempts to use these if they're available at compile-
and run-time. If not, we drop back to manipulating the signal mask as
before.
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
v2: initialise optval
---
src/interfaces/libpq/fe-connect.c | 40 ++
src/interfaces/libpq/fe-secure.c | 83 +-
src/interfaces/libpq/libpq-int.h |2
3 files changed, 107 insertions(+), 18 deletions(-)
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 7f4ae4c..92ab4e0 100644
--- a/src/interfaces/libpq/fe-connect.c
+++ b/src/interfaces/libpq/fe-connect.c
@@ -1085,6 +1085,7 @@ keep_going:
/* We will come back to here until there is
while (conn-addr_cur != NULL)
{
struct addrinfo *addr_cur =
conn-addr_cur;
+ int optval;
/* Remember current address for
possible error msg */
memcpy(conn-raddr.addr,
addr_cur-ai_addr,
@@ -1149,6 +1150,45 @@ keep_going:
/* We will come back to here until there is
}
#endif /* F_SETFD */
+ /* We have three methods of blocking
sigpipe during
+* send() calls to this socket:
+*
+* - setsockopt(sock, SO_NOSIGPIPE)
+* - send(sock, ..., MSG_NOSIGNAL)
+* - setting the signal mask to
SIG_IGN during send()
+*
+* The first two reduce the number of
syscalls (for the
+* third, we require three syscalls to
implement a send()),
+* so use them if they're available.
Their availability is
+* flagged in the following members of
PGconn:
+*
+* conn-sigpipe_so - we
have set up SO_NOSIGPIPE
+* conn-sigpipe_flag - we're
specifying MSG_NOSIGNAL
+*
+* If we can use SO_NOSIGPIPE, then set
sigpipe_so here and
+* we don't need to care about anything
else. Otherwise,
+* try MSG_NOSIGNAL by setting
sigpipe_flag. If we get an
+* error with MSG_NOSIGNAL, we clear
the flag and revert
+* to manual masking.
+*/
+ conn-sigpipe_so = false;
+#ifdef MSG_NOSIGNAL
+ conn-sigpipe_flag = true;
+#else /* !MSG_NOSIGNAL */
+ conn-sigpipe_flag = false;
+#endif /* MSG_NOSIGNAL */
+
+#ifdef SO_NOSIGPIPE
+ optval = 1;
+ if (!setsockopt(conn-sock, SOL_SOCKET,
SO_NOSIGPIPE,
+ (char *)optval,
sizeof(optval)))
+ {
+ conn-sigpipe_so = true;
+ conn-sigpipe_flag = false;
+ }
+#endif /* SO_NOSIGPIPE */
+
+
/*
* Start/make connection. This should
not block, since we
* are in nonblock mode. If it does,
well, too bad.
diff --git a/src/interfaces/libpq/fe-secure.c b/src/interfaces/libpq/fe-secure.c
index 13c97ac..949cd0f 100644
--- a/src/interfaces/libpq/fe-secure.c
+++ b/src/interfaces/libpq/fe-secure.c
@@ -122,6 +122,18 @@ static long win32_ssl_create_mutex = 0;
*/
#ifndef WIN32
+
+static inline int sigpipe_masked(PGconn *conn)
+{
+ /* If we're on an SSL connection, we can only use SO_NOSIGPIPE masking.
+* Otherwise, we can handle SO_NOSIGPIPE or the MSG_NOSIGNAL flag */
+#ifdef USE_SSL
+ if (conn-ssl)
+ return conn-sigpipe_so;
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
On Wed, Jun 10, 2009 at 3:38 AM, Albe Laurenzlaurenz.a...@wien.gv.at wrote: Tom Lane wrote: Drat. Okay, that easy solution probably won't fly. Anyone with AIX access want to try to develop a patch that covers this case without breaking the other ones? I can try, but I only have AIX 5.3 to test with, so I won't be able to test for bugs in other versions. I would need to know what the problems with getaddrinfo on AIX are. Is this an exhaustive list? http://archives.postgresql.org/pgsql-hackers/2009-01/msg01705.php http://archives.postgresql.org/pgsql-hackers/2006-10/msg01069.php http://archives.postgresql.org/pgsql-general/2006-10/msg00909.php http://archives.postgresql.org/pgsql-hackers/2004-07/msg01018.php http://archives.postgresql.org/pgsql-hackers/2004-04/msg00474.php I'll also try to investigate known bugs in AIX' getaddrinfo. AIX 4.3 has been out of support for some time - if it makes the task easier, would it be an option to desupport it? We have 4.3 and a 6.0 here. 4.3 is pretty old, I don't think it's a big deal if we can't get it to work, as long as libpq works. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] page is uninitialized --- fixing
On Tue, 2009-06-09 at 17:28 -0400, Tom Lane wrote: Is there any particular reason to suppose that the empty pages appeared during a crash recovery? Have you read through md.c? I seem to recall there are some slightly squirrelly choices made there about segment-extension behavior. Maybe it could've done the wrong thing here during normal operation. The only way I can see this happening is 1. backup: pg_start_backup() 2. user1: creates temp table 3. user2: Vacuum causes partial truncation of table 4. backup: copies table's files 5. backup: pg_stop_backup() When we replay this, we do so with a base backup that starts recovering at XLogRecPtr of start_backup(), but using a file copied at a later XLogRecPtr. I don't see any way thru md.c that would allow reading a block beyond the end of the currently existing file (except in recovery). I'm fairly certain that this didn't happen because the table in question was pg_attribute and the main problem was that it had not been vacuumed for a very long time. Which leaves me perplexed. An erroneous value from file seek would lead to this though, so perhaps that is the easiest explanation: damage to file metadata in memory. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- 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] pgindent run coming
Andrew Dunstan wrote:
Bruce Momjian wrote:
OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?
The buildfarm does not run the find-typedefs script. Its code for this
is below. My Unix machine runs this once a day. I can do runs on Windows
and Cygwin manually.
If there is changed logic tell me what it is and I'll try to get it done.
Yes, please make the attached change, and rerun the script. This change
reflects the changes I made in src/tools/find_typedef.
What value is there if the URL I have just runs on Linux? It probably
has the same coverage I have for BSD. I asked for something that was
automated for more platforms a year ago and I still don't have it? I
might as well just use the same method I have have used for years.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
*** ./script.pl.orig Wed Jun 10 09:39:27 2009
--- ./script.pl Wed Jun 10 09:39:39 2009
***
*** 30,36
{
@flds = split;
next if (@flds 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
$syms{$1} =1;
}
}
--- 30,36
{
@flds = split;
next if (@flds 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):t/);
$syms{$1} =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] pgindent run coming
Simon Riggs si...@2ndquadrant.com writes: On Tue, 2009-06-09 at 13:21 -0400, Bruce Momjian wrote: It is time to run pgindent on CVS HEAD for 8.4. I am thinking of running it at zero-hour GMT tomorrow, meaning five hours from now. Why don't we do this automatically after each individual commit? It's not very practical until the typedef extraction stuff is fully automatic and fully trustworthy; right now some manual review and intervention still seems like a good idea. Also, that would risk breaking series of interdependent patches. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc..
Rushabh Lathia rushabh.lat...@gmail.com writes: Getting error while trying to insert date with the format 'dd-month-' , 'day-mm-' (format which add the space in between the date ) etc.. 1. Why are you bothering with the completely pointless to_char call at all? 2. It is not a bug that to_char is capable of emitting formats that won't be read by the standard datetime input converter. If you insist on making a useless conversion to char and back, it's on your head to choose a format setting that will work. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multicolumn index corruption on 8.4 beta 2
Floris Bos / Maxnet wrote:
The following settings differ from the defaults:
--
shared_buffers=3500MB
maintenance_work_mem = 128MB
fsync = off
synchronous_commit = off
checkpoint_segments = 25
--
==
Table layout
==
--
Table public.posts_index
Column | Type | Modifiers
++---
cid| integer| not null default
nextval('posts_index_cid
_seq'::regclass)
groupid| integer| not null
startdate | integer| not null
poster | character varying(64) | not null
basefile | character varying(64) | not null
subject| character varying(255) | not null
size | real |
nfo| boolean|
c | boolean|
parts | integer|
totalparts | integer|
imdb | integer|
ng1| boolean| default false
g2 | integer| default 0
g3 | integer| default 0
data | bytea |
Indexes:
posts_index5_pkey PRIMARY KEY, btree (cid) CLUSTER
gr_idx btree (groupid, (- cid))
pgb_idx btree (poster, groupid, basefile)
--
Only noticed problems with the pgb_idx index so far.
I have been trying to reproduce the problem but no success so far. I
made myself a table that matches yours, then I wrote a little perl
script to fill it with random data. (The script also writes out a text
file I can use to re-query things).
I fill the db, then add the indexes. Then I test lookup every record I
added, and find them all.
So, a few questions:
1) did you dump/restore into 8.4beta1 first and then upgrade the
program? Or did you dump/restore into 8.4beta2?
2) did you use any of the concurrent restore options?
3) do you do any updates or deletes to the table after you restore it?
4) do you do any other operations on the table (vacuum, cluster, etc..)?
5) got any triggers or stored procs?
6) To the -hackers: I write the records and then refind them in the
exact same order, would it be a better test to search for records in a
more random order? would it make a difference? Would searching for
some but not all make a difference?
-Andy
--
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] pgindent run coming
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: I saw a few odd things. Most importantly, it seems 'stat' was introduced as a typedef on _both_ lists, yielding weird changes like: The standard headers do define struct stat. I wonder whether the objdump kluge we are using is unable to distinguish typedef names from struct tags. I will have to research this further tomorrow. We don't have a lot of time for research. Maybe the best thing is to just manually remove stat from the typedef list (along with anything else that clearly shouldn't be there)? I agree we are running out of time so I will be running pgindent in one hour using the same BSD-based typedef method I have used in the past. If a better typedef list appears, we can always rerun pgindent. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] pgindent run coming
Bruce Momjian br...@momjian.us writes: Tom Lane wrote: We don't have a lot of time for research. Maybe the best thing is to just manually remove stat from the typedef list (along with anything else that clearly shouldn't be there)? I agree we are running out of time so I will be running pgindent in one hour using the same BSD-based typedef method I have used in the past. If a better typedef list appears, we can always rerun pgindent. Why not compare the BSD list with the new one and adopt anything that seems sane? We know that your old method misses quite a lot of typedefs. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
OK, Andrew, would you use the find_typedef file that is in CVS HEAD and
run that. I think that will fix our problem and then I can use the
buildfarm version. How often does that run and does it pull the script
from CVS HEAD?
The buildfarm does not run the find-typedefs script. Its code for this
is below. My Unix machine runs this once a day. I can do runs on Windows
and Cygwin manually.
If there is changed logic tell me what it is and I'll try to get it done.
Yes, please make the attached change, and rerun the script. This change
reflects the changes I made in src/tools/find_typedef.
What value is there if the URL I have just runs on Linux? It probably
has the same coverage I have for BSD. I asked for something that was
automated for more platforms a year ago and I still don't have it? I
might as well just use the same method I have have used for years.
Well, sometimes I build it and they don't come ;-).
I don't have every platform under the sun that I can run this on,
although I do now have an FBSD VM that I didn't have when I worked on
this previously. If you're actually going to use it I'll set it up as a
buildfarm member and run the find-typedefs there.
I will make the change you request and rerun the stuff on the platforms
I have that are currently buildfarm members, but AFAICT the Linux output
will still include the stat symbol (your change doesn't affect the Linux
branch at all).
Both my version and yours contains provision for filtering out certain
symbols ('timestamp' etc). Maybe we need to add 'stat' to that list.
cheers
andrew
*** ./script.pl.origWed Jun 10 09:39:27 2009
--- ./script.pl Wed Jun 10 09:39:39 2009
***
*** 30,36
{
@flds = split;
next if (@flds 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):[tT]/);
$syms{$1} =1;
}
}
--- 30,36
{
@flds = split;
next if (@flds 7);
! next if ($flds[1] ne 'LSYM' || $flds[6] !~ /([^:]+):t/);
$syms{$1} =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] pgindent run coming
Andrew Dunstan wrote:
Well, sometimes I build it and they don't come ;-).
I don't have every platform under the sun that I can run this on,
although I do now have an FBSD VM that I didn't have when I worked on
this previously. If you're actually going to use it I'll set it up as a
buildfarm member and run the find-typedefs there.
I will make the change you request and rerun the stuff on the platforms
I have that are currently buildfarm members, but AFAICT the Linux output
will still include the stat symbol (your change doesn't affect the Linux
branch at all).
Good point. Here is another diff I need you to make to the pl file.
If you want to make your pl file the official version and replace the
shell script in CVS, that is fine with me. Do you want me to do that?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
*** ./script.pl.orig Wed Jun 10 09:39:27 2009
--- ./script.pl Wed Jun 10 11:09:36 2009
***
*** 14,20
if (@err == 1) # Linux
{
@dumpout = `objdump -W $bin 2/dev/null | egrep -A3
! '(DW_TAG_typedef|DW_TAG_structure_type|DW_TAG_union_type)' 2/dev/null`;
foreach (@dumpout)
{
@flds = split;
--- 14,20
if (@err == 1) # Linux
{
@dumpout = `objdump -W $bin 2/dev/null | egrep -A3
! 'DW_TAG_typedef' 2/dev/null`;
foreach (@dumpout)
{
@flds = split;
--
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] pgindent run coming
Bruce Momjian wrote: Good point. Here is another diff I need you to make to the pl file. Done. Linux run under way. If you want to make your pl file the official version and replace the shell script in CVS, that is fine with me. Do you want me to do that? It needs to be done in two pieces, I think: a perl module that exports a function that can be called from the buildfarm, and program that calls it so it can be run standalone. The function needs two inputs: an installation directory and a source directory. Then we will be able to stay in sync nicely. I will try to do that over the next day or so if you like. Or we can just wing it for now and do this after the release. cheers andrew -- 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] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Merlin Moncure wrote: I wrote: I can try, but I only have AIX 5.3 to test with, so I won't be able to test for bugs in other versions. I would need to know what the problems with getaddrinfo on AIX are. I'll also try to investigate known bugs in AIX' getaddrinfo. AIX 4.3 has been out of support for some time - if it makes the task easier, would it be an option to desupport it? We have 4.3 and a 6.0 here. 4.3 is pretty old, I don't think it's a big deal if we can't get it to work, as long as libpq works. Ok, I did a bit of research here. First, the only cases that affect us are the following: a) listen_addresses = '*' Then the hostname argument to getaddrinfo will be NULL, and the servname argument will be 5432 or similar. b) listen_addresses = '' This does not affect us, since it will not call getaddrinfo. c) listen_addresses = 'host1[,...]' Then the hostname argument will be host1 (DNS name or IPv4/6 address), and servname will be 5432 or similar. Moreover, in the struct addrinfo hint, the following will be set: ai_flags = AI_PASSIVE ai_family = AF_UNSPEC ai_socktype = SOCK_STREAM and all other hints will be zero. Did I cover all cases? I tested getaddrinfo() on my AIX 5.3 ML 03 with these cases, and I did not encounter any problems and the result looked right. I searched the bug database at IBM, and the only APARs that looked like they might affect us are: IY40908, IY45130 = IY44782, IY47326 = IY46612 = IY48232, IY46023, IY51966 = IY50970, IY54776, IZ00799 and IY86414 = IY86549. Since it works on my system, I wonder if the machines where it fails did not have any fixpacks installed. Does Andrew Chernow's machine have the terminal fixpack installed? I wonder what problem he encountered when he said the service argument to getaddrinfo is busted on AIX 4.3. Maybe it would be good enough to state that AIX is only supported with certain fixpacks installed? And do without all the AIX hacks? Yours, Laurenz Albe -- 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] pgindent run coming
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I saw a few odd things. Most importantly, it seems 'stat' was
introduced as a typedef on _both_ lists, yielding weird changes like:
The standard headers do define struct stat. I wonder whether the
objdump kluge we are using is unable to distinguish typedef names
from struct tags.
I will have to research this further tomorrow.
We don't have a lot of time for research. Maybe the best thing is to
just manually remove stat from the typedef list (along with anything
else that clearly shouldn't be there)?
The problem is that there are other symbols I don't know about and the
diff is very large. I have found that the problem was caused when we
added Linux support to find_typedef and I have a way to get an accurate
list on my machine.
OK, I have found the cause of the script error, and it was my fault. A
month after we ran pgindent for 8.3 (December 2007), I received this
issue from Tom:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php
Something I noticed the other day is that pgindent doesn't seem to treat
struct foo or union foo as a type name, which is pretty silly
because no context is needed at all to recognize that. We tend not to
do that too much --- the project style is to use a typedef name --- but
there are some places that do it, particularly the regex code. For
instance there are extra spaces here:
static void
cmtreefree(struct colormap * cm,
union tree * tree,
int level)/* level number (top == 0) of this
block */
{
Fixable?
Not understanding the ramifications of adding struct and union tags to
the typedef list, I modified the BSD code:
http://archives.postgresql.org/pgsql-hackers/2007-12/msg00810.php
Yes, I found those are 't' STABS rather than T which are used in cases
where you do typedef struct {} name. The next pgindent will have those
typedefs you want.
and that modification was propogated to the Linux code.
This has now been fixed in the BSD and Linux code (and Perl script) and
we can move forward with running pgindent once Andrew has lists for all
the platforms he wants.
As for Tom's original complaint about, it seems BSD indent is just not
smart enough about struct/union tags. I will look into fixing that
after 8.4 pgindent is run.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
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] Plan time Improvement - 64bit bitmapset
Andres Freund and...@anarazel.de wrote:
- Sometimes adding a single join more/less dropped the planning time
to a fraction - strange.
- The same with changing {join,from}_collapse_limit - sometimes
changing it yields plan times different by orders of magnitudes in
both directions.
That seems like the place to spend the time looking, rather than
nibbling away at the run times by a few percent after letting them
jump by orders of magnitude.
-Kevin
--
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] pgindent run coming
Andrew Dunstan wrote: Bruce Momjian wrote: Good point. Here is another diff I need you to make to the pl file. Done. Linux run under way. If you want to make your pl file the official version and replace the shell script in CVS, that is fine with me. Do you want me to do that? It needs to be done in two pieces, I think: a perl module that exports a function that can be called from the buildfarm, and program that calls it so it can be run standalone. The function needs two inputs: an installation directory and a source directory. Then we will be able to stay in sync nicely. I will try to do that over the next day or so if you like. Or we can just wing it for now and do this after the release. We have to wing it for now. Please let me know when whatever lists you can generate are ready, hopefully in the next few hours. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Albe Laurenz laurenz.a...@wien.gv.at writes: Maybe it would be good enough to state that AIX is only supported with certain fixpacks installed? And do without all the AIX hacks? That would definitely be a good-enough solution in my opinion, as long as we can document which fixes are needed for which releases. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Bruce Momjian br...@momjian.us writes: OK, I have found the cause of the script error, and it was my fault. A month after we ran pgindent for 8.3 (December 2007), I received this issue from Tom: http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php Something I noticed the other day is that pgindent doesn't seem to treat struct foo or union foo as a type name, which is pretty silly because no context is needed at all to recognize that. Ah. So really the point here is that we want to specifically exclude struct stat because there are too many places in our code where stat is used as a regular identifier. Are there any other special cases like that? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7
Given that RC freeze is nearly upon us for 8.4, and that we need a reasonably non-invasive fix for 8.3 anyway, I propose that for now we just deal with the syncscan issue by tweaking heap_rescan so that rs_startblock doesn't get changed. It looks like that's about a three-line patch. The question of how cursors should behave with respect to volatile functions can be documented and left for another time. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PlannerInfo Structure
Hi all, I created a function which needs build or find a relation (RelOptInfo). The build is ok. On the other hand, I can't find the relation. I have all informations that pg_plan_query has: querytree (Query), cursorOptions (int), boundParams(ParamListInfo) and plan (PlannedStmt). So, how can I take RelOptInfo by these parameters? I thought in use find_base_rel, but it needs the PlannerInfo structure that I don't have. Do you recommend another function? How can I find PlannerInfo with parameters that I have (Eg.: PlannedStmt)? Thanks, Ana Carolina
Re: [HACKERS] Plan time Improvement - 64bit bitmapset
Hi,
On 06/10/2009 06:01 PM, Kevin Grittner wrote:
Andres Freundand...@anarazel.de wrote:
- Sometimes adding a single join more/less dropped the planning time
to a fraction - strange.
- The same with changing {join,from}_collapse_limit - sometimes
changing it yields plan times different by orders of magnitudes in
both directions.
That seems like the place to spend the time looking, rather than
nibbling away at the run times by a few percent after letting them
jump by orders of magnitude.
Yes. I noticed this while looking for reasons. And I will continue to do
so...
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Resolving 8.4 open items
If we are to make the proposed schedule for 8.4 (ie, wrap RC1 tomorrow) we've got to get pretty hard-nosed about closing out the open items at http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items The current list is: * do we need to worry about re-encoding file path names? There is perhaps a real issue here, but it's not been explained nearly to my satisfaction: I do not understand how we should determine which encoding should be passed to the filesystem (but surely that shouldn't vary with the per-database locale), and it's also unclear why we shouldn't assume the value of PGDATA is already in that encoding. Perhaps the issue really applies only to file paths supplied to COPY, in which case the proposed patch is fixing it in the wrong place. I think we should just punt this question to TODO. * revisit increase of default_statistics_target? Seems like the conclusion of that thread is no. * getaddrinfo issue on AIX We need a fix for this, or at least documentation of which OS patches should be applied. * cursor stability issues I will fix this per my proposal just now. * contrib/seg and contrib/cube GiST index support have performance issues * possible bug in cover density ranking? * localeconv encoding issues Punt all these to TODO. They are pre-existing issues and 8.4 is no worse than prior releases. * BUG #4622: xpath only work in utf-8 server encoding Document this as a limitation and put it on TODO. There are also a number of documentation issues open, particularly Dimitri's work on documenting the GIST API better, but we can work on those later. We've never considered that the RC freeze applies to documentation. Objections? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PlannerInfo Structure
Ana Carolina Brito de Almeida ana...@ig.com.br writes: I created a function which needs build or find a relation (RelOptInfo). The build is ok. On the other hand, I can't find the relation. I have all informations that pg_plan_query has: querytree (Query), cursorOptions (int), boundParams(ParamListInfo) and plan (PlannedStmt). So, how can I take RelOptInfo by these parameters? I thought in use find_base_rel, but it needs the PlannerInfo structure that I don't have. Do you recommend another function? How can I find PlannerInfo with parameters that I have (Eg.: PlannedStmt)? You can't; it's a transient structure and it's already gone after the planner returns. If you are plugging into the planning process somewhere, it should be getting passed to you, but the data isn't kept around after the plan is completed. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving 8.4 open items
Tom Lane wrote: If we are to make the proposed schedule for 8.4 (ie, wrap RC1 tomorrow) we've got to get pretty hard-nosed about closing out the open items at http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items The current list is: * do we need to worry about re-encoding file path names? There is perhaps a real issue here, but it's not been explained nearly to my satisfaction: I do not understand how we should determine which encoding should be passed to the filesystem (but surely that shouldn't vary with the per-database locale), and it's also unclear why we shouldn't assume the value of PGDATA is already in that encoding. Perhaps the issue really applies only to file paths supplied to COPY, in which case the proposed patch is fixing it in the wrong place. I think we should just punt this question to TODO. Is there really something new here for 8.4? Haven't we lived with this same thing previously? If it's not a regression, +1 for punting. -- Magnus Hagander Self: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Multicolumn index corruption on 8.4 beta 2
Andy, 6) To the -hackers: I write the records and then refind them in the exact same order, would it be a better test to search for records in a more random order? would it make a difference? Would searching for some but not all make a difference? Are you on OpenSolaris? Can you give your script to Zdenek Jignesh to test in their enviroments? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving 8.4 open items
Magnus Hagander mag...@hagander.net writes: Tom Lane wrote: * do we need to worry about re-encoding file path names? Is there really something new here for 8.4? Haven't we lived with this same thing previously? Right, it's a pre-existing issue --- any misbehavior in this area goes back to the beginning. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving 8.4 open items
On 6/10/09 10:40 AM, Tom Lane wrote: * contrib/seg and contrib/cube GiST index support have performance issues Wasn't there an issue that fixing this requires a data format change? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote: Albe Laurenz laurenz.a...@wien.gv.at writes: Maybe it would be good enough to state that AIX is only supported with certain fixpacks installed? And do without all the AIX hacks? That would definitely be a good-enough solution in my opinion, as long as we can document which fixes are needed for which releases. my take is to go with Albe's solution. I'm downloading the cumulative fixpack for 4.3.3: http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html If the above fixes the problem with the aix hacks removed, problem solved. If it doesn't, then let's face the music and formally drop support for aix 4.3 for 8.4. (and, other than that, do nothing). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Problem with listen_addresses = '*' on 8.4beta2 on AIX
Merlin Moncure wrote: On Wed, Jun 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote: Albe Laurenz laurenz.a...@wien.gv.at writes: Maybe it would be good enough to state that AIX is only supported with certain fixpacks installed? And do without all the AIX hacks? That would definitely be a good-enough solution in my opinion, as long as we can document which fixes are needed for which releases. my take is to go with Albe's solution. I'm downloading the cumulative fixpack for 4.3.3: http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html If the above fixes the problem with the aix hacks removed, problem solved. If it doesn't, then let's face the music and formally drop support for aix 4.3 for 8.4. (and, other than that, do nothing). You mean nothing other than removing the AIX hacks? (I'm with Tom. This has been a constant annoyance over quite a few years.) cheers andrew -- 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] Multicolumn index corruption on 8.4 beta 2
Josh Berkus wrote: Andy, 6) To the -hackers: I write the records and then refind them in the exact same order, would it be a better test to search for records in a more random order? would it make a difference? Would searching for some but not all make a difference? Are you on OpenSolaris? Can you give your script to Zdenek Jignesh to test in their enviroments? I am not, and yes I can. Hopefully I can attach a .tar.bz2 The bigtest.sh is the one to run (it runs all the parts). You'll need to edit fill.pl and test.pl and set the dbname and maybe give a username/password. In the fill.pl there is a $max variable that's used to set the number of records to insert. (its set to 10 million right now) Oh, this .tar wont create a subdirectory -Andy test.tar.bz2 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] Resolving 8.4 open items
Josh Berkus j...@agliodbs.com writes: On 6/10/09 10:40 AM, Tom Lane wrote: * contrib/seg and contrib/cube GiST index support have performance issues Wasn't there an issue that fixing this requires a data format change? Well, that means it probably doesn't get fixed till 8.5. I'm annoyed at that, but such is life. The problem's been there since those modules were created, so we can stand it for another release cycle. Alternatively, we can postpone 8.4 till Oleg and Teodor have some spare cycles to look at the patch, but who knows when that will be. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, I have found the cause of the script error, and it was my fault. A month after we ran pgindent for 8.3 (December 2007), I received this issue from Tom: http://archives.postgresql.org/pgsql-hackers/2007-12/msg00800.php Something I noticed the other day is that pgindent doesn't seem to treat struct foo or union foo as a type name, which is pretty silly because no context is needed at all to recognize that. Ah. So really the point here is that we want to specifically exclude struct stat because there are too many places in our code where stat is used as a regular identifier. Are there any other special cases like that? Yep, lots. I see option also doing strange things, and some others. You can see the diff here: http://momjian.us/expire/pgindent/http://momjian.us/expire/pgindent/ Basically that list is meant for typedefs, not struct or union tags. The BSD indent manual page says: -Ttypename Adds typename to the list of type keywords. Names accu- mulate: -T can be specified more than once. You need to specify all the typenames that appear in your program that are defined by typedef - nothing will be harmed if you miss a few, but the program won't be formatted as nicely as it should. This sounds like a painful thing to have to do, but it's really a symptom of a problem in C: typedef causes a syntactic change in the language and indent can't find all instances of typedef. I am unclear why struct pointers are not being formatted properly in function headers but will research it. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Multicolumn index corruption on 8.4 beta 2
Floris, One more question set: what version of OpenSolaris, and what filesystem are you using? Does the OS have any non-default tuning settings? How did you install or compile PostgreSQL? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving 8.4 open items
Tom, Alternatively, we can postpone 8.4 till Oleg and Teodor have some spare cycles to look at the patch, but who knows when that will be. Not soon. So, +1 to go ahead. If this issue has existed for several versions, and we're not getting a lot of complaints, it says that either not many people are using cube and seg or they don't notice performance issues. Mind you, if performance is terrible, then not many people *would* use cube or seg ... -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Bruce Momjian br...@momjian.us writes: I am unclear why struct pointers are not being formatted properly in function headers but will research it. Yeah, if we can fix that directly without adding the names to the typedef list, it would be better. But not something to do right now. Have you started the pgindent run yet? I have a patch ready for the cursor stability issue, but will hold off committing if it might create a merge problem for you. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc..
On Wednesday 10 June 2009 17:10:42 Tom Lane wrote: Rushabh Lathia rushabh.lat...@gmail.com writes: Getting error while trying to insert date with the format 'dd-month-' , 'day-mm-' (format which add the space in between the date ) etc.. 1. Why are you bothering with the completely pointless to_char call at all? Random guess for entertainment: Oracle applications do this sort of thing all the time. 2. It is not a bug that to_char is capable of emitting formats that won't be read by the standard datetime input converter. If you insist on making a useless conversion to char and back, it's on your head to choose a format setting that will work. Of course they then also use to_date all the time. -- 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] Resolving 8.4 open items
Josh Berkus j...@agliodbs.com writes: If this issue has existed for several versions, and we're not getting a lot of complaints, it says that either not many people are using cube and seg or they don't notice performance issues. Mind you, if performance is terrible, then not many people *would* use cube or seg ... I suspect there aren't many. What I'm more concerned about is that people may have copied the bogus logic for use in their own datatypes. (Which is exactly how Matthew Wakeling came to find out the problem.) But in any case, this train is leaving the station. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving 8.4 open items
Tom, I suspect there aren't many. What I'm more concerned about is that people may have copied the bogus logic for use in their own datatypes. (Which is exactly how Matthew Wakeling came to find out the problem.) But in any case, this train is leaving the station. Can we put a warning in the README for both modules not to copy them as examples? -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Resolving 8.4 open items
Josh Berkus j...@agliodbs.com writes: Tom, I suspect there aren't many. What I'm more concerned about is that people may have copied the bogus logic for use in their own datatypes. (Which is exactly how Matthew Wakeling came to find out the problem.) But in any case, this train is leaving the station. Can we put a warning in the README for both modules not to copy them as examples? Seems a bit pointless unless we have a better example to offer instead. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: I am unclear why struct pointers are not being formatted properly in function headers but will research it. Yeah, if we can fix that directly without adding the names to the typedef list, it would be better. But not something to do right now. Have you started the pgindent run yet? I have a patch ready for the cursor stability issue, but will hold off committing if it might create a merge problem for you. I am waiting for Andrew to tell me he is ready with updated lists for his platforms. His CGI output is now _not_ showing stat so I am comparing the lists now. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] pgindent run coming
Bruce Momjian br...@momjian.us writes: Have you started the pgindent run yet? I have a patch ready for the cursor stability issue, but will hold off committing if it might create a merge problem for you. I am waiting for Andrew to tell me he is ready with updated lists for his platforms. His CGI output is now _not_ showing stat so I am comparing the lists now. OK, I'll commit now and then stay out of your way. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: I am unclear why struct pointers are not being formatted properly in function headers but will research it. Yeah, if we can fix that directly without adding the names to the typedef list, it would be better. But not something to do right now. Have you started the pgindent run yet? I have a patch ready for the cursor stability issue, but will hold off committing if it might create a merge problem for you. I am doing runs as requested on various platforms to extract the typedef lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come. Results in a few hours. The buildfarm will have a consolidated list. cheers andrew -- 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] pgindent run coming
Andrew Dunstan wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I am unclear why struct pointers are not being formatted properly in
function headers but will research it.
Yeah, if we can fix that directly without adding the names to the
typedef list, it would be better. But not something to do right now.
Have you started the pgindent run yet? I have a patch ready for
the cursor stability issue, but will hold off committing if it might
create a merge problem for you.
I am doing runs as requested on various platforms to extract the typedef
lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come.
Results in a few hours. The buildfarm will have a consolidated list.
OK, good. However, I am seeing missing typedefs in the Linux list you
posted at:
http://www.pgbuildfarm.org/cgi-bin/typedefs.pl
I pulled this list 20 minutes ago. I compared your list to the BSD list
I usually used and found that the Linux list had fewer typedefs:
2270 typedefs.old
1848 typedefs.new
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
...
boolvisible;/* include this portal in pg_cursors? */
} PortalData;
I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
5,16d4
AMT
AMTS
ASN1_BIT_STRING
ASN1_BMPSTRING
ASN1_BOOLEAN
ASN1_CTX
ASN1_ENCODING
ASN1_ENUMERATED
ASN1_GENERALIZEDTIME
ASN1_GENERALSTRING
ASN1_HEADER
ASN1_IA5STRING
18,24d5
ASN1_ITEM
ASN1_ITEM_EXP
ASN1_METHOD
ASN1_NULL
ASN1_OBJECT
ASN1_OCTET_STRING
ASN1_PRINTABLESTRING
26,36d6
ASN1_STRING_TABLE
ASN1_T61STRING
ASN1_TEMPLATE
ASN1_TIME
ASN1_TLC
ASN1_TYPE
ASN1_UNIVERSALSTRING
ASN1_UTCTIME
ASN1_UTF8STRING
ASN1_VALUE
ASN1_VISIBLESTRING
59d28
AfterTriggerEventDataOneCtid
68d36
AggHashEntryData
72d39
AggStatePerAggData
80d46
AllocBlockData
82d47
AllocChunkData
142d106
AutoVacuumSignal
149d112
BINOP
151d113
BIO_F_BUFFER_CTX
153d114
BIO_dummy
156,157d116
BIT_STRING_BITNAME
BLOCK
159d117
BN_BLINDING
161,162d118
BN_MONT_CTX
BN_RECP_CTX
175d130
BTScanPos
184d138
BUF_MEM
187d140
BackslashQuoteType
212d164
BoolPtr
221d172
BufferAccessStrategyData
231,233d181
BulkInsertStateData
Byte
Bytef
241,259d188
COMP_CTX
COMP_METHOD
CONDOP
CONF
CONF_IMODULE
CONF_METHOD
CONF_MODULE
CONF_VALUE
COP
CPFunction
CPPFunction
CRYPTO_EX_DATA
CRYPTO_EX_DATA_FUNCS
CRYPTO_EX_DATA_IMPL
CRYPTO_EX_dup
CRYPTO_EX_free
CRYPTO_EX_new
CRYPTO_MEM_LEAK_CB
CRYPTO_dynlock
261d189
CURCUR
298d225
CoercionCodes
301d227
CoercionMethod
326d251
ConstraintExclusionType
360d284
CreateStmtLikeOption
365d288
Cred
376d298
DCH_poz
381d302
DH_METHOD
388,389d308
DSA_METHOD
DSA_SIG
395d313
DatumPtr
417d334
Dl_info
442,448d358
ENGINE_CIPHERS_PTR
ENGINE_CMD_DEFN
ENGINE_CTRL_FUNC_PTR
ENGINE_DIGESTS_PTR
ENGINE_GEN_FUNC_PTR
ENGINE_GEN_INT_FUNC_PTR
ENGINE_LOAD_KEY_PTR
450,452d359
ERR_FNS
ERR_STATE
ERR_STRING_DATA
454,457d360
EVP_CIPHER
EVP_CIPHER_CTX
EVP_CIPHER_INFO
EVP_ENCODE_CTX
460d362
EVP_PBE_KEYGEN
495d396
FF
500d400
FUNMAP
535d434
FormData_pg_description
553d451
FormData_pg_shdescription
578d475
Form_pg_description
596d492
Form_pg_shdescription
618d513
Function
629d523
GEN_SESSION_CB
642,644d535
GP
GV
GVOP
647d537
GenericOptionFlags
660d549
GinScanEntryData
676d564
GlobalTransactionData
701,702d588
HE
HEK
704d589
HISTORY_STATE
721d605
HashJoinTableData
723d606
HashJoinTupleData
740d622
HeapScanDescData
747d628
I16
749d629
I8
751d630
IO
755d633
IV64
759,760d636
IndexAttributeBitMap
IndexAttributeBitMapData
773d648
IndexScanDescData
784d658
InhPaths
805,806d678
ItemLength
ItemOffset
810d681
JMPENV
818,819d688
KEYMAP_ENTRY
KEYMAP_ENTRY_ARRAY
822,828c691,693
Keymap
LHASH
LHASH_COMP_FN_TYPE
LHASH_DOALL_ARG_FN_TYPE
LHASH_DOALL_FN_TYPE
LHASH_HASH_FN_TYPE
LHASH_NODE
---
LDAP
LDAPMessage
LDAP_TIMEVAL
830d694
LISTOP
839,840d702
LOGOP
LOOP
870d731
LockInfo
876d736
LockTagType
882d741
MAGIC
884,888d742
MD2_CTX
MD4_CTX
MD5_CTX
MDC2_CTX
MGVTBL
898d751
MergeJoinClauseData
914,916d766
NETSCAPE_CERT_SEQUENCE
NETSCAPE_SPKAC
NETSCAPE_SPKI
921d770
NUM_poz
944c793
OBJ_NAME
---
OM_uint32
976d824
Outrec
979d826
PADOFFSET
981,988d827
PBE2PARAM
PBEPARAM
PBKDF2PARAM
PEM_CTX
PEM_ENCODE_SEAL_CTX
PEM_USER
PERL_CONTEXT
PERL_SI
992d830
PGErrorVerbosity
1018d855
PGSSTrackLevel
1037,1047d873
PKCS7
PKCS7_DIGEST
PKCS7_ENCRYPT
PKCS7_ENC_CONTENT
PKCS7_ENVELOPE
PKCS7_ISSUER_AND_SERIAL
PKCS7_RECIP_INFO
PKCS7_SIGNED
Re: [HACKERS] Resolving 8.4 open items
On Wed, 10 Jun 2009, Tom Lane wrote: There are also a number of documentation issues open, particularly Dimitri's work on documenting the GIST API better, but we can work on those later. We've never considered that the RC freeze applies to documentation. I had a question in this area actually. I'm working on making a mini version of http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server under Server Configuration in the docs. Basically, make a new section titled Performance Optimization that provides a short list of values to tune for better performance. We've got plenty of evidence it's hard to figure out which of the knobs in the resource/query sections are the big important ones, and which sound cool but tend to be less useful. If I got that done over the next week or two, would that still be early enough to make it into 8.4? We've made a lot of progress in the last year building community consensus in this area, and I'd like to get at least an intro to that into the official docs. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- 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] pgindent run coming
Out of curiosity how different is the output if we don't pass the typedef list at all? I'm wondering if the formatting differences are things we actually care much about anyways. -- 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] pgindent run coming
Bruce Momjian wrote:
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
...
boolvisible;/* include this portal in pg_cursors? */
} PortalData;
I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.
Well, that is almost certainly a result of the change you asked me to
make :-)
The symbol is in the run done early this morning before those changes.
See
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetledt=2009-06-10%20064401stg=typedefs
So we need to look and see what tag that symbol has in the objdump output.
cheers
andrew
--
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] Resolving 8.4 open items
Greg Smith gsm...@gregsmith.com writes: On Wed, 10 Jun 2009, Tom Lane wrote: There are also a number of documentation issues open, particularly Dimitri's work on documenting the GIST API better, but we can work on those later. We've never considered that the RC freeze applies to documentation. I had a question in this area actually. I'm working on making a mini version of http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server under Server Configuration in the docs. Basically, make a new section titled Performance Optimization that provides a short list of values to tune for better performance. We've got plenty of evidence it's hard to figure out which of the knobs in the resource/query sections are the big important ones, and which sound cool but tend to be less useful. If I got that done over the next week or two, would that still be early enough to make it into 8.4? We've made a lot of progress in the last year building community consensus in this area, and I'd like to get at least an intro to that into the official docs. If there's actually consensus on it, it could go in post-RC, but I'm not sure we're as close as all that ... BTW, wouldn't it fit better under Performance Tips (chapter 14)? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Greg Stark st...@enterprisedb.com writes: Out of curiosity how different is the output if we don't pass the typedef list at all? I'm wondering if the formatting differences are things we actually care much about anyways. It tends to put extra spaces in variable declarations that are using the typedef. Not sure about other effects, but it is kinda ugly when you are used to it being right. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
On Tuesday 09 June 2009 20:21:35 Bruce Momjian wrote: It is time to run pgindent on CVS HEAD for 8.4. I am thinking of running it at zero-hour GMT tomorrow, meaning five hours from now. Any objections? Btw., can you make pgindent remove whitespace at the end of lines? -- 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] Multicolumn index corruption on 8.4 beta 2
Floris Bos / Maxnet b...@je-eigen-domein.nl writes: Hi, Tom Lane wrote: Floris Bos / Maxnet b...@je-eigen-domein.nl writes: postg...@db:/data$ /opt/postgres/8.4-beta/bin/64/initdb -E SQL_ASCII -X /data/pg_xlog /data/db The database cluster will be initialized with locale en_US.UTF-8. Oooh, that doesn't look real good. You're going to be using strcoll() comparisons that assume the data is in UTF8, but the database is not enforcing valid UTF8 encoding. I have not checked the dump to see if it's all valid data, but this could be the root of the issue. If you want to use SQL_ASCII because the data isn't uniformly encoded, it'd be better to use C locale. Darn. Looks like you are right! Works a lot better with --locale=C My 8.3 PostgreSQL installation ran under FreeBSD, and there the locale is C by default: So I was not used to have to add a --locale=C option. Under Opensolaris it's indeed UTF-8 by default. Yeah, this is kind of unfortunate. I'm not sure there is much we could do about it, unless we want to insist that C locale be used if the database encoding is SQL_ASCII. That cure seems worse than the disease though. We have locked down encoding/locale combinations pretty strictly for 8.4, but SQL_ASCII is generally thought to be a let the user beware setting. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Peter Eisentraut pete...@gmx.net writes: Btw., can you make pgindent remove whitespace at the end of lines? I think it usually does that already ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Andrew Dunstan wrote:
Bruce Momjian wrote:
I did a diff, attached, and found some typedefs that don't appear, like
PortalData. That is defined in our code as:
typedef struct PortalData *Portal;
typedef struct PortalData
{
/* Bookkeeping data */
...
boolvisible;/* include this portal in pg_cursors? */
} PortalData;
I will try to build on Linux here and see how objdump displays that,
unless you can get me the output.
Well, that is almost certainly a result of the change you asked me to
make :-)
The symbol is in the run done early this morning before those changes.
See
http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=dungbeetledt=2009-06-10%20064401stg=typedefs
So we need to look and see what tag that symbol has in the objdump output.
OK, I got the answer for Linux. I built 8.4 RC2 and ran:
objdump -W postgres |grep -3 PortalData
and the output is attached. You will notice every mention of PortalData
has 'DW_TAG_structure_type' (stucture member) above it, and none have
DW_TAG_typedef (typedef tag). This is caused by this documented
behavior from find_typedef:
# Linux
# Unfortunately the Linux version doesn't show unreferenced typedefs.
# The problem is that they are still in the source code so should be
# indented properly. However, I think pgindent only cares about
# the typedef references, not the definitions, so I think it might
# be fine
So that is why the Linux list is shorter, but again, I think that is fine.
Andrew, let me know when your list is ready.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
8db7 DW_AT_byte_size : 4
8db8 DW_AT_type: 8dbc
18dbc: Abbrev Number: 24 (DW_TAG_structure_type)
8dbd DW_AT_name: PortalData
8dc8 DW_AT_byte_size : 96
8dc9 DW_AT_decl_file : 40
8dca DW_AT_decl_line : 105
--
14706e DW_AT_byte_size : 4
14706f DW_AT_type: 147073
1147073: Abbrev Number: 24 (DW_TAG_structure_type)
147074 DW_AT_name: PortalData
14707f DW_AT_byte_size : 96
147080 DW_AT_decl_file : 43
147081 DW_AT_decl_line : 105
--
20dd10 DW_AT_byte_size : 4
20dd11 DW_AT_type: 20dd15
120dd15: Abbrev Number: 17 (DW_TAG_structure_type)
20dd16 DW_AT_name: PortalData
20dd21 DW_AT_byte_size : 96
20dd22 DW_AT_decl_file : 46
20dd23 DW_AT_decl_line : 105
--
2144bc DW_AT_byte_size : 4
2144bd DW_AT_type: 2144c1
12144c1: Abbrev Number: 16 (DW_TAG_structure_type)
2144c2 DW_AT_name: PortalData
2144cd DW_AT_byte_size : 96
2144ce DW_AT_decl_file : 46
2144cf DW_AT_decl_line : 105
--
273c96 DW_AT_byte_size : 4
273c97 DW_AT_type: 273c9b
1273c9b: Abbrev Number: 19 (DW_TAG_structure_type)
273c9c DW_AT_name: PortalData
273ca7 DW_AT_byte_size : 96
273ca8 DW_AT_decl_file : 40
273ca9 DW_AT_decl_line : 105
--
348c3f DW_AT_byte_size : 4
348c40 DW_AT_type: 348c44
1348c44: Abbrev Number: 20 (DW_TAG_structure_type)
348c45 DW_AT_name: PortalData
348c50 DW_AT_byte_size : 96
348c51 DW_AT_decl_file : 42
348c52 DW_AT_decl_line : 105
--
4b0f00 DW_AT_byte_size : 4
4b0f01 DW_AT_type: 4b0f05
14b0f05: Abbrev Number: 7 (DW_TAG_structure_type)
4b0f06 DW_AT_name: PortalData
4b0f11 DW_AT_byte_size : 96
4b0f12 DW_AT_decl_file : 57
4b0f13 DW_AT_decl_line : 105
--
4b9974 DW_AT_byte_size : 4
4b9975 DW_AT_type: 4b9979
14b9979: Abbrev Number: 17 (DW_TAG_structure_type)
4b997a DW_AT_name: PortalData
4b9985 DW_AT_byte_size : 96
4b9986 DW_AT_decl_file : 47
4b9987 DW_AT_decl_line : 105
--
4c28e3 DW_AT_byte_size : 4
4c28e4 DW_AT_type: 4c28e8
14c28e8: Abbrev Number: 22 (DW_TAG_structure_type)
4c28e9 DW_AT_name: PortalData
4c28f4 DW_AT_byte_size : 96
4c28f5 DW_AT_decl_file : 42
4c28f6 DW_AT_decl_line : 105
--
5d8c98 DW_AT_byte_size : 4
5d8c99 DW_AT_type: 5d8c9d
15d8c9d: Abbrev Number: 26 (DW_TAG_structure_type)
5d8c9e DW_AT_name: PortalData
5d8ca9 DW_AT_byte_size : 96
5d8caa DW_AT_decl_file : 39
5d8cab DW_AT_decl_line : 105
--
5e42f0 DW_AT_byte_size : 4
5e42f1 DW_AT_type: 5e42f5
15e42f5: Abbrev Number: 26
Re: [HACKERS] pgindent run coming
Tom Lane wrote: Greg Stark st...@enterprisedb.com writes: Out of curiosity how different is the output if we don't pass the typedef list at all? I'm wondering if the formatting differences are things we actually care much about anyways. It tends to put extra spaces in variable declarations that are using the typedef. Not sure about other effects, but it is kinda ugly when you are used to it being right. Yea, I used a short pgindent typedef list once and people noticed right away so I had to rerun. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] pgindent run coming
Tom Lane wrote: Peter Eisentraut pete...@gmx.net writes: Btw., can you make pgindent remove whitespace at the end of lines? I think it usually does that already ... Yes. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] pgindent run coming
On Wednesday 10 June 2009 22:50:15 Bruce Momjian wrote:
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Btw., can you make pgindent remove whitespace at the end of lines?
I think it usually does that already ...
Yes.
Um, attached you will find a bunch of counterexamples.
Index: src/bin/initdb/initdb.c
===
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.171
diff -u -3 -p -r1.171 initdb.c
--- src/bin/initdb/initdb.c 3 Jun 2009 16:17:49 - 1.171
+++ src/bin/initdb/initdb.c 10 Jun 2009 20:42:32 -
@@ -1356,9 +1356,9 @@ bootstrap_template1(char *short_version)
bki_lines = replace_token(bki_lines, ENCODING, encodingid);
bki_lines = replace_token(bki_lines, LC_COLLATE, lc_collate);
-
+
bki_lines = replace_token(bki_lines, LC_CTYPE, lc_ctype);
-
+
/*
* Pass correct LC_xxx environment to bootstrap.
*
Index: src/bin/pg_ctl/pg_ctl.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_ctl/pg_ctl.c,v
retrieving revision 1.110
diff -u -3 -p -r1.110 pg_ctl.c
--- src/bin/pg_ctl/pg_ctl.c 5 Apr 2009 04:19:58 - 1.110
+++ src/bin/pg_ctl/pg_ctl.c 10 Jun 2009 20:42:32 -
@@ -1486,9 +1486,9 @@ CreateRestrictedProcess(char *cmd, PROCE
}
#ifndef __CYGWIN__
-AddUserToDacl(processInfo-hProcess);
+ AddUserToDacl(processInfo-hProcess);
#endif
-
+
CloseHandle(restrictedToken);
ResumeThread(processInfo-hThread);
Index: src/bin/pg_dump/dumputils.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/dumputils.c,v
retrieving revision 1.45
diff -u -3 -p -r1.45 dumputils.c
--- src/bin/pg_dump/dumputils.c 11 Mar 2009 03:33:29 - 1.45
+++ src/bin/pg_dump/dumputils.c 10 Jun 2009 20:42:33 -
@@ -59,7 +59,7 @@ init_parallel_dump_utils(void)
const char *
fmtId(const char *rawid)
{
- /*
+ /*
* The Tls code goes awry if we use a static var, so we provide for both
* static and auto, and omit any use of the static var when using Tls.
*/
@@ -87,7 +87,7 @@ fmtId(const char *rawid)
{
/* new buffer */
id_return = createPQExpBuffer();
-#ifdef WIN32
+#ifdef WIN32
if (parallel_init_done)
TlsSetValue(tls_index,id_return);
else
@@ -95,7 +95,7 @@ fmtId(const char *rawid)
#else
s_id_return = id_return;
#endif
-
+
}
/*
Index: src/bin/pg_dump/keywords.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/keywords.c,v
retrieving revision 1.2
diff -u -3 -p -r1.2 keywords.c
--- src/bin/pg_dump/keywords.c 8 Mar 2009 16:53:30 - 1.2
+++ src/bin/pg_dump/keywords.c 10 Jun 2009 20:42:33 -
@@ -18,7 +18,7 @@
#include parser/keywords.h
/*
- * We don't need the token number, so leave it out to avoid requiring other
+ * We don't need the token number, so leave it out to avoid requiring other
* backend headers.
*/
#define PG_KEYWORD(a,b,c) {a,0,c},
Index: src/bin/pg_dump/pg_backup_archiver.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_archiver.c,v
retrieving revision 1.171
diff -u -3 -p -r1.171 pg_backup_archiver.c
--- src/bin/pg_dump/pg_backup_archiver.c 4 Jun 2009 19:16:48 - 1.171
+++ src/bin/pg_dump/pg_backup_archiver.c 10 Jun 2009 20:42:33 -
@@ -3487,12 +3487,12 @@ parallel_restore(RestoreArgs *args)
/*
* Close and reopen the input file so we have a private file pointer
- * that doesn't stomp on anyone else's file pointer, if we're actually
+ * that doesn't stomp on anyone else's file pointer, if we're actually
* going to need to read from the file. Otherwise, just close it
* except on Windows, where it will possibly be needed by other threads.
*
* Note: on Windows, since we are using threads not processes, the
- * reopen call *doesn't* close the original file pointer but just open
+ * reopen call *doesn't* close the original file pointer but just open
* a new one.
*/
if (te-section == SECTION_DATA )
@@ -3870,7 +3870,7 @@ CloneArchive(ArchiveHandle *AH)
ArchiveHandle *clone;
/* Make a flat copy */
- clone = (ArchiveHandle *) malloc(sizeof(ArchiveHandle));
+ clone = (ArchiveHandle *) malloc(sizeof(ArchiveHandle));
if (clone == NULL)
die_horribly(AH, modulename, out of memory\n);
memcpy(clone, AH, sizeof(ArchiveHandle));
Index: src/bin/pg_dump/pg_backup_custom.c
===
RCS file: /cvsroot/pgsql/src/bin/pg_dump/pg_backup_custom.c,v
retrieving revision 1.41
diff -u -3 -p -r1.41 pg_backup_custom.c
--- src/bin/pg_dump/pg_backup_custom.c 2 Feb 2009 20:07:37 - 1.41
+++ src/bin/pg_dump/pg_backup_custom.c 10 Jun 2009 20:42:33 -
@@ -133,8 +133,8 @@ InitArchiveFmt_Custom(ArchiveHandle *AH)
AH-StartBlobPtr = _StartBlob;
AH-EndBlobPtr = _EndBlob;
AH-EndBlobsPtr = _EndBlobs;
- AH-ClonePtr =
Re: [HACKERS] pgindent run coming
Peter Eisentraut pete...@gmx.net writes: I think it usually does that already ... Um, attached you will find a bunch of counterexamples. At a quick look, I'm not sure that any of these are in code that hasn't been edited since the 8.3 pgindent run. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
On Wed, Jun 10, 2009 at 9:54 PM, Tom Lanet...@sss.pgh.pa.us wrote: Peter Eisentraut pete...@gmx.net writes: I think it usually does that already ... Um, attached you will find a bunch of counterexamples. At a quick look, I'm not sure that any of these are in code that hasn't been edited since the 8.3 pgindent run. On a tangent: git warns about or fixes up white-space problems like that when you're applying a patch. I've actually found this to be a bit of a dilemma though. For code i want it to just go ahead and fix up anything it finds. But for regression test expected output files I don't want it to. I don't think you can control it per-directory though. -- Gregory Stark http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Display of foreign keys in psql
I'm having trouble coming up with a sensible translation for the last line of this: peter=# \d test* Table public.test1 Column | Type | Modifiers +-+--- a | integer | not null Indexes: test1_pkey PRIMARY KEY, btree (a) Referenced by: test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a) Is there a magic reason why the IN is capitalized? (Maybe from would be better anyway?) -- 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] Display of foreign keys in psql
Peter Eisentraut wrote: I'm having trouble coming up with a sensible translation for the last line of this: peter=# \d test* Table public.test1 Column | Type | Modifiers +-+--- a | integer | not null Indexes: test1_pkey PRIMARY KEY, btree (a) Referenced by: test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a) Is there a magic reason why the IN is capitalized? (Maybe from would be better anyway?) Probably not. They were used to capitalizing IN for a subquery and it carried over; should be lowercase. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Display of foreign keys in psql
Bruce Momjian br...@momjian.us wrote: Peter Eisentraut wrote: Indexes: test1_pkey PRIMARY KEY, btree (a) Referenced by: test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a) Is there a magic reason why the IN is capitalized? should be lowercase. What about PRIMARY KEY, FOREIGN KEY, and REFERENCES? Shouldn't these keywords be consistently capitalized (or not)? -Kevin -- 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] Display of foreign keys in psql
Peter Eisentraut pete...@gmx.net writes: Referenced by: test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a) Is there a magic reason why the IN is capitalized? (Maybe from would be better anyway?) I think it was probably done to make it more visually distinct from the adjacent identifiers, which would be lowercase more often than not. Personally I'd suggest losing the word altogether; what's wrong with Referenced by: test2_y_fkey test2 FOREIGN KEY (y) REFERENCES test1(a) Or use TABLE: test2_y_fkey TABLE test2 FOREIGN KEY (y) REFERENCES test1(a) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Display of foreign keys in psql
On Wed, Jun 10, 2009 at 10:58 PM, Bruce Momjianbr...@momjian.us wrote: Is there a magic reason why the IN is capitalized? (Maybe from would be better anyway?) Probably not. They were used to capitalizing IN for a subquery and it carried over; should be lowercase. Well in that line everything that isn't part of the user's expressions, columns, or table names is in all-caps. But I agree it looks odd. I don't really have a better suggestion though. Hm, maybe in table foo or from table foo would be better than just having the one preposition alone. -- Gregory Stark http://mit.edu/~gsstark/resume.pdf -- 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] Display of foreign keys in psql
2009/6/11 Peter Eisentraut pete...@gmx.net: Referenced by: test2_y_fkey IN test2 FOREIGN KEY (y) REFERENCES test1(a) Is there a magic reason why the IN is capitalized? (Maybe from would be better anyway?) Isn't on the conventional preposition to use here? I would think of this as a foreign key on test2, referencing test1. In the same way you would talk about having a primary key on a table. Same goes for indexes, triggers, table constraints, etc. IMO Cheers, BJ -- 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] Display of foreign keys in psql
On Wed, Jun 10, 2009 at 11:04 PM, Tom Lanet...@sss.pgh.pa.us wrote: Or use TABLE: test2_y_fkey TABLE test2 FOREIGN KEY (y) REFERENCES test1(a) Hm, one of the things a lot of people said they liked about the existing list is that it was almost copy-pastable as the command to recreate the constraint. If we use TABLE it might make sense to reorder things so that it matches the command. The command that would recreate this constraint is: ALTER TABLE test2 ADD CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a); So perhaps something like: Referenced by: TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a); -- Gregory Stark http://mit.edu/~gsstark/resume.pdf -- 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] Not quite a security hole in internal_in
I wrote: Sergey Burladyan eshkin...@gmail.com writes: How about contrib/ ? I have this in my test 8.3.7 database: That stuff should all be marked strict ... on the whole I'm not sure that contrib is null-safe anyway, independently of this particular issue. AFAIK no one's really gone through it. So I just did that, and found one bit of sloppiness in pg_freespacemap, plus a whole lot of GIST/GIN support functions that aren't marked strict and probably should be. Will fix. This is actually a lot closer to being right than I would have bet on before the exercise. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Display of foreign keys in psql
Greg Stark st...@enterprisedb.com writes: So perhaps something like: Referenced by: TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a); +1 ... although making it *really* copy-and-pastable would require a bit more attention to detail than I bet it's gotten. (Schema qualification and double-quoting-at-need being the likely trouble spots.) Still, we can fix that later if we have the basic appearance being compatible with that goal. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [BUGS] Cursor with hold emits the same row more than once across commits in 8.3.7
Tom Lane wrote: Given that RC freeze is nearly upon us for 8.4, and that we need a reasonably non-invasive fix for 8.3 anyway, I propose that for now we just deal with the syncscan issue by tweaking heap_rescan so that rs_startblock doesn't get changed. It looks like that's about a three-line patch. The question of how cursors should behave with respect to volatile functions can be documented and left for another time. Sounds like a good approach. Mark -- 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] Display of foreign keys in psql
On Wed, Jun 10, 2009 at 11:21 PM, Tom Lanet...@sss.pgh.pa.us wrote: Greg Stark st...@enterprisedb.com writes: So perhaps something like: Referenced by: TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a); +1 ... although making it *really* copy-and-pastable would require a bit more attention to detail than I bet it's gotten. (Schema qualification and double-quoting-at-need being the likely trouble spots.) Still, we can fix that later if we have the basic appearance being compatible with that goal. Even there the TABLE is kind of optional. It would stlil make sense as Referenced by: test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a) and even like that it looks like it's the widest line in the printout -- Gregory Stark http://mit.edu/~gsstark/resume.pdf -- 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] Display of foreign keys in psql
Greg Stark st...@enterprisedb.com writes: On Wed, Jun 10, 2009 at 11:21 PM, Tom Lanet...@sss.pgh.pa.us wrote: Greg Stark st...@enterprisedb.com writes: TABLE test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a); +1 Even there the TABLE is kind of optional. It would stlil make sense as Referenced by: test2 CONSTRAINT test2_y_fkey FOREIGN KEY (y) REFERENCES test1(a) I think that goes against our message style guidelines (46.3.9: When citing the name of an object, state what kind of object it is). Not sure if brevity is worth a small chance of confusion. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 8.4beta[12] set returning function fails -- was O.K. with 8.3
Dear PostgreSQL Hackers, Through PostgreSQL 8.3, both of the following functions worked, using generate_series(array_lower($1, 1), array_upper($1, 1)) i instead of generate_subscripts($1, 1). With PostgreSQL 8.4, both are accepted, but only the second one works, regardless of whether I use generate_subscripts or the old way. The error is shown. What's going on? Thanks, _Greg CREATE OR REPLACE FUNCTION array_to_set(ANYARRAY) RETURNS SETOF RECORD AS $$ SELECT i AS index, $1[i] AS value FROM generate_subscripts($1, 1) i $$ LANGUAGE SQL STRICT IMMUTABLE; COMMENT ON FUNCTION array_to_set(ANYARRAY) IS 'returns the array as a set of RECORD(index, value) pairs'; SELECT array_to_set(ARRAY['one', 'two']); -- BREAKS IN PG 8.4 beta1 beta2, vis: -- -- ERROR: 0A000: set-valued function called in context that cannot accept a set -- CONTEXT: SQL function array_to_set during startup -- LOCATION: fmgr_sql, functions.c:644 CREATE OR REPLACE FUNCTION array_to_list(ANYARRAY) RETURNS SETOF ANYELEMENT AS $$ SELECT $1[i] FROM generate_subscripts($1, 1) i $$ LANGUAGE SQL STRICT IMMUTABLE; COMMENT ON FUNCTION array_to_list(ANYARRAY) IS 'returns the array as a set of its elements from lowest to highest; - can we guarantee the values will be seen in order???'; SELECT array_to_list(ARRAY['one', 'two']); -- Works great, vis: -- --array_to_list -- --- -- one -- two -- (2 rows) -- 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] pgindent run coming
Andrew Dunstan wrote: I am doing runs as requested on various platforms to extract the typedef lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come. Results in a few hours. The buildfarm will have a consolidated list. The consolidated list comes from Windows(mingw) and Linux. My Cygwin run broke for some reason, and 'objdump --stabs' doesn't seem to do what we need on FBSD, so the output there was empty. If someone knows how to get the typedefs out via objdump on FBSD would they please let us know ASAP? Bruce, I think that's the best I can do today. thanks andrew -- 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] pgindent run coming
Andrew Dunstan wrote: Andrew Dunstan wrote: I am doing runs as requested on various platforms to extract the typedef lists. Linux is done, Windows (mingw) is running, FBSD and Cygwin to come. Results in a few hours. The buildfarm will have a consolidated list. The consolidated list comes from Windows(mingw) and Linux. My Cygwin run broke for some reason, and 'objdump --stabs' doesn't seem to do what we need on FBSD, so the output there was empty. If someone knows how to get the typedefs out via objdump on FBSD would they please let us know ASAP? I will check on our Postgres shell server right away. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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] Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc..
On Thu, Jun 11, 2009 at 12:02 AM, Peter Eisentraut pete...@gmx.net wrote: On Wednesday 10 June 2009 17:10:42 Tom Lane wrote: Rushabh Lathia rushabh.lat...@gmail.com writes: Getting error while trying to insert date with the format 'dd-month-' , 'day-mm-' (format which add the space in between the date ) etc.. 1. Why are you bothering with the completely pointless to_char call at all? Random guess for entertainment: Oracle applications do this sort of thing all the time. I thought when we are providing the different format into to_char for datetime then standard datetime input converters should also have the capability to read that format. 2. It is not a bug that to_char is capable of emitting formats that won't be read by the standard datetime input converter. If you insist on making a useless conversion to char and back, it's on your head to choose a format setting that will work. Of course they then also use to_date all the time. Yes, its we can always use to_date. -- Rushabh Lathia
Re: [HACKERS] Getting error while trying to insert date with the format 'dd-month-yyyy' , 'day-mm-yyyy' etc..
Rushabh Lathia rushabh.lat...@gmail.com writes: I thought when we are providing the different format into to_char for datetime then standard datetime input converters should also have the capability to read that format. to_char is designed to support a near-infinite number of output formats, including many that are necessarily ambiguous. There is no intention whatsoever that they all be readable by the input converters. It might or might not be useful to adjust the input converters to read the specific format you chose. But to_char produced it is simply not an interesting argument in favor of that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pgindent run coming
Bruce Momjian wrote: The consolidated list comes from Windows(mingw) and Linux. My Cygwin run broke for some reason, and 'objdump --stabs' doesn't seem to do what we need on FBSD, so the output there was empty. If someone knows how to get the typedefs out via objdump on FBSD would they please let us know ASAP? I will check on our Postgres shell server right away. OK, so we got that working, and the consolidated list now contains FBSD data as well. cheers andrew -- 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] pgindent run coming
Andrew Dunstan and...@dunslane.net writes: Bruce Momjian wrote: I will check on our Postgres shell server right away. OK, so we got that working, and the consolidated list now contains FBSD data as well. Um, let's *go* guys. RC1 wrap is scheduled for 18 hours from now. That means it is already too late to be sure that we'll have a full cycle of buildfarm checks on the pgindent run. Quit fooling around and get it done. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
