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).
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 the
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 libpq
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
relation
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 goes
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 you
Ü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 we
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
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
the visitation
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
* 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
one.
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
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
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
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
client
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?
Why do
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 which are
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
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 systems
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 local
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
);
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 I see
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 local
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, then, so as not
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
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 database which
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
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 constraints,
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
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
than
you
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
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
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
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 off the
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
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 separate from
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 =
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
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 that should be
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 tests
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
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 a bit
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:
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
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
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 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
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
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
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
I recently started
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
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 really
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:
1.
54 matches
Mail list logo
