Here is an updated version of the patch from
http://candle.pha.pa.us/mhonarc/patches2/msg00025.html. It handles the
options for libpq connections the same way other options are handled,
and it also updates the kerberos documentation. It contains a couple of
minor changes to the Kerberos documentati
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
> (Actually, we could skinny it down to backend PID only ...
but that would add a hashtable lookup to every mess
Certainly seems that way. Missed a .diff for the rules output there...
Should be a simple replace, from what I can tell what's in the output on
the buildfarm boxes I checked is correct, the expected file shuold
changed.
Oops.
//Magnus
>
> Is this what broke the regression tests on HEAD?
>
> c
Is this what broke the regression tests on HEAD?
cheers
andrew
Neil Conway wrote:
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
> (Actually, we could skinny
Andrew Dunstan wrote:
Is this what broke the regression tests on HEAD?
Yes, it is -- fix checked in to HEAD. My apologies for missing this.
-Neil
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscr
tiny patch to test this feature.
cheers
andrew
Index: input/copy.source
===
RCS file: /home/cvsmirror/pgsql/src/test/regress/input/copy.source,v
retrieving revision 1.11
diff -c -r1.11 copy.source
*** input/copy.source 16 Mar 2005 06:0
Andrew Dunstan wrote:
tiny patch to test this feature.
Applied, thanks.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Tom Lane wrote:
> Bruce Momjian writes:
> > I looked over this item, originally posted as:
> > http://archives.postgresql.org/pgsql-hackers/2005-03/msg01055.php
>
> I still think this is substantial complication (more than likely
> introducing some bugs) to deal with a non problem.
>
> http:
Christopher Kings-Lynne wrote:
> Seems like an idea to me...
>
> On another note, what about the problem I pointed out where it's not
> possible to drop the default on a serial column after you alter it to a
> varchar, for example...
Uh, should we allow a columns data type to be changed if it h
Path withdrawn by author.
---
Christopher Kings-Lynne wrote:
> This patch updates psql and pg_dump to use the new copy api. Probably
> needs some review.
>
> I have tested it with dos and unix newlines, etc.
>
> Chris
C
Hi,
This is translation updates for branchs 7.4 and 8.0.
http://br.geocities.com/eulerto/nls_74_pt-br.tgz
http://br.geocities.com/eulerto/nls_80_pt-br.tgz
Please apply.
Euler Taveira de Oliveira
euler[at]yahoo_com_br
__
Converse com seus amigos
Satoshi Nagayasu wrote:
>
> Satoshi Nagayasu wrote:
> > I wanted to make the postmaster read-only, and found
> > "default_transaction_read_only" option, but it can be overwritten.
>
> I mean it can be overridden by the user. I don't want that.
I understand, but we haven't gotten enough requests
On Mon, May 09, 2005 at 10:13:22PM -0400, Bruce Momjian wrote:
> Satoshi Nagayasu wrote:
> >
> > Satoshi Nagayasu wrote:
> > > I wanted to make the postmaster read-only, and found
> > > "default_transaction_read_only" option, but it can be overwritten.
> >
> > I mean it can be overridden by the u
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > The ability to have PGDATA in read-only media (like CDs) has been
> > requested a lot of times, hasn't it?
>
> It's come up a few times ... more than an un-overridable read-only mode
> anyway. Also, I should think that those who wan
Alvaro Herrera wrote:
> On Mon, May 09, 2005 at 10:13:22PM -0400, Bruce Momjian wrote:
> > Satoshi Nagayasu wrote:
> > >
> > > Satoshi Nagayasu wrote:
> > > > I wanted to make the postmaster read-only, and found
> > > > "default_transaction_read_only" option, but it can be overwritten.
> > >
> >
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The ability to have PGDATA in read-only media (like CDs) has been
> requested a lot of times, hasn't it?
It's come up a few times ... more than an un-overridable read-only mode
anyway. Also, I should think that those who want a secure read-only
mode wa
Bruce Momjian writes:
> Having removed our security for not allowing override of things like
> log_statement, it seems we need a more general capability for
> controlling how something can be set that no one can change.
The initial implementation was definitely pretty broken, but I agree
we shoul
Bruce Momjian wrote:
>>It's come up a few times ... more than an un-overridable read-only mode
>>anyway. Also, I should think that those who want a secure read-only
>>mode want it enforced selectively --- for instance, assuredly read-only
>>for some users but not others. I can hardly
> As I mentioned before, I wanted to the read-only database mode.
> It is the per-database state.
>
> http://archives.postgresql.org/pgsql-hackers/2005-03/msg00540.php
>
> However, if it is not provided, we have to find alternative way
> to get our purpose.
>
> So I'm
This patch reduces the size of the message header used by statistics
collector messages, per recent discussion. This actually required quite
a few changes -- for example, "databaseid != InvalidOid" was used to
check whether a slot in the backend entry table was initialized, but
that no longer w
There were various locations in the code that were casting the first
argument to MemSet() or occasionally memset() to a char *. This is not
necessary, per C89: memset's first argument is a void * to begin with,
and there is an implicit conversion between void * and any other pointer
type.
I al
Neil Conway wrote:
I also noticed a bit of unclear / inconsistent code in MemSet() itself:
it's not obvious whether unary * or postfix ++ has higher precedence
(the latter does), so I added some parentheses to make this clear.
Okay, apparently I'm the only person who doesn't like code like this :
22 matches
Mail list logo