* D'Arcy J.M. Cain (darcy@druid.net) wrote:
On Thu, 28 Sep 2006 12:44:24 -0400
Stephen Frost [EMAIL PROTECTED] wrote:
I'm not sure about 'money' in general but these claims of great
performance improvments over numeric just don't fly so easily with me.
numeric isn't all *that* much slower
Greetings,
The array_accum example aggregate in the user documentation works
reasonably on small data sets but doesn't work too hot on large ones.
http://www.postgresql.org/docs/8.1/static/xaggr.html
Normally I wouldn't care particularly much but it turns out that PL/R
uses arrays for
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Long story short, I set out to build a faster array_accum. Much to my
suprise and delight, we already *had* one. accumArrayResult() and
makeArrayResult()/construct_md_array() appear to do a fantastic job
* Stephen Frost ([EMAIL PROTECTED]) wrote:
For comparison, the new functions run with:
time psql -c select aaccum(generate_series) from
generate_series(1,100); /dev/null
4.24s real 0.34s user 0.06s system
Compared to:
time psql -c select array_accum
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
I was hoping to do that, but since it's an aggregate the ffunc format is
pre-defined to require accepting the 'internal state' and nothing else,
and to return 'anyelement' or 'anyarray' one of the inputs must
* Stephen Frost ([EMAIL PROTECTED]) wrote:
I'm going to be running a very large query shortly using
this aaccum and will report back how it goes.
It went *very* well, actually much better than I had originally
expected. This query used to take over 12 hours to complete (about 11
of which
Greetings,
First, a quick digression into what I've gleaned from the spec in
terms of implementation, from SQL2003:
-- Table-level grants. The spec basically says that a table-level
-- grant is as if the same grant was done on all existing and future
-- columns. (I
* Jaime Casanova ([EMAIL PROTECTED]) wrote:
On Fri, Aug 22, 2008 at 10:19 PM, Bruce Momjian [EMAIL PROTECTED] wrote:
Added to September commit fest.
updating the patch with one that only extends inserts. though, i
haven't look at the col level privs patch yet.
At least initially I
Greetings,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
Comments welcome, apologies for it not being ready by 9/1. I'm
planning to continue working on it tomorrow, and throughout September
as opportunity allows (ie: when Josh isn't keeping me busy).
Here is an updated patch. I've added
* Tom Lane ([EMAIL PROTECTED]) wrote:
=?ISO-8859-1?Q?Benedek_L=E1szl=F3?= [EMAIL PROTECTED] writes:
pg_dumpall now just passes the --role option to pg_dump. What do you
think, is it enough
or it should issue the SET ROLE TO ... command in its own session too?
I think it would have to,
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Jaime Casanova ([EMAIL PROTECTED]) wrote:
updating the patch with one that only extends inserts. though, i
haven't look at the col level privs patch yet.
At least initially I wasn't planning to support
Jaime,
* Jaime Casanova ([EMAIL PROTECTED]) wrote:
On 7/25/08, Stephen Frost [EMAIL PROTECTED] wrote:
Yes, I'm working on it
hi, any work on it? may i help?
If you look at the commitfest, I've posted my WIP so far there. Most of
the grammer, parser, and catalog changes are there. There's
Hi Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Comments welcome, apologies for it not being ready by 9/1. I'm
planning to continue working on it tomorrow, and throughout September
as opportunity allows (ie: when Josh isn't keeping me busy).
I'm trying
* Gregory Stark ([EMAIL PROTECTED]) wrote:
The other reason to think NOTICE might be better is that it's something which,
if it occurs once, will always occur for that database. So a sysadmin will
become inured to seeing WARNING on his backups. Are there any other warning
conditions which
Greetings,
I've reviewed the patch here:
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
and am happy to report that it looks to be in good order. It has
documentation and regression updates, is in context diff format,
patches against current CVS with only some minor fuzz,
Jaime,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
* Jaime Casanova ([EMAIL PROTECTED]) wrote:
On 7/25/08, Stephen Frost [EMAIL PROTECTED] wrote:
Yes, I'm working on it
hi, any work on it? may i help?
If you look at the commitfest, I've posted my WIP so far there. Most
* Tom Lane ([EMAIL PROTECTED]) wrote:
I can think of a way around that: represent a default expression using
classid = OID of pg_attribute, objid = OID of table, objsubid = column
attnum. This is distinct from the column itself, which is represented
with classid = OID of pg_class. It seems
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
If we were to accept the pg_attrdef approach, why aren't we
doing a pg_attracl table instead of adding a column to pg_attribute?
That's actually not an unreasonable question. If you were to do that
then you
Tom,
* Tom Lane ([EMAIL PROTECTED]) wrote:
Markus Wanner [EMAIL PROTECTED] writes:
ISTM that we should at least combine defaults and ACLs then, as proposed
by Stephen.
Huh? Maybe I missed something, but I didn't think that was suggested
anywhere.
I had suggested a single table, with an
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
What does the subobject column for pg_shdepend buy us?
Tracking column-level ACL dependencies rather than having those
dependencies only be at the table-level. This complicates
pg_shdepend some, but simplifies the dependency handling in the
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
* Markus Wanner ([EMAIL PROTECTED]) wrote:
What does the subobject column for pg_shdepend buy us?
Tracking column-level ACL dependencies rather than having those
dependencies only be at the table-level. This complicates
* Gregory Stark ([EMAIL PROTECTED]) wrote:
Robert Haas [EMAIL PROTECTED] writes:
CREATE AGGREGATE array_accum (anyelement)
CREATE OR REPLACE FUNCTION array_enum(anyarray)
Have you actually tried these functions on large data sets? They're not in the
same performance league as intagg.
Jeff,
* Jeff Davis ([EMAIL PROTECTED]) wrote:
2) ARRAY_ACCUM() -- Returns empty array on no input, and includes NULL
inputs.
Excellent.. I added it the easy way (from the online docs), but that's
clearly not at all efficient and was going to try and fix it, for psql
to use with the
KaiGai, et al,
* KaiGai Kohei ([EMAIL PROTECTED]) wrote:
Stephen, what is the status of your efforts?
I've now got it passing the base regression tests with the actual logic
included in the path. That doesn't mean it works completely, of course,
but I feel like I'm making progress. Feedback,
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Sorry, this took way longer than planned.
Beleive me, I understand. :)
testdb=# GRANT TRUNCATE (single_col) ON test TO malory;
GRANT
This has been fixed in the attached patch.
Some privilege regression tests currently fail with your
Markus, et al,
* Stephen Frost ([EMAIL PROTECTED]) wrote:
I also wonder if you could use joins or something
to extract information about columns you're not supposed to have access
to, or where clauses, etc..
welp, I've done some additional testing and there's good news and bad, I
suppose
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
... A case I just realized might be an issue is
doing a 'select 1 from x;' where you have *no* rights on x, or any
columns in it, would still get you the rowcount.
Well, if you have table-level select on x, I
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
... A case I just realized might be an issue is
doing a 'select 1 from x;' where you have *no* rights on x, or any
columns in it, would still get you the rowcount.
Well, if you have table-level select on x, I
Markus,
* Markus Wanner ([EMAIL PROTECTED]) wrote:
Stephen Frost wrote:
Attached patch has this fixed and still passes all regression tests,
etc.
Do you have an up-to-date patch laying around? The current one conflicts
with some CVS tip changes.
No, not yet. I suspect the array_agg
Alvaro,
* Alvaro Herrera ([EMAIL PROTECTED]) wrote:
I had a look at aclchk.c and didn't like your change to
objectNamesToOids; seems rather baroque. I changed it per the attached
patch.
I've incorporated this change.
Moreover I didn't very much like the way aclcheck_error_col is dealing
* Robert Haas (robertmh...@gmail.com) wrote:
One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code.
I've really got to take exception to this. I've only been
* Greg Smith (g...@2ndquadrant.com) wrote:
I personally feel that Steven
Frost's recent comments here about how the PostgreSQL code makes this
harder than it should be really cuts to the core of a next step here.
The problem facing us isn't is SEPostgreSQL the right solution for
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
It's been perfectly clear since day one, and was reiterated as recently
as today
http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
that what the security community wants is row-level security.
Yes, they do want row-level
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
(1) Whether the framework should host the default PG model, not only
enhanced security features, or not?
This patch tried to host both of the default PG model and SELinux.
But, the default PG model does not have same origin with
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
On Fri, Dec 11, 2009 at 05:45, Tom Lane t...@sss.pgh.pa.us wrote:
It's been perfectly clear since day one, and was reiterated as recently
as today
http://archives.postgresql.org/message-id/4b21757e.7090...@2ndquadrant.com
that what
David,
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
So I downloaded and read through the PCI DSS document (74 pages is
pretty light compared to NFSv4.1 hehe...) and There are several areas
there where I think strong access controls in the database will not only
fulfill the requirement
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
On Fri, 2009-12-11 at 09:32 -0500, Robert Haas wrote:
I think that we should try to move the PG default checks inside the
hook functions. If we can't do that cleanly, it's a good sign that
the hook functions are not correctly placed to
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
As Rober Haas already suggested in another message, my patch in the last
commit fest is too large. It tried to rework anything in a single patch.
The per-object-type basis make sense for me.
Agreed.
In my cosmetic preference, ace_ is
Greg,
* Greg Smith (g...@2ndquadrant.com) wrote:
I think we need a two pronged attack on this issue. Eventually I think
someone who wants this feature in there will need to sponsor someone
(and not even necessarily a coder) to do a sizable round of plain old
wording cleanup on the
* Robert Haas (robertmh...@gmail.com) wrote:
I'll stop here because I see that Stephen Frost has just sent an
insightful email on this topic as well. Hmm, maybe that's the Steve
you were referring to.
I have doubts- but then I don't ever see my comments as insightful for
some reason
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
I actually have an idea how to solve the problem in this particular
case, but I'm reluctant to say what it is because I'm not sure if I'm
right, and at any rate *I don't want to write this patch*.
As far as crap goes, I'd have to put this
All,
* Robert Haas (robertmh...@gmail.com) wrote:
If we design a security abstraction layer, the interfaces need to
really be abstraction boundaries. Passing the table OID and then also
the tablespace OID because PG DAC needs that to make its access
control decision is crap.
Now, to
David,
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
So the document I read is linked below [1].
Great, thanks again.
[agree with all the rest]
It is definitely good to have a second opinion on this since I've just
only started reading the PCI compliance documents. I'm definitely not an
* David P. Quigley (dpqu...@tycho.nsa.gov) wrote:
Yea I never asked Stephen if he goes by Stephen or Steve when I met him
on Wednesday. I guess calling him Steve is me being a bit
presumptuous :)
Oh, either is fine, tho people will probably follow a bit better if you
say Stephen. As a
Josh,
* Joshua Brindle (met...@manicmethod.com) wrote:
Stephen Frost wrote:
I do think that, technically, there's no reason we couldn't allow for
multiple only-more-restrictive models to be enabled and built in a
single binary for systems which support it. As such, I would make those
just
* Robert Haas (robertmh...@gmail.com) wrote:
OK, it's clear that I've handled this badly. Sorry. My fear (however
unjustified) was that someone would go and rewrite the patch based on
an opinion that I express whether they agree with it or not.
That's always going to be a risk in an
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Dec 11, 2009 at 2:11 PM, Stephen Frost sfr...@snowman.net wrote:
Second, the information we *don't* have from above is generally
information about what the requesting action is. For example, when
changing ownership of an object, we can't
Stephen (great name!),
* Stephen Smalley (s...@tycho.nsa.gov) wrote:
Reference:
http://www.usenix.org/event/sec02/wright.html
http://lxr.linux.no/#linux+v2.6.32/include/linux/security.h
The XACE framework for the X server is described by:
* Robert Haas (robertmh...@gmail.com) wrote:
If I don't tell
you how to write the patch, you can't accuse me of moving the
goalposts (of course I've now discovered the pitfalls of that approach
as well...).
Indeed, we also yell and scream when we don't know which direction the
goalposts are
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Dec 11, 2009 at 4:26 PM, Stephen Frost sfr...@snowman.net wrote:
Does that help clarify my example case?
That case doesn't seem terribly problematic to me. It seems clear
that we'll want to pass some information about both x and y. What
* Robert Haas (robertmh...@gmail.com) wrote:
Allow me to assist- y is never in a structure once you're out of the
parser:
Well this is why you're writing the patch and not me. :-)
Sure, just trying to explain why your suggestion isn't quite the
direction that probably makes the most
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas robertmh...@gmail.com writes:
What exactly do you mean by a SubOID? I'm not really following that part.
I assume he's talking about the object reference representation used in
pg_depend, which is actually class OID + object OID +
* Stephen Frost (sfr...@snowman.net) wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I assume he's talking about the object reference representation used in
pg_depend, which is actually class OID + object OID + sub-object ID.
The only object type that has sub-objects at the moment is tables
Greetings,
I'll start a new thread on this specific topic to hopefully pull out
anyone who's focus is more on that than on SEPG.
Row-Level security has been implemented in a number of existing
commercial databases. There exists an implementation of row-level
security for PostgreSQL today in
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
Please comment, update the wiki, let us know you're interested in this..
Good start, however, could you defer the discussion after the Feb-15?
My hands are now full in the security framework and SE-PgSQL/Lite. :(
While I'm glad you're
* Bruce Momjian (br...@momjian.us) wrote:
I am not replying to many of these emails so I don't appear to be
brow-beating (forcing) the community into accepting this features. I
might be brow-beating the community, but I don't want to _appear_ to be
brow-beating. ;-)
My apologies if I come
KaiGai,
* KaiGai Kohei (kai...@kaigai.gr.jp) wrote:
The reason why I put on the security hook in ExecScan() is to avoid the
problem that row-cost user defined function can be evaluated earlier
than row-level security policy. (I believed it was a well-known problem
at that time yet.) So, I
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
IIRC, one headache issue is that user may provide well indexable conditions,
such as SELECT * FROM view_x WHERE id = 1234. In this case, if we strictly
keep the order of evaluation between inside and outside of the view, its
performance
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
You are fine. I was just saying that at a time I was one of the few
loud voices on this, and if this is going to happen, it will be because
we have a team that wants to do this, not because I am being loud. I
see the team forming nicely.
Not
* Robert Haas (robertmh...@gmail.com) wrote:
I think there was a previous discussion of this when Heikki first
posted the issue to -hackers.
There was, it's now linked off the http://wiki.postgresql.org/wiki/RLS
page (as well as this thread). Feel free to add other threads, update
with your
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
The patch was not attached...
This patch either does too much, or not enough.
I would either leave the Assert() in-place as a double-check (I presume
that's why it was there in the first place, and if that Assert() fails
then our assumption
* Tom Lane (t...@sss.pgh.pa.us) wrote:
KaiGai Kohei kai...@ak.jp.nec.com writes:
[ patch to remove EnableDisableRule's permissions check ]
I don't particularly like this patch, mainly because I disagree with
randomly removing permissions checks without any sort of plan about
where they
* Robert Haas (robertmh...@gmail.com) wrote:
Disentangling that seems like a job and a half.
Indeed it will be, but I think it would be a good thing to actually have
a defined point at which permissions checking is to be done. Trying to
read the code and figure out what permissions you need to
* Rod Taylor (rod.tay...@gmail.com) wrote:
I (stupidly?) installed PostgreSQL into a hostile environment which
didn't like this and decided to kill the processes as a result.
Unfortunately, I cannot change the environment.
That's not hostile, that's broken.
Stephen
signature.asc
* Josh Berkus (j...@agliodbs.com) wrote:
What I'm getting from your e-mail, Dave, is If it doesn't solve all
problems for everyone in the world from Day 1, it's not worth doing.
It's my experience that the way to get OSS software that works is to
build a little bit at a time, each delivery of
* Dave Page (dp...@pgadmin.org) wrote:
Because if we (PostgreSQL) are going to support this effort, then it
should not ignore such a huge percentage of our installation base.
Not doing it day 1 is not ignoring. It's using what resources *are*
being made available to the best extent we can. If
* David Fetter (da...@fetter.org) wrote:
OK, we have a proposal on the table to bump some patches from this
CommitFest to free up more committer resources, particularly Tom, to
work on Hot Standby and Streaming Replication and attempt to
accelerate the process of getting 8.5 out the door.
Dave,
* Dave Page (dp...@pgadmin.org) wrote:
Right - but the buildfarm isn't a feature being offered to end users.
And this network isn't a feature of the core code either, nor, do I
believe, is it being designed in a way that would require an overhaul
down the road to support Windows. To be
* Magnus Hagander (mag...@hagander.net) wrote:
Do we need to make the value configurable? I'd certainly find it
interesting to set backends to say 5 or something like that, that
makes them less likely to be killed than any old oops opened too big
file in an editor-process, but still possible
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I don't want to go to the trouble of creating (and documenting) a
configure option for this. Much less a GUC ;-)
Requiring a custom build to disable it would be horrible, in my view.
Or, at best, just means that the packagers won't enable it, which
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Alex Hunsaker bada...@gmail.com writes:
On Fri, Jan 8, 2010 at 07:27, Tom Lane t...@sss.pgh.pa.us wrote:
Then, somebody who wants the feature would build with, say,
-DLINUX_OOM_ADJ=0
or another value if they want that.
Here is a stab at
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
It also seems to call into question the wisdom of annual releases.
If we had a two-year cycle which had three times as much in it,
would that be an improvement, or not?
At the moment, my vote would be how 'bout we discuss this post-8.5?.
Alex,
* Alex Hunsaker (bada...@gmail.com) wrote:
As long as the VM/container you are running under wont kill postmaster
for trying to access proc-- the patch I posted should work fine. It
just ignores any error (I assumed you might be running in a chroot
without proc or some such).
As I
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Alex Hunsaker bada...@gmail.com writes:
Sure this was openssh? I just looked through the entire cvs history
for opensshp and found 0 references to 'oom' let alone 'oom_adj'.
Maybe something distro specific?
FWIW, I see no evidence that sshd on
Magnus,
* Magnus Hagander (mag...@hagander.net) wrote:
The attached patch implements RADIUS authentication (RFC2865-compatible).
Great! We have a few environments which use RADIUS auth, nice that PG
might be able to use that auth method in the future.
I'm not a fan of having the shared
* Jaime Casanova (jcasa...@systemguards.com.ec) wrote:
if it's not broken, then it doesn't need a fix...
if that code is causing a hole in security then i said remove it, if
not... what's the problem in let it be until we know exactly what the
plan is?
The chances of getting concensus on an
* Alex Hunsaker (bada...@gmail.com) wrote:
On Wed, Jan 13, 2010 at 12:54, Tom Lane t...@sss.pgh.pa.us wrote:
I'm a little worried by Stephen's plan, mainly because I'm concerned
that it would lead to ALTER TABLE taking exclusive lock on a table long
before it gets around to checking
* Alex Hunsaker (bada...@gmail.com) wrote:
On Wed, Jan 13, 2010 at 13:46, Alex Hunsaker bada...@gmail.com wrote:
Im of the opinion if we are going to be meddling with the permission
checks [...]
Specifically:
http://archives.postgresql.org/pgsql-hackers/2009-05/msg00566.php
Sounds like
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
Some of ALTER TABLE operations take multiple permission checks, not only
ownership of the relation to be altered.
Yes, exactly my point. Those places typically just presume that the
owner check has already been done.
For example, ALTER TABLE with
* Dave Page (dp...@pgadmin.org) wrote:
Wait for it
9.0.
Sure, tell us now, after we've all already had to submit our 8.5-related
talks for PGCon... ;)
Thanks!
Stephen
signature.asc
Description: Digital signature
* Magnus Hagander (mag...@hagander.net) wrote:
IIRC Stephen had some other reason, but I'll leave it to him to
fill that in :-)
I was really looking for multi-server support as well, and support
for a config-file format that's commonly used for RADIUS. I'll
take a whack at doing that this
All,
* Joshua D. Drake (j...@commandprompt.com) wrote:
On Thu, 2010-03-04 at 11:23 -0500, Tom Lane wrote:
I'm not sure offhand about a reasonable way to rearrange the code to
avoid duplicate messages.
Perhaps just add what can't be revoked? meaning:
WARNING: no privileges could be
* Tom Lane (t...@sss.pgh.pa.us) wrote:
One thought is that the column cases should be phrased more like
no privileges could be revoked for column foo of table bar
Check the messages associated with DROP cascading for the canonical
phrasing here, but I think that's what it is.
Looks like
* Joseph Adams (joeyadams3.14...@gmail.com) wrote:
I propose adding application-level access control to PostgreSQL via a
jails concept. In a nutshell, a jail is created as part of the
database definition (typically exposing a free variable for the
current user). When a jail is activated for
* Robert Haas (robertmh...@gmail.com) wrote:
Sometimes it would be nice to conditionalize queries on a value other
than the authenticated role. I really wish we had some kind of SQL
variable support. Talking out of my rear end:
I certainly agree- having variable support in the backend would
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
So instead of the typical reject instruction we also add a
rejectverbose instruction that has a more verbose message. Docs would
describe it as an additional instruction to assist with debugging a
complex pg_hba.conf, with warning that if
* Robert Haas (robertmh...@gmail.com) wrote:
The first version is a lot more common and as it turns out, is sometimes
very hard to spot. This patch attaches a HINT message to these two
cases. The message itself could probably be a lot better, but I can't
think of anything.
Thoughts?
* Simon Riggs (si...@2ndquadrant.com) wrote:
I guarantee that if that proposal goes in, people will complain about
that also. Last minute behaviour changes are bad news. I don't object to
adding something, just don't take anything away. It's not like the code
for it is pages long or anything.
* Robert Haas (robertmh...@gmail.com) wrote:
On Mon, May 3, 2010 at 11:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that we should throw away all this logic and just
have the slave cancel competing queries if the replay process waits
more than max_standby_delay seconds to
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
Tom's proposed behaviour (has also been proposed before) favours the
avoid query cancellation route though could lead to huge amounts of lag.
My impression of Tom's suggestion was that it would also be a maximum
amount of delay which would be
* Simon Riggs (si...@2ndquadrant.com) wrote:
If recovery waits for max_standby_delay every time something gets in its
way, it should be clear that if many things get in its way it will
progressively fall behind. There is no limit to this and it can always
fall further behind. It does result in
* Aidan Van Dyk (ai...@highrise.ca) wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100510 06:03]:
A problem with using the name max_standby_delay for Tom's suggestion
is that it sounds like a hard limit, which it isn't. But if we name it
something like:
I'ld still
Brendan,
* Brendan Hill (brend...@jims.net) wrote:
Getting significantly lower performance on a specific query after upgrading
from 8.3 - 8.4 (windows). I'm not expecting a quick fix from the mail
lists, but I would appreciate any indications as to where else I could look
or what tools I
Greetings,
Toying around with FETCH_COUNT today, I discovered that it didn't do
the #1 thing I really wanted to use it for- query large tables without
having to worry about LIMIT to see the first couple hundred records.
The reason is simple- psql ignores $PAGER exiting, which means that
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A saner
approach, which would also help for other corner cases such as
out-of-disk-space, would be to check for write failures on the output
file and abandon the query if any occur.
I had considered this, but I'm not sure we really need to catch *every*
* Tom Lane (t...@sss.pgh.pa.us) wrote:
If you're combining this with the FETCH_COUNT logic then it seems like
it'd be sufficient to check ferror(fout) once per fetch chunk, and just
fall out of that loop then. I don't want psql issuing query cancels
on its own authority, either.
Attached is
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Attached is a patch that just checks the result from the existing
fflush() inside the FETCH_COUNT loop and drops out of that loop if we
get an error from it.
I thought it might be about that simple once you
Greetings,
This doesn't seem right to me:
postgres=# select
postgres-# string_agg(column1::text order by column1 asc,',')
postgres-# from (values (3),(4),(1),(2)) a;
string_agg
1234
(1 row)
I'm thinking we should toss a syntax error here and force the 'order
by' to be at
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
This doesn't seem right to me:
postgres=# select
postgres-# string_agg(column1::text order by column1 asc,',')
postgres-# from (values (3),(4),(1),(2)) a;
string_agg
1234
(1 row
Greetings,
Under:
http://developer.postgresql.org/pgdocs/postgres/runtime-config-file-locations.html
We have:
ident_file (string)
Specifies the configuration file for ident authentication
(customarily called pg_ident.conf). This parameter can only be set
at server start.
301 - 400 of 4379 matches
Mail list logo
