On Monday 16 July 2007 22:32:07 Shruthi A wrote:
> > > Please reply soon, this is an emergency..
This may be obvious, but a quick reply might call for commercial support.
Check out [1].
[1]http://www.postgresql.org/support/professional_support
wt
--
Warren Turkal (w00t)
--
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>>> The way this is handled in a number of other applications (putty being
>>> the one that comes to mind easily) is that two DLLs are built- one for
>>> SSPI and one for GSSAPI and you can easily switch between them on the
>>> cli
Was there any consensus on this change? It or something like it is necessary
to get gcov to work for contrib modules. I think adding all of $(CFLAGS) is
the correct thing to do on linux because if we're going to use $(CC) to link
then you don't know which of $(CFLAGS) might be necessary at link ti
On 7/14/07, Tom Lane <[EMAIL PROTECTED]> wrote:
I just noticed that when the BY option was added to plpgsql FOR loops,
no real error checking was done. If you specify a zero step value,
you'll have an infinite loop. If you specify a negative value, the
loop variable will increment in the "wrong
I think the tsearch documentation is nearing completion:
http://momjian.us/expire/fulltext/HTML/textsearch.html
but I am not happy with how tsearch is enabled in a user table:
http://momjian.us/expire/fulltext/HTML/textsearch-app-tutorial.html
Aside from the fact that it needs m
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this something for 8.3 or 8.4?
My goodness, you are a bit behind on the email. We fixed that a month ago.
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.
Is this something for 8.3 or 8.4?
---
Tom Lane wrote:
> The current discussion about the tsearch-in-core patch has convinced me
> that there are plausible use-cases for typmod values that aren't simple
> integers. For inst
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Michael Glaesemann wrote:
>
> On Jun 14, 2007, at 19:04 , [EMAIL PROTECTED] wrote:
>
> > For UUID, I
> > would valu
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Heikki Linnakangas wrote:
> We have these GUC variables that define a fraction of something:
>
> #autovacuum_vacuum_
Hi,
>
> I want to take a plan generated by the postgres optimizer and insert a
> constant in place of another constant in the plan. There is a function
> OidOutputFunctionCall( ) to get the constant. Similarly, is there any
> function to set the value of the constant? Also what does
> OidInputFu
Magnus, what is your reaction to this patch?
---
Hannes Eder wrote:
> Magnus Hagander wrote:
> >Hannes Eder wrote:
> >> Is it worth doing this the "Perl-way" and using File::Find? If so, I
> can
> >> work an a patch for
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> We could fix this either by changing the definition of
>> IsTransactionState() or by introducing another test function with
>> a different name. Any thoughts which is preferable?
> Is this done or should it be kept for 8.4?
Fixed, I
Is this done or should it be kept for 8.4?
---
Tom Lane wrote:
> I just noticed that there are a number of places (mostly GUC assignment
> hooks) that use IsTransactionState() to decide if it's safe for them to
> do catalog
I have added the CVS Wiki URL to our CVS docs section.
---
Greg Smith wrote:
> I've now finished up initial content generation on the wiki page that
> covers using the CVS repository:
>
> http://developer.postgresql.org/in
Gurjeet, do you have a patch to be applied for this?
---
Gurjeet Singh wrote:
> On 5/30/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Gurjeet Singh wrote:
> > >> But I did no
Where are we on this?
---
Tom Lane wrote:
> I just rearranged the code in mbutils.c a little bit to make it more
> robust if conversion of an over-length string is attempted, and noted
> this comment:
>
> /*
> * When conve
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> "pgstat.c", line 652: warning: const object should have initializer:
> all_zeroes (E_CONST_OBJ_SHOULD_HAVE_INITIZR)
> "pgstat.c", line 2118: warning: const object should have initializer:
> all_zeroes (E_CONST_OBJ_SHOULD_HAVE_INITIZR)
Man, eve
Zdenek Kotala wrote:
> Stefan Kaltenbrunner wrote:
>> Zdenek Kotala wrote:
>>> Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
> For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
> want to determine warning tags for each warning add -errtags.
Is that supporte
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Andrew Sullivan" <[EMAIL PROTECTED]> writes:
>>> I would say just set up a project on pgfoundry.
>
>> I agree, though I think in the long term we do need a more complete set of
>> operators and functions in cor
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> > The way this is handled in a number of other applications (putty being
> > the one that comes to mind easily) is that two DLLs are built- one for
> > SSPI and one for GSSAPI and you can easily switch between them on the
> > client. That'd work fine
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> Stephen Frost wrote:
>>> I'm not quite sure if that would affect what we do but it sounds like it
>>> might. The main thing we use on the clients wrt Postgres is the ODBC
>>> driver but I've used psql once or twice and have be
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Andrew Sullivan" <[EMAIL PROTECTED]> writes:
>> I would say just set up a project on pgfoundry.
> I agree, though I think in the long term we do need a more complete set of
> operators and functions in core.
Considering that BIT and BIT VARYING have b
"Andrew Sullivan" <[EMAIL PROTECTED]> writes:
> On Mon, Jul 16, 2007 at 09:40:18AM -0700, TJ O'Donnell wrote:
>> I would like to make these a part of postgresql for others to use.
>> Is it more appropriate for these to be in contrib code
>> or part of the postgresql proper?
>> How can I contribut
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> > I'm not quite sure if that would affect what we do but it sounds like it
> > might. The main thing we use on the clients wrt Postgres is the ODBC
> > driver but I've used psql once or twice and have been trying to get
> > peo
On Mon, Jul 16, 2007 at 09:40:18AM -0700, TJ O'Donnell wrote:
> I would like to make these a part of postgresql for others to use.
> Is it more appropriate for these to be in contrib code
> or part of the postgresql proper?
> How can I contribute these?
I would say just set up a project on pgfound
Stephen Frost wrote:
> * Magnus Hagander ([EMAIL PROTECTED]) wrote:
>> I've set it up as a different way of doing GSSAPI authentication. This
>> means that if you can't have both SSPI and MIT KRB GSSAPI in the same
>> installation. I don't see a problem with this - 99.9% of windows users
>> will ju
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
> I've set it up as a different way of doing GSSAPI authentication. This
> means that if you can't have both SSPI and MIT KRB GSSAPI in the same
> installation. I don't see a problem with this - 99.9% of windows users
> will just want the SSPI version an
A quick status update on the SSPI authentication part of the GSSAPI project.
I have libpq SSPI working now, with a few hardcoded things still in
there to be fixed. But it means that I can connect to a linux server
using kerberos/GSSAPI *without* the need to set up MIR Kerberos
libraries and settin
I have been working extensively with the bit string data type.
I have a number of useful c-language functions to
set/clear a bit, count number of bits set, inquire if
a bit is set/clear, etc.
I don't see functions like these as part of any SQL standard,
(although I think they ought to be).
I woul
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
Stefan Kaltenbrunner wrote:
Zdenek Kotala wrote:
For sun studio -erroff=E_STATEMENT_NOT_REACHED is useful there. If you
want to determine warning tags for each warning add -errtags.
Is that supported on all versions of sun studio(Sun WorkShop 6
On Mon, Jul 16, 2007 at 01:23:46PM +0100, Simon Riggs wrote:
> Both of these changes are simple enough to consider for 8.3
I'm in favour of scalability, of course, but are they really simple
enough to put in for 8.3? I was under the impression that there was
a push on to get the thing shipped, an
>> I'm happy to run some benchmarks to show the improvements with
various
>> NUM_BUFFER_PARTITIONS settings. However, I want to make sure that
this
>> is going to be useful. I can run 16 (base), 32, 64, 128 etc. type
>> increments, but I'm more concerned about the number of cores to use.
Do
>> you
"Strong, David" <[EMAIL PROTECTED]> writes:
> I'm happy to run some benchmarks to show the improvements with various
> NUM_BUFFER_PARTITIONS settings. However, I want to make sure that this
> is going to be useful. I can run 16 (base), 32, 64, 128 etc. type
> increments, but I'm more concerned abou
Tom,
I'm happy to run some benchmarks to show the improvements with various
NUM_BUFFER_PARTITIONS settings. However, I want to make sure that this
is going to be useful. I can run 16 (base), 32, 64, 128 etc. type
increments, but I'm more concerned about the number of cores to use. Do
you have a su
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I get with flex 2.5.4 is
>>
>> pgc.c: In function `base_yylex':
>> pgc.c:1564: warning: label `find_rule' defined but not used
>> preproc.y: At top level:
>> pgc.c:3818: warning: `yy_flex_realloc' defined but not used
>>
>>
Tom Lane wrote:
I really dislike that approach to deciding which functions to count.
The main problem with it is that it will try to count C-language
functions that are added after initdb, such as contrib stuff and
third-party add-ons like postgis. The percentage overhead for a
typical short C f
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> 2. Increase NUM_BUFFER_PARTITIONS from 16 to 256 (or higher).
Do you have any evidence to back up such a large increase?
This change is not free; at the very least it will break
contrib/pg_buffercache, which wants to lock all the partitions at once.
lwl
Tom Lane wrote:
Michael Meskes <[EMAIL PROTECTED]> writes:
On Wed, Jul 11, 2007 at 07:18:17PM -0400, Tom Lane wrote:
Now if we could only get rid of those flex-induced warnings in ecpg...
Don't you get the same in the backend's parser code? I surely do.
No, ecpg is the only one producing w
Andrew Dunstan wrote:
Joshua D. Drake wrote:
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
If I have 16 cores, things are still really loud but I start to not be
able to tell the difference. The percentage of improvement is much lower.
E.g, 16 cores works and Postgr
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Wed, Jul 11, 2007 at 07:18:17PM -0400, Tom Lane wrote:
>> Now if we could only get rid of those flex-induced warnings in ecpg...
> Don't you get the same in the backend's parser code? I surely do.
No, ecpg is the only one producing warnings for me.
Joshua D. Drake wrote:
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
+1 on the idea (I can speak to the technical side). What I can say
is that it
is pretty much known that after 8 cores we slow down. Although 8.2
is better
than any other release in this regard.
Wait
>Simon Riggs wrote:
>
>> Proposals
>>
>> 1. For the first result, I suggest that we introduce some padding
into
>> the shmem structure XLogCtlData to alleviate false sharing that may
>> exist between holders of WALInsertLock, WALWriteLock and info_lck.
The
>> cost of this will be at most about 200
On Wed, Jul 11, 2007 at 07:18:17PM -0400, Tom Lane wrote:
> Now if we could only get rid of those flex-induced warnings in ecpg...
Don't you get the same in the backend's parser code? I surely do.
It seems these are only missing prototypes. How about adding an include
file with those prototypes?
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
+1 on the idea (I can speak to the technical side). What I can say is that it
is pretty much known that after 8 cores we slow down. Although 8.2 is better
than any other release in this regard.
Wait, what benchmarks have you s
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> +1 on the idea (I can speak to the technical side). What I can say is that it
> is pretty much known that after 8 cores we slow down. Although 8.2 is better
> than any other release in this regard.
Wait, what benchmarks have you seen where we slow
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> This is intentional --- consider case where VACUUM has removed both
>> index and heap entries while some other (amazingly slow...) process is
>> in flight from the index to the heap.
> Hmm. In b-tree we keep the index page pinned
Simon Riggs wrote:
Proposals
1. For the first result, I suggest that we introduce some padding into
the shmem structure XLogCtlData to alleviate false sharing that may
exist between holders of WALInsertLock, WALWriteLock and info_lck. The
cost of this will be at most about 200 bytes of shmem, w
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> While looking at the HOT patch, I noticed that if there's an index tuple
>> pointing to a non-existing heap tuple, we just silently ignore it.
>
> This is intentional --- consider case where VACUUM has removed both
> index and hea
Ühel kenal päeval, E, 2007-07-16 kell 15:23, kirjutas Heikki
Linnakangas:
> While looking at the HOT patch, I noticed that if there's an index tuple
> pointing to a non-existing heap tuple, we just silently ignore it.
>
> Such dangling index entries of course means that your database is
> corrupt,
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> While looking at the HOT patch, I noticed that if there's an index tuple
> pointing to a non-existing heap tuple, we just silently ignore it.
This is intentional --- consider case where VACUUM has removed both
index and heap entries while some other
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think offhand that the correct semantics of the flag are "we have
>> redirected our original stderr into a pipe for syslogger",
> We could expose syslogger's redirection_done flag, which I think has the
> semantics you want.
Yeah,
While looking at the HOT patch, I noticed that if there's an index tuple
pointing to a non-existing heap tuple, we just silently ignore it.
Such dangling index entries of course means that your database is
corrupt, but we ought to handle that better. In the worst case, the heap
slot is inserted to
Tom Lane wrote:
I think offhand that the correct semantics of the flag are "we have
redirected our original stderr into a pipe for syslogger", and in
fact that we should transition the output format exactly at the
instant where we do that; the starting of the child process happens
at a slightl
> > Is there any reason we can't just use a check on whether
> SysLoggerPID
> > is not 0?
>
> (a) that really shouldn't be exported out of postmaster.c,
> and (b) it is not readily available to child backends is it?
Should there be child backends when the logger did not start ?
I'd think star
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> (a) that really shouldn't be exported out of postmaster.c, and (b) it is
>> not readily available to child backends is it?
> It's already used in elog.c in Win32 code:
> if ((!Redirect_stderr || am_syslogger ||
>
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is there any reason we can't just use a check on whether SysLoggerPID is
not 0?
(a) that really shouldn't be exported out of postmaster.c, and (b) it is
not readily available to child backends is it?
It's alrea
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Is there any reason we can't just use a check on whether SysLoggerPID is
> not 0?
(a) that really shouldn't be exported out of postmaster.c, and (b) it is
not readily available to child backends is it?
regards, tom lane
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> It's possible I've done the autoconf hackery wrong though. Should
> UINT64_FORMAT still be defined if there's no int64?
Yes.
regards, tom lane
---(end of broadcast)---
TIP 9: In ve
Do any of the build farm machines not support 64-bit integers? I just added a
--enable-bigint flag to configure.in and tested building without it and got an
error at xlog.c:
xlog.c: In function 'ValidXLOGHeader':
xlog.c:3240: error: 'UINT64_FORMAT' undeclared (first use in this function)
xlog.c:3
Neil Conway wrote:
(schemaname, procname, nargs) is still ambiguous in the face of function
overloading. Although the presence of procid uniquely identifies each
function anyway, if you're going to include the name and argument
information, it might be worth including the argument types as well
David Strong presented some excellent results of his SMP scalability
testing at Ottawa in May.
http://www.pgcon.org/2007/schedule/events/16.en.html
There are some easy things we can do to take advantage of those results,
especially the ones that were hardware independent.
The hardware independent
Tom Lane wrote:
I think we probably need a flag
variable separate from the GUC variable to tell when to send using
the chunk protocol.
Is there any reason we can't just use a check on whether SysLoggerPID is
not 0? It should only be set if the syslogger has in fact started.
c
62 matches
Mail list logo
