A great first step would be to add elog(INFO,...) in some standardized
format over the wire so that clients can tell what's going on. It could
be triggered by a GUC which is off by default.
-M
On Jul 15, 2006, at 9:10 PM, Greg Stark wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Maybe w
Hannu Krosing <[EMAIL PROTECTED]> writes:
> And by any chance, do you plan to backport the standby WAL playback mode
> patches to 8.0 and 8.1 series ?
That's not happening ... we do not put new features in stable branches.
regards, tom lane
---(end
Instead of this rigmarole with pg_usleep() being a macro to
pgwin32_backend_usleep, why don't we just call the function in
backend/port/win32/signal.c pg_usleep(), and put something like
#if defined(FRONTEND) || !defined(WIN32)
around the version in src/port/pgsleep.c? We don't really wa
That said I'm not sure how much I can do here. For a substantial index we
should expect most of the time will be spent in the tuplesort. It's hard to
see how to get any sort of progress indicator out of there and as long as we
can't it's hard to see the point of getting one during the heap scan
From: "Tom Lane"
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
Probably, this application will be required.
This seems very messy. The correct fix is just to put back the #include
line, no?
@@ -18,6 +18,7 @@
#include
#include "miscadmin.h"
+#include "postmaster/postmaster.h"
#include "stor
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Maybe we can show progress indicators in status line (either
> pg_stat_activity.current_query or commandline shown in ps), like
>
> WAITING TO START PHASE 1 - WAITING FOR TRANSACTION XXX TO COMPLETE
>
> or
>
> INSERTING INDEX ENTRY N OF M
>
> cha
"Hiroshi Saito" <[EMAIL PROTECTED]> writes:
> Probably, this application will be required.
This seems very messy. The correct fix is just to put back the #include
line, no?
regards, tom lane
---(end of broadcast)---
TIP 1:
Andrew Dunstan wrote:
> Someone at the conference mentioned a tool that would portably and
> reliably report system info such as architecture.
What's wrong with config.guess?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)--
Hi Tom-san.
I think that it should be in this way.
#include "postgres_fe.h"
#ifdef WIN32
#include "win32.h"
#endif
However, I am still under try by the reason for seeing the error of now a few.
Regards,
Hiroshi Saito
- Original Message -
From: "Tom Lane"
src/interfaces/libpq/win32
Andrew,
> Someone at the conference mentioned a tool that would portably and
> reliably report system info such as architecture. If someone has details
> I would like to have them, as it would help solve the buildfarm
> personality problem properly.
There's potentially two, actually. A SF start
Ühel kenal päeval, N, 2006-07-13 kell 01:07, kirjutas Greg Stark:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote:
> > > no regression tests yet.
> >
> > We'll need some performance tests that show that lock-hold time is
> > *actually* reduced,
Someone at the conference mentioned a tool that would portably and
reliably report system info such as architecture. If someone has details
I would like to have them, as it would help solve the buildfarm
personality problem properly.
cheers
andrew
---(end of broadcast
Ühel kenal päeval, R, 2006-07-14 kell 17:39, kirjutas Simon Riggs:
> On Fri, 2006-07-14 at 12:09 -0400, Tom Lane wrote:
> > "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> > > I've now thought about how to fix that without doing that rather crude
> > > rsync-pg_xlog-hack.
> > > I've read through
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> C function definition:
> PG_FUNCTION_INFO_V1(pgq3c_ang2ipix);
> Datum pgq3c_ang2ipix(PG_FUNCTION_ARGS)
> {
> static q3c_ipix_t ipix_buf;
> ipix_buf ++;
> elog(WARNING,"%lld",ipix_buf);
> return PointerGetDatum((&ipix_buf));
> }
Drew,
> Is there any interest in a basic perl script that would read through a
> postgresql.conf file and calculate approximate memory (and shared
> memory) usage? Also, are there any other (simple for now) things I
> should look at in the process? Asking because I'm getting annoyed with
> doing t
Josh Berkus wrote:
It's very nice to throw these things out there and put them on the TODO
list ... and if I had $100,000 in development money to throw at something, I
might spend it that way ... but to propose them as *immediate* solutions to
problems for 8.2 is fantasy.
Point taken. Obviou
All,
Several of us hashed this out at the Code Sprint. While the solution we
arrived at doesn't completely satisfy Greg, several others would be fine with
just having a version of pgsql-patches (pgsql-patches-lite?) that we could
subscribe to to get the messages without the attachments.
Also,
Lukas, all:
> So what I am suggesting is that PostgreSQL.org should push people
> towards the monolithic distro. The docs should contain everything that
> is in the monolithic distro. At conference we should say the name of the
> monolithic distro etc.
The issue I think you're ignoring is that ma
Tom Lane <[EMAIL PROTECTED]> writes:
> On the other side of the coin, there's the analogy to GROUP BY that Greg
> points out --- there's some duplicated functionality there, but again it
> doesn't carry over to DISTINCT ON, AFAICS.
The equivalent query for:
SELECT DISTINCT ON (x,y) a,b,c FROM .
We estimate 1 month for both us to complete these issues/todos and
1 month extra to write documentation, so we certainly are not ready
for 8.2, most probable 8.3. We're looking for sponsorship of our work.
Oleg
On Sat, 15 Jul 2006, Teodor Sigaev wrote:
tsearch2 is functionality that definitel
Hello, Hackers
I recently discovered that some my tables with the functional indices
have the wrong pg_stats records.
wsdb=# \d q3c
Table "public.q3c"
Column | Type | Modifiers
+--+---
ipix | bigint |
ra | double precisio
pgcheckdefines reports
src/port/getaddrinfo.c references HAVE_STRUCT_SOCKADDR_STORAGE_SS_LEN, defined
in src/include/libpq/pqcomm.h
I think this is an actual bug: if we have a platform that calls its
struct sockaddr_storage member __ss_len, and we are using our own
getaddrinfo code, we will fail
Hi
I had a urge to do a bit of hacking today, and so I tried to implement
my idea about an pg_rotate_wal for postgres 8.1. It's basically a huge
hack, and wastes io bandwith - but it doesn't need any patches to 8.1,
and can be compiled as an extension.
Here is the code (Included, because it's
src/interfaces/libpq/win32.c contains
/* Declared here to avoid pulling in all includes, which causes name
collissions */
#ifdef ENABLE_NLS
extern char *
libpq_gettext(const char *msgid)
__attribute__((format_arg(1)));
#else
#define libpq_gettext(x) (x)
#endif
Now, since it has nowhere bothered
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> iMath's protability checks failed. Attached patch drops them
> and expects postgres.h to give correct types.
> Also enable asserts to fail earlier.
Applied, thanks. Looks like this should fix current buildfarm
failure on "bear".
On Sat, Jul 15, 2006 at 09:34:57AM -0400, Andrew Dunstan wrote:
> Neil Conway wrote:
> >We could annotate the source to indicate that some functions are
> >deliberately intended to be externally visible, but not referenced
> >within the source tree, and then teach find_static to grok that
> >annota
Neil Conway wrote:
On Sat, 2006-07-15 at 00:05 -0400, Tom Lane wrote:
The fundamental problem with find_static is that it hasn't got a clue
about likely future changes, nor about what we think external add-ons
might want
We could annotate the source to indicate that some functions are
On 7/14/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I wrote:
> Applied, thanks. What I now see is that pgp-pubkey-decrypt passes on
> a 32-bit machine but dumps core on a 64-bit machine, with SIGSEGV here:
Addendum: seems it only fails without openssl.
iMath's protability checks failed. Attached
RenameRewriteRule, and I defer to Teodor about the gist and gin
functions. The others range somewhere between "no" and "hell no".
I think that gistcentryinit() and extractEntriesS() should not be a
static.
---(end of broadcast)---
TIP 9: In
29 matches
Mail list logo
