Andreas 'ads' Scherbaum wrote:
Andrew: your workaround was to create a domain which would use
0/1 ... this idea will not behave like a boolean, because it does not
accept 'true'/'false'.
My replacement boolean type does accept all this input values and does
emit 0/1 instead of 'f'/'t'. But sin
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2007-12-27 at 17:29 -0500, Tom Lane wrote:
>> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>>> then a subsequent postmaster start could initiate a second archiver
>>> process which would cause issues with whatever the first archiver is
>>> doing.
>>
On Thu, 27 Dec 2007 11:39:29 -0500 Andrew Dunstan wrote:
> Andreas 'ads' Scherbaum wrote:
> >>> i considered this one but this would only bring 0/1 as input, not as
> >>> output values, which is what i want.
> >>>
> >> er, what? This domain would have input and output values of 0/1.
> >>
On Thu, 2007-12-27 at 17:29 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What does postmaster do then? Sleep until archiver is done, or exit
> > immediately and hope that the archiver goes away as soon as it finishes?
>
> I think it can just exit immediately, particular
Ron Mayer wrote:
Or do you mean being able to perform parts of the query plan fully in
parallel? If this, then one would need a lot more than ParallelSort...
I wouldn't recommend that - it seems like a Hard Problem.
Isn't it the case that the implicit unions from processing partitioned
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What does postmaster do then? Sleep until archiver is done, or exit
> immediately and hope that the archiver goes away as soon as it finishes?
I think it can just exit immediately, particularly if we invent the
variant signal for "archive what you can
Tom Lane wrote:
> ISTM the postmaster should leave the archiver alone at the
> PM_WAIT_BACKENDS -> PM_SHUTDOWN transition, and instead send it
> a WAKEN signal (SIGUSR1) when it sees normal exit of the bgwriter.
> That will afford an opportunity to archive anything that was pushed
> out during the
Stephen Frost wrote:
> It'd be really nice to be able to have client-side certificates used for
> authentication by having a way to associate a certificate (or maybe at
> least the DN, but you can have dups) to a user. That's a seperate
> conversation tho, really.
Absolutely, but as you say a com
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Most Linux distros don't have SELinux, AFAIK, so this is probably not a
> very useful suggestion. Not that I have a problem with Red-Hat-specific
> solutions ;-)
Debian also has SELinux, if one wishes to configure it. I suspect other
Debian-derived distrib
Simon Riggs <[EMAIL PROTECTED]> writes:
> ...based upon limitations of the existing system. We have been
> SIGQUIT'ing the archiver, and there is a comment there to say how
> important it is that we *do not* try to finish processing before we
> quit. If you think that comment is wrong, thats OK by
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> I have no problem with that. But it does seem to me that we are going
>> about this all wrong. The OP proposed a "solution" which was intended to
>> ensure at the server end that an untrusted user could not spoof the
>> postmaster i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have no problem with that. But it does seem to me that we are going
> about this all wrong. The OP proposed a "solution" which was intended to
> ensure at the server end that an untrusted user could not spoof the
> postmaster if the postmaster were
On Thu, 2007-12-27 at 15:29 -0500, Tom Lane wrote:
> As of CVS HEAD, the behavior after the postmaster receives a shutdown
> request and has seen its last regular-backend child die is:
...based upon limitations of the existing system. We have been
SIGQUIT'ing the archiver, and there is a comment
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Sure. But we *do* provide a way to work around it *if you have to*: use
SSL with trusted certificates. In the large number of cases where you
*don't* need to worry about it, there's no need to add any extra overhead.
And
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Sure. But we *do* provide a way to work around it *if you have to*: use
> SSL with trusted certificates. In the large number of cases where you
> *don't* need to worry about it, there's no need to add any extra overhead.
> And if you're going with SSL
Magnus Hagander wrote:
> > How expensive would it be to implement a "server_user" db open parameter
> > that would perform reverse credential passing to validate? "dbname=XXX
> > port=5432 server_user=postgres". If the server can't prove it is
> > postgres through UNIX socket credential passing, it
The problem complained of in bug #3843 was something I'd noticed a few
days ago and meant to fix. ISTM the recent change to have the archiver
outlive the postmaster was incompletely thought out, and we really need
to take two steps back and reconsider, if we want to fix it so it works.
As of CVS H
Tomasz Ostrowski wrote:
> On Sun, 23 Dec 2007, Tom Lane wrote:
>> 3. Massive confusion and breakage as various people transition to the
>> new standard at different times.
>
> As with any major version.
No, it would introduce a client/server incompatibility. Generally, older
clients (libpq) will
Mark Mielke wrote:
> I prefer UNIX sockets with kernel credential passing over TCP/IP with
> username/password or the more expensive SSL. I do not like storing
> passwords or private certificates in a place available to the web user,
> as other web users would then also have access. I do not have e
Andrew Sullivan wrote:
> On Sun, Dec 23, 2007 at 09:52:14PM +0100, Magnus Hagander wrote:
>> My point is that all these other server products have the exact same
>> issue. And that they deal with it the exact same we do - pretty much
>> leave it up to the guy who configure the server to realize tha
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I think at minimum we need to forbid b, f, n, r, t, v, which are the
control character representations currently recognized by COPY.
But I'm tempted to make it reject all 26 lower-case ASCII letters,
as a form
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think at minimum we need to forbid b, f, n, r, t, v, which are the
>> control character representations currently recognized by COPY.
>> But I'm tempted to make it reject all 26 lower-case ASCII letters,
>> as a form of future-proofi
On Sun, Dec 23, 2007 at 01:45:14AM -0500, Tom Lane wrote:
>
> The primary reason things work like that is that there are boatloads of
> machines that are marginally misconfigured. For instance, userland
> thinks there is IPv6 support when the kernel thinks not (or vice versa).
Not only "marginal
On Mon, Dec 24, 2007 at 12:04:16AM +0100, Tomasz Ostrowski wrote:
>
> Not at all, as it won't run as root, it'll just start as root and
> then give up all root privileges. The only thing it would have after
> being root is just an open socket.
If you think that is complete protection against priv
On Sun, Dec 23, 2007 at 09:52:14PM +0100, Magnus Hagander wrote:
> My point is that all these other server products have the exact same
> issue. And that they deal with it the exact same we do - pretty much
> leave it up to the guy who configure the server to realize that's just
> how things work.
Tom Lane wrote:
Currently, copy.c rejects newline, carriage return, and backslash as
settings for the column delimiter character (in non-CSV mode). These
all seem necessary to avoid confusion. However, I just noticed that the
letters r, n, t, etc would also not work: on output, data character
Andreas 'ads' Scherbaum wrote:
i considered this one but this would only bring 0/1 as input, not as
output values, which is what i want.
er, what? This domain would have input and output values of 0/1.
Yes, but i will loose 't', 'true', 'f' and 'false', the usual input
values in
Currently, copy.c rejects newline, carriage return, and backslash as
settings for the column delimiter character (in non-CSV mode). These
all seem necessary to avoid confusion. However, I just noticed that the
letters r, n, t, etc would also not work: on output, data characters
matching such a de
On Thu, 27 Dec 2007 08:52:15 -0500 Andrew Dunstan wrote:
> Andreas 'ads' Scherbaum wrote:
> > On Wed, 26 Dec 2007 20:20:59 -0500 Andrew Dunstan wrote:
> >
> > This PHP driver is in use since years, do you really expect they will
> > fix this bug and make thousands of applications fail? Everyone li
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Ron Mayer
>Sent: Wednesday, 19 December 2007 19:26
>To: Mark Mielke; pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] Sorting Improvements for 8.4
>
>> Or do you mean being able to perform parts of the
Andreas 'ads' Scherbaum wrote:
On Wed, 26 Dec 2007 20:20:59 -0500 Andrew Dunstan wrote:
Andreas 'ads' Scherbaum wrote:
The reason for my question is: PHP (yes *grumble*) does not recognize
boolean columns but instead makes a simple string from a PG boolean.
So every time you select
Am Donnerstag, 20. Dezember 2007 schrieb Tom Lane:
> I think it's reasonable even for COPY TO, since IMHO the odds that it's
> a typo, rather than intentional, are probably 100:1.
ISTM that with this line of argument we could disable thousands of valid uses
of SQL commands.
--
Peter Eisentraut
On Wed, 26 Dec 2007 20:20:59 -0500 Andrew Dunstan wrote:
>
> Andreas 'ads' Scherbaum wrote:
> > The reason for my question is: PHP (yes *grumble*) does not recognize
> > boolean columns but instead makes a simple string from a PG boolean.
> >
> > So every time you select a boolean column in PHP,
On Sun, 23 Dec 2007, Tom Lane wrote:
> ISTM we have these action items:
> 1. Improve the code so that SSL authentication can be used across a
> Unix-socket connection (we can disable encryption though).
I've just realised that there's a problem with SSL with disabled
encryption on a unix socket /
34 matches
Mail list logo
