On Tue, 15 Jan 2008 16:11:16 -0600
"Roberts, Jon" <[EMAIL PROTECTED]> wrote:
> I need to set a basic password policy for accounts but I don't see any
> documentation on how to do it. I'm assuming there is a way to do this,
> maybe even with a trigger.
>
> The policy would be something like this:
"John Smith" <[EMAIL PROTECTED]> writes:
> Can someone clarify if WAL-logging of hash indexes will be supported
> in the 8.4 release?
There is absolutely 0 value in tackling that until someone can fix
hash's performance problems. If there is no real-world scenario for
using it ... which there rea
http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php,
"... I very much want to encourage authors of new Resource Managers and it
looks like we may be getting at least 3 new RMs that produce WAL
records: hash indexes (currently not WAL-logged), bitmap indexes and
clustered indexes for
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> In helping someome on IRC it has become apparent that unless I am
> mistaken "COPY foo from 'filename'" is reading the file according to the
> client encoding.
> Is that the expected behaviour?
Yes, it is. Not sure if it's adequately documented.
On Jan 15, 2008 4:25 AM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 14, 2008 at 10:12:55PM -0500, Jaime Casanova wrote:
> > On Jan 14, 2008 11:03 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > > Roberts, Jon wrote:
> > > > Version: PostgreSQL 8.2.5 on i686-pc-mingw32
> > > >
> > >
In helping someome on IRC it has become apparent that unless I am
mistaken "COPY foo from 'filename'" is reading the file according to the
client encoding.
Is that the expected behaviour? The client might have no influence at
all on the contents of the file. Offhand, I would have said that a
Roberts, Jon wrote:
I need to set a basic password policy for accounts but I don't see any
documentation on how to do it. I'm assuming there is a way to do this,
maybe even with a trigger.
The policy would be something like this:
1. Must contain letters and numbers
2. Must be at least 8 cha
I need to set a basic password policy for accounts but I don't see any
documentation on how to do it. I'm assuming there is a way to do this,
maybe even with a trigger.
The policy would be something like this:
1. Must contain letters and numbers
2. Must be at least 8 characters long
3. Must co
On Tue, 2008-01-15 at 16:37 -0500, Tom Lane wrote:
> Neither of those events could trigger it, because neither would be
> processed midstream during a COPY (in the current code, anyway).
OK, thanks.
> As best I can tell:
>
> * NOTICE messages are a risk, especially if you have a more-verbose-
>
I wrote:
> * ParameterStatus could be a risk if a function executed during COPY
> tried to change one of the above-mentioned parameters. Since COPY OUT
> doesn't fire triggers, I think user-defined datatype output functions
> would be the only possible candidates for that.
Scratch that --- that t
Simon Riggs <[EMAIL PROTECTED]> writes:
> That's what the docs say, but Tom's patch also adds lines to handle
> NOTIFY, which is what prompted the question.
I don't believe that code can get executed given the current backend
design. I just put it in because the protocol spec says (and always
has
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Hmm, aren't ParameterStatus messages sent just before Ready For Query?
No, they're sent immediately (see ReportGUCOption). I had some ideas
in the back of my head about postponing such sends until just before
Ready For Query, with the idea of avoiding
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Mon, 2008-01-14 at 18:46 +, Tom Lane wrote:
>> Fix an ancient oversight in libpq's handling of V3-protocol COPY OUT mode:
>> we need to be able to swallow NOTICE messages, and potentially also
>> ParameterStatus messages (although the latter would be
On Tue, 15 Jan 2008, Tom Lane wrote:
I think on most systems you'd have to explicitly tweak the /tmp-cleaning
script to know not to zap such a link. Given that such a local
customization would probably disappear in your next system update, the
security gain might be fleeting.
Right, on the
Gregory Stark <[EMAIL PROTECTED]> writes:
> I had another thought. Perhaps in use_assert_checking mode we should have it
> start from a random position every time. Or perhaps just a random position
> from amongst the first n pages.
Interesting idea, but I fear it'd make a lot of the regression tes
"Jeff Davis" <[EMAIL PROTECTED]> writes:
> On Mon, 2008-01-14 at 22:10 -0500, Tom Lane wrote:
>> It's a tossup from here. Anybody have a strong opinion one way or the
>> other?
>
> To me a heapscan means "read all the tuples" (without implying order)
> and an ordered heap scan is a special case t
On Mon, 2008-01-14 at 22:10 -0500, Tom Lane wrote:
> It's a tossup from here. Anybody have a strong opinion one way or the
> other?
>
To me a heapscan means "read all the tuples" (without implying order)
and an ordered heap scan is a special case that should be made explicit.
But this is not a s
Thank you, fixed.
Yoshiyuki Asaba wrote:
Hi,
I found a bug in ts_headline(). Here is a reproducible sql.
-- sql ---
SELECT substring(version(), 0, 20);
CREATE TEXT SEARCH PARSER dummy_parser (
START = prsd_start,
GETTOKEN = prsd_nexttoken,
END = prsd_end,
--
-- HEADLINE = prsd_he
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Gregory Stark wrote:
>> In a previous life I had a database which had daily partitions. I assure you
>> it was unquestionably the right decision. Each day's data wasn't just
>> distinguished by the timestamp but actually was entirely sepa
Hi,
(sorry for the previous one, if delivered, that went of too early...)
Zeugswetter Andreas ADI SD wrote:
Yes, but the problem with the timestamp partitioned tables is, that the
window is sliding. Thus you would need two alter tables for each new
period. One that changes the constraint + one
>>> On Mon, Jan 14, 2008 at 9:33 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> Yeah, all of this is about confusion and error-proneness. I still think
> that the real problem is that we don't have full control over
> client-side code, and therefore can't just write
Hi,
Zeugswetter Andreas ADI SD wrote:
Yes, but the problem with the timestamp partitioned tables is, that the
window is sliding. Thus you would need two alter tables for each new
period. One that changes the constraint + one that creates the new
partition. So it seems natural to join the two con
Doug,
This thread really should be moved to pgsql-performance mailing list. Thanks,
and good luck tuning Windows.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an app
Hi,
Tom Lane wrote:
DBAs tend to be belt *and* suspenders guys, no?
I rather know those admins with stupid looking faces who are wondering
why their transactions fail. Often enough, that can have a lot of
different reasons. Extending the set of possible traps doesn't seem like
a clever idea
> > I don't agree with that at all. I can imagine plenty of situations
> > where a tuple falling outside the range of available partitions
*should*
> > be treated as an error. For instance, consider timestamped
observations
> > --- data in the future is certainly bogus, and data further back
tha
Hi,
Gregory Stark wrote:
In a previous life I had a database which had daily partitions. I assure you
it was unquestionably the right decision. Each day's data wasn't just
distinguished by the timestamp but actually was entirely separate from the
previous day's data. Both the archiving strategy
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't agree with that at all. I can imagine plenty of situations
>> where a tuple falling outside the range of available partitions *should*
>> be treated as an error.
> Isn't it better to have these constraints as table const
Gregory Stark <[EMAIL PROTECTED]> writes:
> Here's something else which confused me just now. Why does the second query
> return NULL instead of an array slice?
Because it isn't a slice expression --- you used colon nowhere, so the
result type is going to be text not text[]. (Remember that the pa
On Tue, Jan 15, 2008 at 10:36:17AM -0500, Tom Lane wrote:
> Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> > Jeff Cohen wrote:
> >> If you don't define a "default" partition to handle outliers, the
> >> insert should fail with an error.
>
> > IMO, you should always have a "default" partition,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> One thing to be aware of is /tmp cleaners ...
>>
>> ... but that would definitely be a problem. I think on most systems
>> you'd have to explicitly tweak the /tmp-cleaning script to know not to
>> zap such a link. Given that such a
Hi,
I found a bug in ts_headline(). Here is a reproducible sql.
-- sql ---
SELECT substring(version(), 0, 20);
CREATE TEXT SEARCH PARSER dummy_parser (
START = prsd_start,
GETTOKEN = prsd_nexttoken,
END = prsd_end,
--
-- HEADLINE = prsd_headline,
--
LEXTYPES = prsd_lextype
);
C
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why do you find that surprising? It's either a slice or it isn't,
>> there's no halfway point. Are you proposing to throw an error if only
>> some of the subscripts have colons? What would be the point?
>
> What is confusing is if
"Markus Schiltknecht" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Hans-Juergen Schoenig wrote:
>>> What do you need so many partitions for?
>>
>> having so many tables is not funny but it can be the only reasonable choice.
>
> Well, what do you do with all those partitions?
In a previous life I had a
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Just for reference: who is it we're worried will check the old
> location? Any client using libpq will use the protected directory
> built into that.
Only if it's using the same copy of libpq that was built with the
server. Also, there are non-
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > One thing to be aware of is /tmp cleaners ...
>
> ... but that would definitely be a problem. I think on most systems
> you'd have to explicitly tweak the /tmp-cleaning script to know not to
> zap such a link. Given that such a lo
Hi,
Tom Lane wrote:
I don't agree with that at all. I can imagine plenty of situations
where a tuple falling outside the range of available partitions *should*
be treated as an error. For instance, consider timestamped observations
--- data in the future is certainly bogus, and data further ba
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Perhaps the easiest thing to do is to create a (possibly dangling)
> symlink in /tmp to the real socket in a protected dir.
Cute idea ...
> One thing to be aware of is /tmp cleaners ...
... but that would definitely be a problem. I think on most syst
Markus Schiltknecht <[EMAIL PROTECTED]> writes:
> Jeff Cohen wrote:
>> If you don't define a "default" partition to handle outliers, the
>> insert should fail with an error.
> IMO, you should always have a "default" partition, then, so as not to
> violate the constraints (by rejecting tuples wh
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > If any dimension is written as a slice, i.e. contains a colon, then all
> > dimensions are treated as slices.
>
> > Is the the behavior of assuming an entry with no colon is a slice what
> > we want, or are we just stuck with it?
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Yeah, all of this is about confusion and error-proneness. I still think
> >> that the real problem is that we don't have full control over
> >> client-side code, and therefore can't just write off the problem of a
Hi,
Hans-Juergen Schoenig wrote:
What do you need so many partitions for?
having so many tables is not funny but it can be the only reasonable choice.
Well, what do you do with all those partitions? Most of them will end up
on the same storage subsystem. So, if you don't partition to spread
On Mon, Jan 14, 2008 at 10:24:06PM -0500, Bruce Momjian wrote:
> Yea, I figured using protected directories for the socket was the
> zero-cost solution, and if you have to do SSL, might as well just use
> TCP too. (If you moved the socket file to a protected directory I think
> you could use exter
sure, but this can become really tedious for 1024 partitions,
Well, managing 1024 partitions manually is a tedious job, no matter
what grammar you take: You'll have to deal with 1024 different
partition names.
What do you need so many partitions for?
imagine a structure which is pa
We tried reducing the memory footprint of the postgres processes, via
shared_buffers (from 3 on Linux to 3000 on Windows), max_fsm_pages
(from 2000250 on Linux to 10 on Windows), max_fsm_relations (from
2 on Linux to 5000 on Windows), and max_connections (from 222 on
Linux to 100 on Win
* Alvaro Herrera <[EMAIL PROTECTED]> [080115 07:24]:
> Tom Lane wrote:
>
> > It strikes me that given the postmaster's infrastructure for listening
> > on multiple sockets, it would be a pretty small matter of programming
> > to teach it to listen on socket files in multiple directories not only
>
Hi,
Hannu Krosing wrote:
I guess it would go to some "default" partition ?
Which doesn't have a name so far, which prevents from addressing that
partition. Nor is it pretty well defined, it's just a rest.
sure, but this can become really tedious for 1024 partitions,
Well, managing 1024 p
On Mon, Jan 14, 2008 at 10:10:54PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >> I went through all of the heap_beginscan calls in the code last night.
> >> pgstattuple was broken but AFAICS none of the other callers care about
>
Ühel kenal päeval, E, 2008-01-14 kell 10:49, kirjutas Markus
Schiltknecht:
> Hi,
>
> Jeff Cohen wrote:
> > We did look at allowing general functions for partitioning and this was
> > one concern. The other is that we want to enforce that a row only gets
> > inserted into a single partition, so
Tom Lane wrote:
> It strikes me that given the postmaster's infrastructure for listening
> on multiple sockets, it would be a pretty small matter of programming
> to teach it to listen on socket files in multiple directories not only
> one.
The problem with this idea is that if the postmaster goe
Bruce Momjian wrote:
> My feeling on the moving of sockets risk is that you are probably going
> to have all your clients using the new socket directory before anyone
> tries to put something in /tmp, especially if you have the lock file in
> /tmp as outlined above. To spoof in such a situation y
On Mon, Jan 14, 2008 at 10:12:55PM -0500, Jaime Casanova wrote:
> On Jan 14, 2008 11:03 AM, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > Roberts, Jon wrote:
> > > Version: PostgreSQL 8.2.5 on i686-pc-mingw32
> > >
> > > I recently started getting this error message randomly, "could not open
> > >
On Tue, Jan 15, 2008 at 10:10:37AM +0100, Peter Eisentraut wrote:
> Am Montag, 14. Januar 2008 schrieb Tom Lane:
> > If we do want to apply Peter's patch, I think it needs to be extended so
> > that the default behavior on sockets is the same as before, ie, no SSL.
> > This could be done by giving
Am Montag, 14. Januar 2008 schrieb Tom Lane:
> If we do want to apply Peter's patch, I think it needs to be extended so
> that the default behavior on sockets is the same as before, ie, no SSL.
> This could be done by giving libpq an additional connection parameter,
> say "socketsslmode", having th
Hi Jeff,
Jeff Cohen wrote:
If you don't define a "default" partition to handle outliers, the
insert should fail with an error.
IMO, you should always have a "default" partition, then, so as not to
violate the constraints (by rejecting tuples which are correct according
to the constraints).
54 matches
Mail list logo