This if-block is misplaced:
> case RECOVERY_TARGET_STOP_IMMEDIATE:
> case RECOVERY_TARGET_STOP_XID:
> case RECOVERY_TARGET_STOP_TIME:
> paused = false;
> br
On Fri, 2009-10-16 at 01:43 +0300, Heikki Linnakangas wrote:
> recovery_starts_paused is useless as it is. It pauses the recovery right
> after the first WAL record, all right, but before we see a running-xacts
> record, we won't let any backends in. And if you can't connect, you
> can't unpause,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm trying to figure out why I keep getting an error when trying to COPY
data into a table. The basic process is to get
Robert Haas wrote:
> On Thu, Oct 15, 2009 at 1:22 PM, Tom Lane wrote:
>> Maybe if I weren't burned out after a month of CommitFesting, I could
>> muster a more positive reaction, but right now I just can't summon any
>> enthusiasm for this.
>
> Based on this review, I am marking this patch Reject
Subject line pretty much says it all.
Thanks,
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Oct 15, 2009 at 1:22 PM, Tom Lane wrote:
> Maybe if I weren't burned out after a month of CommitFesting, I could
> muster a more positive reaction, but right now I just can't summon any
> enthusiasm for this.
Based on this review, I am marking this patch Rejected.
For what it's worth, I
Tom Lane wrote:
> KaiGai Kohei writes:
>> [ patch r2363 ]
>
> I promised I would review this today, but I just can't make myself do it
> in any detail. This is too large, too ugly, and it is going in a
> direction that I do not like or want to spend any of my time on.
>
> The overwhelming impre
On Mon, Oct 12, 2009 at 9:13 PM, Itagaki Takahiro
wrote:
>
> Magnus Hagander wrote:
>
>> One other question - you note that WriteConsoleW() "could fail if
>> stderr is redirected". Are you saying that it will always fail when
>> stderr is redirected, or only sometimes? If ony sometimes, do you kn
On Thu, Oct 15, 2009 at 2:27 AM, Heikki Linnakangas
wrote:
> Robert Haas wrote:
>> On Wed, Sep 30, 2009 at 12:24 PM, Heikki Linnakangas
>> wrote:
Do you
have any sense of how soon you'll feel confident to commit either
patch?
>>> I'm bad at estimating. Not this week for sure, and
Tom Lane wrote:
> Itagaki Takahiro writes:
> > I think there is a benefit to provide WHEN cluase at least
> > for compatibility with other DBMSs, even through we can move
> > the expressions into the body of trigger functions.
>
> This seems to me to be a lot of code to accomplish nothing usef
Alvaro Herrera writes:
> Hmm ... this is something that had not occured to me earlier. There is
> a connection pool here (JDBCConnectionPool I'm told; hadn't heard about
> that one) and there are about 100 backends permanently, not all of which
> are always busy. Perhaps what's going on here is
Tom Lane wrote:
> Alvaro Herrera writes:
> > While looking at this code I notice something that troubles me. Just
> > after extending the relation, we don't insert the new page into the FSM.
> > So if the extending backend does not do any other insertion on the page,
> > it is forgotten as possib
recovery_starts_paused is useless as it is. It pauses the recovery right
after the first WAL record, all right, but before we see a running-xacts
record, we won't let any backends in. And if you can't connect, you
can't unpause, so it's stuck forever.
It should probably behave as "pause after reac
On Thu, Oct 15, 2009 at 10:40 PM, Ron Mayer
wrote:
> Dave Page wrote:
>> I never said it wasn't - in fact I said from the outset it was about
>> box-checking, and that anyone doing things properly will use
>> LDAP/SSPI/Kerberos etc.
>
> I don't understand why the box-checkers can't already check t
Dimitri Fontaine wrote:
> It's pretty often the case (IME) that calling a trigger is the only
> point in the session where you fire plpgsql, and that's a visible
> cost.
Wouldn't a connection pool solve this?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Tom Lane writes:
> That argument is based on a completely evidence-free assumption, namely
> that this patch would make your case faster. Executing the WHEN tests
> is hardly going to be zero cost. It's not too hard to postulate cases
> where implementing a filter this way would be *slower* than
Alvaro Herrera writes:
> While looking at this code I notice something that troubles me. Just
> after extending the relation, we don't insert the new page into the FSM.
> So if the extending backend does not do any other insertion on the page,
> it is forgotten as possible insert target until the
Dave Page wrote:
> I never said it wasn't - in fact I said from the outset it was about
> box-checking, and that anyone doing things properly will use
> LDAP/SSPI/Kerberos etc.
I don't understand why the box-checkers can't already check that
box; with the explanation stating "Yes - by using LDAP o
I've been spending some time debugging a customer's performance problem,
and what I see is that there are a bunch of processes all waiting for
the relation extension lock for a particular relation.
While looking at this code I notice something that troubles me. Just
after extending the relation,
On Thu, Oct 15, 2009 at 7:22 PM, Mark Mielke wrote:
> It depends on what your goal is. If your goal is to treat users as monkeys
> that you do not trust, even with their own password, and the DBA as God, who
> you absolutely do trust, than you are correct.
>
> I don't know about your company - but
On 10/15/2009 02:02 PM, Dave Page wrote:
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas wrote:
OK, so we're in violent agreement here?
From a technical perspective I think we have been for a while. Though
clearly some people disagree with my assertion that putting any form
of policy
Dave Page writes:
> I suppose in the worst case, I could just have pgAdmin throw the
> error, and then add a per-server option to disable password hashing in
> the relevant places, but I'd far rather have that automated so it
> can't be set unnecessarily.
As I commented before, I think that autom
Dave Page writes:
> On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane wrote:
>> Yes, and it's an optional flag that could perfectly well be implemented
>> in the plugin that I think we do have consensus to add a hook for.
>> The argument is over why do we need to litter the core system with it.
> I alre
On 10/15/2009 01:44 PM, Dave Page wrote:
I don't deal with prospective clients, which is where this comes from.
I do deal with a team of (pre)sales engineers who complain about this,
and maybe half-a-dozen other issues on a very regular basis. They tell
me that PostgreSQL loses out in early stage
On Thu, Oct 15, 2009 at 10:22:52AM -0700, Josh Berkus wrote:
> > (I'd bet lunch that the one about add_missing_from is bogus, too,
> > or could easily be made so. mysql isn't forgiving about missing
> > FROM items, so it's hard to believe that they have a lot of such
> > things no matter how littl
On Thu, Oct 15, 2009 at 6:55 PM, Robert Haas wrote:
> OK, so we're in violent agreement here?
From a technical perspective I think we have been for a while. Though
clearly some people disagree with my assertion that putting any form
of policy enforcement in the client is not actually 'enforcemen
On Thu, Oct 15, 2009 at 1:47 PM, Dave Page wrote:
> On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> If we were using some kind of real public key system and someone
>>> suggested breaking it to add password complexity checking, I would
>>> understand the outrage here.
On Thu, Oct 15, 2009 at 6:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> If we were using some kind of real public key system and someone
>> suggested breaking it to add password complexity checking, I would
>> understand the outrage here. But I don't understand why everyone is
>> so worked up
On Thu, Oct 15, 2009 at 6:17 PM, Josh Berkus wrote:
> Enabling the inclusion of a password checker in the client *would*
> improve things by preventing stupid users from setting their password
> the same as their username, or to a 3-letter word, or anything equally
> stupid which can be checked i
Robert Haas writes:
> If we were using some kind of real public key system and someone
> suggested breaking it to add password complexity checking, I would
> understand the outrage here. But I don't understand why everyone is
> so worked up about having an *optional* *flag* to force plaintext
> i
> (I'd bet lunch that the one about add_missing_from is bogus, too,
> or could easily be made so. mysql isn't forgiving about missing
> FROM items, so it's hard to believe that they have a lot of such
> things no matter how little they care about Postgres.)
OpenACS does the old-style DELETEs wit
KaiGai Kohei writes:
> [ patch r2363 ]
I promised I would review this today, but I just can't make myself do it
in any detail. This is too large, too ugly, and it is going in a
direction that I do not like or want to spend any of my time on.
The overwhelming impression after a brief read-throug
On Thu, Oct 15, 2009 at 12:23 PM, Mark Mielke wrote:
> You miss my point (and conveniently cut it out). For users who accidentally
> break policy vs users who purposefully circumvent policy - the approaches
> must be different, and the risk management decision may be different.
>
> It's a lot easi
On 10/15/09 9:41 AM, Dave Page wrote:
> Sometimes that can be for huge projects, where it is
> necessary to justify every difference in check-box items against other
> products to get past the early eval stages. Like it or not, that is a
> fact, and this hampers our adoption.
Precisely, and I thin
Mark Mielke wrote:
> On 10/15/2009 10:08 AM, Dave Page wrote:
>> ...other
>> DBMSs (and all major operating systems I can think of) offer password
>> policy features as non-client checks...we are compared ...
>
> Not so clear to me. If they're doing strong checks, this means they're
> sending pass
On Thu, Oct 15, 2009 at 5:28 PM, Mark Mielke wrote:
>
> Not so clear to me. If they're doing strong checks, this means they're
> sending passwords in the clear or only barely encoded, or using some OTHER
> method than 'alter role ... password ...' to change the password.
Some are sending them in
On 10/15/2009 10:38 AM, Albe Laurenz wrote:
Mark Mielke wrote:
Does Oracle really do password checks on the base SQL commands used to
change an Oracle password? That sounds silly.
In Oracle you can write a stored procedure to check passwords;
it is invoked whenever a user is created o
On 10/15/2009 10:08 AM, Dave Page wrote:
It's certainly true that there are other ways for users to compromise
their passwords if they want. The fact remains though, that most other
DBMSs (and all major operating systems I can think of) offer password
policy features as non-client checks which ar
On 10/15/2009 03:54 AM, Dave Page wrote:
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke wrote:
On 10/14/2009 05:33 PM, Dave Page wrote:
No. Any checks at the client are worthless, as they can be bypassed by
10 minutes worth of simple coding in any of a dozen or more languages.
Dave Page writes:
> Looking further, I think this might be quite clean:
> - Add a precedence flag to PQconninfoOption
> - In conninfo_parse, in the section that grabs the envvars for empty
> params, modify the logic to override any existing values if a value is
> set in the environment and the p
On Thu, Oct 15, 2009 at 4:37 PM, Tom Lane wrote:
> Another possibility that should be mentioned for the record is that
> we could special-case the appname parameter inside libpq, so that the
> environment variable takes precedence over the conn setting instead
> of the other way round. That seem
Dave Page writes:
> On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane wrote:
>> Hmm. Maybe this is a generic problem. Should libpq offer some sort
>> of help? Maybe a "secondaryappname" parameter that doesn't override
>> the env variable.
> is it worth uglifying libpq? All we're talking about is some
On Thu, Oct 15, 2009 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
>> wrote:
>>> EXPLAIN BUFFERS only shows 'hit', 'read' and 'temp read' in text format
>>> to fit in display, but xml or json format contains all of them.
>
>> I was very c
On Thu, Oct 15, 2009 at 3:50 PM, Tom Lane wrote:
> Dave Page writes:
>> On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane wrote:
>>> Also, I am wondering exactly what you think psql would *do* with the
>>> parameter if it had it. If the answer is "force the setting to be
>>> 'psql'", that's the wrong a
Robert Haas writes:
> On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
> wrote:
>> EXPLAIN BUFFERS only shows 'hit', 'read' and 'temp read' in text format
>> to fit in display, but xml or json format contains all of them.
> I was very careful when I submitted the machine-readable explain patch
2009/10/15 Heikki Linnakangas :
> KaiGai Kohei wrote:
>> I have to focus on my patches with highest priority in CommitFest,
>> but it may be possible to help reviewing the proposed patches in
>> the off-fest season. It is illegal/undesirable for the process?
>
> No, that's absolutely fine. During c
Pavel Stehule writes:
> 2009/10/15 Tom Lane :
>> This seems to me to be a lot of code to accomplish nothing useful.
> I disagree. When I analysed speed of some operations, I found some
> unwanted trigger calls should to slow down applications. I am for any
> method, that could to decrease trigger
Dave Page writes:
> On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane wrote:
>> Also, I am wondering exactly what you think psql would *do* with the
>> parameter if it had it. If the answer is "force the setting to be
>> 'psql'", that's the wrong answer. IMO you'd really want the environment
>> variabl
On Thu, Oct 15, 2009 at 7:29 AM, Itagaki Takahiro
wrote:
> EXPLAIN BUFFERS only shows 'hit', 'read' and 'temp read' in text format
> to fit in display, but xml or json format contains all of them.
I was very careful when I submitted the machine-readable explain patch
to make sure that the choice
Itagaki Takahiro writes:
> I think there is a benefit to provide WHEN cluase at least
> for compatibility with other DBMSs, even through we can move
> the expressions into the body of trigger functions.
This seems to me to be a lot of code to accomplish nothing useful.
It will always be the case
2009/10/15 Tom Lane :
> Itagaki Takahiro writes:
>> I think there is a benefit to provide WHEN cluase at least
>> for compatibility with other DBMSs, even through we can move
>> the expressions into the body of trigger functions.
>
> This seems to me to be a lot of code to accomplish nothing usefu
Mark Mielke wrote:
> Does Oracle really do password checks on the base SQL commands used to
> change an Oracle password? That sounds silly.
In Oracle you can write a stored procedure to check passwords;
it is invoked whenever a user is created or altered.
No matter how you change the password, O
On Thu, Oct 15, 2009 at 3:28 PM, Tom Lane wrote:
> Dave Page writes:
>> a) Added PQsetdbLogin2() with an additional option for the application
>> name (my guess is 'no').
>> b) Updated the apps to use PQconnectdb
>> c) Something else?
>
> a) is absolutely right out. b) is okay from an overall vi
Dave Page writes:
> a) Added PQsetdbLogin2() with an additional option for the application
> name (my guess is 'no').
> b) Updated the apps to use PQconnectdb
> c) Something else?
a) is absolutely right out. b) is okay from an overall viewpoint but
you would find yourself doing something very mu
Dave Page escreveu:
> On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane wrote:
>> Sure. I'm envisioning that what the env variable or connection option
>> actually does is cause libpq to include a SET command for a GUC
>> variable in the initial connection request packet. Compare, say,
>> PGCLIENTENCODI
On Thu, Oct 15, 2009 at 2:49 PM, Kevin Grittner
wrote:
> Dave Page wrote:
>> On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
>
>>> bigger problems, like that slip of paper in their desk drawer with
>>> the password written on it.
>
>> See my previous comment about dates. Check-box items aside, I
On Wed, Oct 14, 2009 at 3:42 PM, Tom Lane wrote:
> Sure. I'm envisioning that what the env variable or connection option
> actually does is cause libpq to include a SET command for a GUC
> variable in the initial connection request packet. Compare, say,
> PGCLIENTENCODING -> client_encoding.
So
Dave Page wrote:
> On Wed, Oct 14, 2009 at 10:51 PM, Kevin Grittner
>> bigger problems, like that slip of paper in their desk drawer with
>> the password written on it.
> See my previous comment about dates. Check-box items aside, I have
> absolutely no desire to try to give the illusion of a
On Thu, 2009-10-15 at 17:44 +0800, mingsoftt wrote:
> I have thought of making visual c++ of not recognizing "typename" as a
> keyword, say, by turning some compiler options to forced c mode
> ( rather than c++).
> Is there indeed such an option? If not, is there a way to resolve my
> problem as de
hi there,
i have trouble compiling a c style program ( filename with extension cpp)
written for visual C++.
When i added the following #includes,
>>> #include "spi.h"
>>> #include "trigger.h"
compilation errors say "error C2899: typename cannot be used outside a template
declaration".
I need th
Michael Meskes írta:
> On Wed, Oct 14, 2009 at 06:37:43PM +0200, Boszormenyi Zoltan wrote:
>
>> the attached patch makes ECPG more robust
>> against applications that free() strings by storing
>> its own copy of the prepared statement name.
>>
>
> Please do not call strdup() directly in lib
On Wed, Oct 14, 2009 at 06:37:43PM +0200, Boszormenyi Zoltan wrote:
> the attached patch makes ECPG more robust
> against applications that free() strings by storing
> its own copy of the prepared statement name.
Please do not call strdup() directly in libecpg. Instead please use
ecpg_strdup() whi
Robert Haas wrote:
> In this case, I think that the auto_explain changes out to be part of
> the same patch as the core EXPLAIN changes
Here is a rewritten patch to add EXPLAIN (ANALYZE, BUFFERS) and
support for it by contrib/auto_explain. I removed pg_stat_statements
support from the patch for
Simon Riggs wrote:
> On Thu, 2009-10-15 at 10:33 +0300, Heikki Linnakangas wrote:
>> Let me know if I'm missing something. And please feel free to help, by
>> testing, by reviewing and commenting on the patch, or by addressing any
>> of the above issues. I will continue working on this, but this is
On Wed, Oct 14, 2009 at 11:44 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Peter Eisentraut writes:
>> > Well, you would lose anyway if the DBA switches the pg_hba.conf setting
>> > from md5 to password without telling you.
>>
>> True :-(. Anybody for a zero-knowledge pro
On Thu, 2009-10-15 at 10:33 +0300, Heikki Linnakangas wrote:
> There's been a lot of churn in hot standby since the beginning of the
> commitfest, so I thought it would be good to summarize where we are.
>
> Attached is the latest and greatest patch against CVS head, taken from
> the hs-riggs bra
On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke wrote:
> On 10/14/2009 05:33 PM, Dave Page wrote:
>>
>> No. Any checks at the client are worthless, as they can be bypassed by
>> 10 minutes worth of simple coding in any of a dozen or more languages.
>>
>
> Why care?
Because many large (and small for
On Thu, 2009-10-15 at 13:18 +0900, Itagaki Takahiro wrote:
> Simon Riggs wrote:
>
> > > Is it possible to use WAL-skipping and BulkInsertState in
> > > ATRewriteTable() ?
> > > If ok, I'll submit a patch for the next commitfest.
> >
> > Yes
>
> Patch attached.
> This patch skip WAL writes duri
68 matches
Mail list logo
