On 26.04.2011 09:45, Prakash Itnal wrote:
I have create the following tables:
1. rnc table
CREATE TABLE act_rnc(rnc_id integer NOT NULL PRIMARY KEY, rnc_data BYTEA);
2. rncgen table
CREATE TABLE act_rncgen(rnc_id integer NOT NULL PRIMARY KEY, rncsubObj_Cnt
integer, rncgen_data BYTEA);
3. iuo tabl
Congrats on being selected, looking forward to mentor you!
On 25.04.2011 23:09, Alexander Korotkov wrote:
The first question that I would like to discuss is the node buffer storage.
During index build each index page (except leaf) should have several pages
of buffer. So my question is where to s
Hi,
I have create the following tables:
1. rnc table
CREATE TABLE act_rnc(rnc_id integer NOT NULL PRIMARY KEY, rnc_data BYTEA);
2. rncgen table
CREATE TABLE act_rncgen(rnc_id integer NOT NULL PRIMARY KEY, rncsubObj_Cnt
integer, rncgen_data BYTEA);
3. iuo table which has a foreign key reference to
Hello all,
While examining the executor, I was wondering what the *args part of
AggrefExprState nodes contain. I found that the Aggref (Expr)'s args list
is a list of TargetEntry nodes. But the state node's args is initialized in
ExecInitExpr as:
astate->args = (List *) ExecInitExpr((Expr *) agg
Greg Stark writes:
> On Tue, Apr 26, 2011 at 2:07 AM, Andrew Dunstan wrote:
>> Oh, it just occurred to me that maybe you thought the whole thing
>> *including* indent would be reimplemented in perl. That was never my
>> intention, and is a much larger project than I had in mind.
> Oh, I thought
Excerpts from Tom Lane's message of lun abr 25 20:48:42 -0300 2011:
> Andrew Dunstan writes:
> > Well, that way you'll have a handful of -Ttypdef parameters for each
> > invocation of indent instead of a gazillion of them. No more command
> > line length issues.
>
> Well, -Ttypedef is wrong on
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Sounds good to me ... who's volunteering?
(Andrew) I will as well. Github perhaps, Andrew? I'll be happy to get
some unit tests written.
- --
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x1
On Tue, Apr 26, 2011 at 2:07 AM, Andrew Dunstan wrote:
> Oh, it just occurred to me that maybe you thought the whole thing
> *including* indent would be reimplemented in perl. That was never my
> intention, and is a much larger project than I had in mind.
Oh, I thought that was what you were prop
Robert Haas wrote:
> On Mon, Apr 25, 2011 at 8:19 PM, Bruce Momjian wrote:
> > The attached applied patch improves pg_upgrade by: ?avoiding one
> > start/stop of the postmaster; ?using the -w (wait) flag for pg_ctl
> > start/stop; ?removing the unused "quiet" flag in the functions for
> > starting
Thanks Hackers
My proposal (the title is "Caching query results in pgpool-II") is accepted
by Google Summer of Code 2011 and I am very happy!
I appreciate your support and help so much. (Especially thanks to Tatsuo
Ishii)
Regards
On 04/25/2011 09:02 PM, Andrew Dunstan wrote:
The current script calls our (patched) BSD indent. Any rewrite would
have to also. It (the BSD indent) doesn't have any facility to pass a
typedef file parameter. If you want that we have to patch the C code.
No amount of rewriting in Perl or a
On 04/25/2011 08:54 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 04/25/2011 07:48 PM, Tom Lane wrote:
Well, -Ttypedef is wrong on its face. Right would be a switch
specifying the name of the file to read the typedef list from.
Then you don't need massive script-level infrastructure to try
On Mon, Apr 25, 2011 at 8:19 PM, Bruce Momjian wrote:
> The attached applied patch improves pg_upgrade by: avoiding one
> start/stop of the postmaster; using the -w (wait) flag for pg_ctl
> start/stop; removing the unused "quiet" flag in the functions for
> starting/stopping the postmaster.
It
Andrew Dunstan writes:
> On 04/25/2011 07:48 PM, Tom Lane wrote:
>> Well, -Ttypedef is wrong on its face. Right would be a switch
>> specifying the name of the file to read the typedef list from.
>> Then you don't need massive script-level infrastructure to try
>> to spoonfeed that data to the pr
On Tuesday, April 26, 2011 02:22:34 AM Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
> >> [ lots of awesome test results ]
> >
> > Very interesting work. I think it's interesting that there is so much
> > allocation happening inside MessageConte
On 04/25/2011 07:48 PM, Tom Lane wrote:
Well, that way you'll have a handful of -Ttypdef parameters for each
invocation of indent instead of a gazillion of them. No more command
line length issues.
Well, -Ttypedef is wrong on its face. Right would be a switch
specifying the name of the file
On Tuesday, April 26, 2011 01:24:20 AM Robert Haas wrote:
> On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
> > [ lots of awesome test results ]
>
> Very interesting work. I think it's interesting that there is so much
> allocation happening inside MessageContext; I barely knew that
> exis
Robert Haas writes:
> On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
>> [ lots of awesome test results ]
> Very interesting work. I think it's interesting that there is so much
> allocation happening inside MessageContext; I barely knew that
> existed, let alone that it was a hotspot for
I have just applied a patch to minorly improve performance of pg_upgrade.
Below is a pg_upgrade test run from 9.0 to 9.1 with the 'regression'
database loaded; the numbers at the start of the line indicate the
number of seconds from the previous line being output.
Does anyone see any way to spee
The attached applied patch improves pg_upgrade by: avoiding one
start/stop of the postmaster; using the -w (wait) flag for pg_ctl
start/stop; removing the unused "quiet" flag in the functions for
starting/stopping the postmaster.
--
Bruce Momjian http://momjian.us
EnterpriseDB
On Tuesday, April 26, 2011 01:39:37 AM Tom Lane wrote:
> Andres Freund writes:
> > So after all this my question basically is: How important do we think the
> > mctx.c abstraction is?
>
> I think it's pretty important. As a specific example, a new context
> type in which pfree() is a no-op would
Robert Haas writes:
> On Mon, Apr 25, 2011 at 7:03 PM, Tom Lane wrote:
>> As per the other thread today, this advice would usually be correct,
>> so I think that not offering any advice at all would be a step down from
>> that.
> Well, currently ALTER TABLE will work even if the argument is a vi
Andrew Dunstan writes:
> On 04/25/2011 07:00 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> and filter the typedefs list so that we only use the ones
>>> that appear in each file with that file, instead of passing the whole
>>> list to each file.
>> Not sure I gather the value of doing that.
Andres Freund writes:
> So after all this my question basically is: How important do we think the
> mctx.c abstraction is?
I think it's pretty important. As a specific example, a new context
type in which pfree() is a no-op would be fine with me. A new context
type in which pfree() dumps core w
On Thu, Apr 21, 2011 at 11:46 AM, Robert Haas wrote:
> On Thu, Apr 21, 2011 at 11:38 AM, Peter Eisentraut wrote:
>> On Tue, 2011-04-19 at 18:18 -0400, Robert Haas wrote:
>>> 2. The typed tables stuff vs. pg_upgrade still needs work. I would be
>>> just as happy if Tom or Peter wanted to fix this
On Mon, Apr 25, 2011 at 7:03 PM, Tom Lane wrote:
> Robert Haas writes:
>> The sequence of steps that he posted wasn't actually right.
>
> Yes, I did read the thread.
OK.
>> The patch seems trivially correct,
>> since this is obviously schizophrenic:
>
>> ereport(ERROR,
>>
On 04/25/2011 07:18 PM, Tom Lane wrote:
Peter Eisentraut writes:
On mån, 2011-04-25 at 15:26 -0400, Tom Lane wrote:
Well, it's not just to be "helpful", it's to close off code paths that
are never going to be sufficiently well-tested to not have bizarre
failure modes. That helps both devel
I came across this today, while helping a customer. The following will
happily create a piece of XML with an embedded ^A:
select xmlelement(name foo, null, E'abc\x01def');
Now, a ^A is totally forbidden in XML version 1.0, and allowed but only
as "" or equivalent in XML version 1.1, and n
On Mon, Apr 25, 2011 at 5:45 PM, Andres Freund wrote:
> [ lots of awesome test results ]
Very interesting work. I think it's interesting that there is so much
allocation happening inside MessageContext; I barely knew that
existed, let alone that it was a hotspot for memory allocation. I
think i
Peter Eisentraut writes:
> On mån, 2011-04-25 at 15:26 -0400, Tom Lane wrote:
>> Well, it's not just to be "helpful", it's to close off code paths that
>> are never going to be sufficiently well-tested to not have bizarre
>> failure modes. That helps both developers (who don't have to worry
>> a
On 04/25/2011 07:00 PM, Tom Lane wrote:
Andrew Dunstan writes:
Well, my solution would be to replace pgindent with a perl script (among
other advantages, it would then run everywhere we build, including
Windows),
Sounds good to me ... who's volunteering?
I'll take a look.
and filter the t
=?ISO-8859-15?Q?Yves_Wei=DFig?= writes:
> But anyway I am having trouble creating an operator class:
> CREATE OPERATOR CLASS abstime_ops
> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
> OPERATOR 1 = ,
> FUNCTION 1 abstimeeq(abstime,abstime);
> yields: ERROR: invalid procedure numb
Robert Haas writes:
> The sequence of steps that he posted wasn't actually right.
Yes, I did read the thread.
> The patch seems trivially correct,
> since this is obviously schizophrenic:
> ereport(ERROR,
> (errcode(ERRCODE_WRONG_OBJECT_TYPE),
>
Andrew Dunstan writes:
> Well, my solution would be to replace pgindent with a perl script (among
> other advantages, it would then run everywhere we build, including
> Windows),
Sounds good to me ... who's volunteering?
> and filter the typedefs list so that we only use the ones
> that appea
Hi,
In the thread
http://archives.postgresql.org/message-id/4da69d60.4000...@2ndquadrant.com /
"Single client performance on trivial SELECTs" I wondered whether it might be
possible to increase the performance of the current allocator by using some
slab allocator like concept.
While avoiding doi
Peter Eisentraut wrote:
Another point, as there appear to be diverging camps about
supertransactional stored procedures vs. autonomous transactions, what
would be the actual use cases of any of these features? Let's collect
some, so we can think of ways to make them work.
An analogy I like to
On mån, 2011-04-25 at 15:26 -0400, Tom Lane wrote:
> Well, it's not just to be "helpful", it's to close off code paths that
> are never going to be sufficiently well-tested to not have bizarre
> failure modes. That helps both developers (who don't have to worry
> about testing/fixing such code pat
On Mon, Apr 25, 2011 at 10:17 AM, Tom Lane wrote:
> Shigeru Hanada writes:
>> I noticed that ALTER FOREIGN TABLE RENAME TO emits a wrong hint message
>> if the object was not a foreign table. ISTM that the hint message is
>> not necessary there. Attached patch removes the hint message.
>
> Surel
On 04/25/2011 01:55 PM, Andrew Dunstan wrote:
Well, my solution would be to replace pgindent with a perl script
(among other advantages, it would then run everywhere we build,
including Windows), and filter the typedefs list so that we only use
the ones that appear in each file with that f
On Mon, Apr 25, 2011 at 2:07 PM, Peter Eisentraut wrote:
> On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
>> So the topic of "real" "stored procedures" came up again. Meaning a
>> function-like object that executes outside of a regular transaction,
>> with the ability to start and sto
On 04/25/2011 04:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 04/25/2011 03:30 PM, Tom Lane wrote:
*Ouch*. Really? It's hard to believe that anyone would consider it
remotely usable for more than toy-sized projects, if you have to list
all the typedef names on the command line.
Looks
Am 24.04.2011 23:33, schrieb Tom Lane:
> =?ISO-8859-15?Q?Yves_Wei=DFig?=
> writes:
>> again index access methods, can somebody shed some light into operator
>> classes for indexes? The documentation is an entry point, but after
>> reading I still don't have a clue how exactly they are used and cr
On Mon, Apr 25, 2011 at 2:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... There's a similar stanza for sequences, but that one uses
>> ereport(WARNING...) rather than ereport(ERROR...). We could either
>> remove that stanza entirely (making foreign tables consistent with
>> views) or change
On Mon, Apr 25, 2011 at 4:29 PM, Steve Singer wrote:
> On 11-04-25 03:40 PM, Robert Haas wrote:
>>
>> At the risk of getting a bit cranky, you haven't participated in a
>> material way in any CommitFest we've had in well over a year. AFAICS,
>> the first, last, and only time you are listed in the
On 11-04-25 03:40 PM, Robert Haas wrote:
At the risk of getting a bit cranky, you haven't participated in a
material way in any CommitFest we've had in well over a year. AFAICS,
the first, last, and only time you are listed in the CommitFest
application is as co-reviewer of a patch in July 2009,
On Apr 25, 2011, at 3:28 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 04/25/2011 03:30 PM, Tom Lane wrote:
>>> *Ouch*. Really? It's hard to believe that anyone would consider it
>>> remotely usable for more than toy-sized projects, if you have to list
>>> all the typedef names on the com
Andrew Dunstan writes:
> On 04/25/2011 03:30 PM, Tom Lane wrote:
>> *Ouch*. Really? It's hard to believe that anyone would consider it
>> remotely usable for more than toy-sized projects, if you have to list
>> all the typedef names on the command line.
> Looks like BSD does the same. It's just
On Mon, Apr 25, 2011 at 8:26 AM, Greg Smith wrote:
> On 04/24/2011 10:06 PM, Daniel Farina wrote:
>>
>> On Thu, Apr 21, 2011 at 8:51 PM, Greg Smith wrote:
>>
>>>
>>> There's still the "fsync'd a data block but not the directory entry yet"
>>> issue as fall-out from this too. Why doesn't PostgreS
Peter Eisentraut wrote:
Another point, as there appear to be diverging camps about
supertransactional stored procedures vs. autonomous transactions, what
would be the actual use cases of any of these features?
Looping over hundreds of identical schema executing DDL statements on
each. We can'
On Mon, Apr 25, 2011 at 7:02 PM, Tom Lane wrote:
> Yeah, the existing precedent (not only for GRANT but for some other
> things like ALTER TABLE) is that a command that says "TABLE" is allowed
> to apply to other relation types if it makes sense to apply it. It's
> only when you name some other o
Hello
2011/4/25 Joel Jacobson :
> I have two separate ideas, but they are kind of connected,
>
> (1) Make the detailed error message available in SPs and not only the short
> error message (SQLERRM)
> When debugging errors in stored procedures, I often add an exception handler
> and print the valu
Hackers!
I was happy to know that my proposal "Fast GiST index build" was accepted to
GSoC 2011! Thank you very much for support! Especially thanks to Heikki
Linnakangas for becoming my mentor!
The first question that I would like to discuss is the node buffer storage.
During index build each ind
On Mon, Apr 25, 2011 at 3:47 PM, Joshua D. Drake wrote:
> On 04/25/2011 12:40 PM, Robert Haas wrote:
>> At the risk of getting a bit cranky, you haven't participated in a
>> material way in any CommitFest we've had in well over a year. AFAICS,
>> the first, last, and only time you are listed in t
On Mon, Apr 25, 2011 at 5:00 PM, Greg Smith wrote:
> Stop right there; the slow path was the only one that had any hope of being
> correct. It can actually slow things by a factor of 100X or more,
> worst-case. "So, we currently have the choice between filesystem corruption
> or major performanc
On 04/25/2011 12:40 PM, Robert Haas wrote:
At the risk of getting a bit cranky, you haven't participated in a
material way in any CommitFest we've had in well over a year. AFAICS,
the first, last, and only time you are listed in the CommitFest
application is as co-reviewer of a patch in July 20
On 04/25/2011 02:26 PM, Josh Berkus wrote:
Overall, I think the advantages to a faster/shorter CF cycle outweigh
the disadvantages enough to make it at least worth trying. I'm willing
to run the first 1-week CF, as well as several of the others during the
9.2 cycle to try and make it work.
On Mon, Apr 25, 2011 at 2:26 PM, Josh Berkus wrote:
> I thought the idea of setting the initial CF for July 15th for 9.1 was
> that we would consistently have the first CF in July every year? As
> discussed at that time, there's value to our corporate-sponsored
> developers in knowing a regular a
On 04/25/2011 03:30 PM, Tom Lane wrote:
Greg Stark writes:
Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
figuring out how to get even remotely similar output.
...
And it doesn't take a file for the list of typedefs. You have to
provide each one as an argment on the com
Peter Eisentraut wrote:
> what would be the actual use cases of any of these features?
> Let's collect some, so we can think of ways to make them work.
The two things which leap to mind for me are:
(1) All the \d commands in psql should be implemented in SPs so
that they are available from
Greg Stark writes:
> Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
> figuring out how to get even remotely similar output.
> ...
> And it doesn't take a file for the list of typedefs. You have to
> provide each one as an argment on the command-line.
*Ouch*. Really? It's
Peter Eisentraut writes:
> On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
>> In the particular case at hand, if someone is trying to use the same
>> hostssl-containing pg_hba.conf across multiple systems, is it not
>> reasonable to suppose that he should have SSL turned on in
>> postgresql.co
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
> So the topic of "real" "stored procedures" came up again. Meaning a
> function-like object that executes outside of a regular transaction,
> with the ability to start and stop SQL transactions itself.
>
> I would like to collect some sp
Robert Haas writes:
> However, I think that the "logged table, unlogged index" idea is
> probably the most promising thing to think about doing first.
+1 for that --- it's clean, has a clear use-case, and would allow us
to manage the current mess around hash indexes more cleanly.
That is, hash in
On mån, 2011-04-25 at 13:34 -0500, Merlin Moncure wrote:
> hm. does the sql standard prohibit the use of extra transactional
> features?
It doesn't prohibit anything. It just kindly requests that standard
syntax has standard behavior.
> are you sure it's not implied that any sql (including
> STA
Josh Berkus writes:
> As much as I'd like to start development early officially, I'm with Tom
> in being pessimistic about the bugs we're going to find in SSI,
> Collations and Synch Rep. Frankly, if you and Tom weren't so focused on
> fixing it, I'd be suggesting that we pull Collations from 9.1
On Mon, Apr 25, 2011 at 4:17 PM, Tom Lane wrote:
> No, not at all, because you're ignoring the common case of a series of
> dependent patches that are submitted in advance of the first one having
> been committed.
Uh, true.
> To get to the point where we could do things that way, it would have
On mån, 2011-04-25 at 14:18 -0400, Tom Lane wrote:
> In the particular case at hand, if someone is trying to use the same
> hostssl-containing pg_hba.conf across multiple systems, is it not
> reasonable to suppose that he should have SSL turned on in
> postgresql.conf on all those systems? If he d
Excerpts from Tomas Vondra's message of lun abr 25 14:50:18 -0300 2011:
> Yes, I know the tuple length is in HeapTupleHeader (and I'm already
> checking that), but that does not allow to check lengths of the
> individual columns, especially those with varlena types.
>
> That's a very annoying typ
On Mon, Apr 25, 2011 at 2:21 PM, Simon Riggs wrote:
>> Right, but the trick is how you identify which blocks you need to
>> zero. You used the word "damaged", which to me implied that the block
>> had been modified in some way but ended up with other than the
>> expected contents, so that somethi
On Mon, Apr 25, 2011 at 1:18 PM, Peter Eisentraut wrote:
> On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
>> So the topic of "real" "stored procedures" came up again. Meaning a
>> function-like object that executes outside of a regular transaction,
>> with the ability to start and sto
Robert Haas writes:
> ... There's a similar stanza for sequences, but that one uses
> ereport(WARNING...) rather than ereport(ERROR...). We could either
> remove that stanza entirely (making foreign tables consistent with
> views) or change ERROR to WARNING (making it consistent with
> sequences)
On 04/25/2011 02:18 PM, Peter Eisentraut wrote:
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
So the topic of "real" "stored procedures" came up again. Meaning a
function-like object that executes outside of a regular transaction,
with the ability to start and stop SQL transactio
All,
> �I'm not aware that we've set
>>> any dates for 9.2 CommitFests yet ...
I thought the idea of setting the initial CF for July 15th for 9.1 was
that we would consistently have the first CF in July every year? As
discussed at that time, there's value to our corporate-sponsored
developers in
On Mon, Apr 25, 2011 at 1:42 PM, Robert Haas wrote:
> On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs wrote:
>> On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas wrote:
>>> On Apr 24, 2011, at 1:22 PM, Simon Riggs wrote:
Unlogged tables are a good new feature.
>>>
>>> Thanks.
>>>
I noticed Br
On tor, 2011-04-21 at 18:24 +0300, Peter Eisentraut wrote:
> So the topic of "real" "stored procedures" came up again. Meaning a
> function-like object that executes outside of a regular transaction,
> with the ability to start and stop SQL transactions itself.
I would like to add a note about th
Peter Eisentraut writes:
> On mån, 2011-04-25 at 13:11 -0400, Tom Lane wrote:
>> Or we could go in the direction of making hostssl lines be a silent
>> no-op in both cases, but that doesn't seem like especially
>> user-friendly design to me. We don't treat any other cases in
>> pg_hba.conf compa
On Mon, Apr 25, 2011 at 7:00 PM, Leonardo Francalanci wrote:
>> The amount of data loss on a big
>> table will be <1% of the data loss
>>caused by truncating the whole table.
>
> If that 1% is random (not time/transaction related), usually you'd rather
> have an empty table.
Why do you think it
On Mon, Apr 25, 2011 at 2:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane wrote:
>> I'm not sure I quite understood what you were saying there, but I'm
>> coming around to the view that this is already 100% consistent with
>> the way views are handled:
>
On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh wrote:
> On 2011-04-25 20:00, Leonardo Francalanci wrote:
>>> The amount of data loss on a big table will be <1% of the data
>>> loss caused by truncating the whole table.
>>
>> If that 1% is random (not time/transaction related), usually you'd
>> rath
Jesper Krogh wrote:
> On 2011-04-25 20:00, Leonardo Francalanci wrote:
>>> The amount of data loss on a big table will be <1% of the data
>>> loss caused by truncating the whole table.
>>
>> If that 1% is random (not time/transaction related), usually
>> you'd rather have an empty table. In othe
On mån, 2011-04-25 at 13:35 -0400, Robert Haas wrote:
> Hmm, it appears we had some pre-existing inconsistency here, because
> ALL TABLES IN currently includes views.
Which makes sense because you use GRANT ... ON TABLE to grant privileges
to views.
> That's weird, but
> it'll be even more weird
On mån, 2011-04-25 at 19:12 +0200, Magnus Hagander wrote:
> We need to be very careful about ignoring *anything* in pg_hba.conf,
> since it's security configuration. Doing it silently is even worse.
You're not really "ignoring" anything. It's just not going to be a
match.
--
Sent via pgsql-hac
On 2011-04-25 20:00, Leonardo Francalanci wrote:
> The amount of data loss on a big table will be <1% of the data
> loss caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd
rather have an empty table. In other words: is a table that is not
On mån, 2011-04-25 at 13:11 -0400, Tom Lane wrote:
> Or we could go in the direction of making hostssl lines be a silent
> no-op in both cases, but that doesn't seem like especially
> user-friendly design to me. We don't treat any other cases in
> pg_hba.conf comparably AFAIR.
We ignore "local" e
Robert Haas writes:
> On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane wrote:
> I'm not sure I quite understood what you were saying there, but I'm
> coming around to the view that this is already 100% consistent with
> the way views are handled:
> rhaas=# create view v as select 1;
> CREATE VIEW
> rha
> The amount of data loss on a big
> table will be <1% of the data loss
>caused by truncating the whole table.
If that 1% is random (not time/transaction related), usually you'd rather have
an empty table. In other words: is a table that is not consistant with anything
else in the db useful?
--
On Mon, Apr 25, 2011 at 1:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> Hmm, it appears we had some pre-existing inconsistency here, because
>> ALL TABLES IN currently includes views. That's weird, but
>> it'll be even more weird if we adopt the approach suggested by this
>> patch, which crea
Magnus Hagander writes:
> On Mon, Apr 25, 2011 at 19:38, Tom Lane wrote:
>> While I'm looking at this, I notice that here (and in some other places
>> in pg_hba.conf) we say "not supported on this platform" which seems
>> rather bogus to me. It implies that it's not possible to have SSL
>> suppo
On mån, 2011-04-25 at 09:17 -0400, Robert Haas wrote:
> it'll be harder to organize reviewers (see esp. the note
> by Greg Smith in that regard),
As far as I'm concerned, those who run the commit fests will have to
work out how to best configure the commit fests. I have no strong
feelings about m
I have two separate ideas, but they are kind of connected,
(1) Make the detailed error message available in SPs and not only the short
error message (SQLERRM)
When debugging errors in stored procedures, I often add an exception handler
and print the values of declared variables to the log.
Unfo
On Mon, Apr 25, 2011 at 19:38, Tom Lane wrote:
> Magnus Hagander writes:
>> Yeah, better make any misconfiguration very clear - let's throw an error.
>
> OK, so we need something like (untested)
>
> if (token[4] == 's') /* "hostssl" */
> {
> #ifdef USE_SSL
> + if (!
Peter Eisentraut writes:
> Since some people didn't like removing the hint about "installcheck",
> I'd suggest just removing the "exit 1", which should then be pretty
> consistent overall.
Works for me.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
Dne 25.4.2011 18:16, Alvaro Herrera napsal(a):
> Excerpts from Tomas Vondra's message of dom abr 24 13:49:31 -0300 2011:
>
>> Right now I do have a very simple tool that reads a given file and
>> performs a lot of checks at the block level (as described in bufpage.h),
>> and the next step should b
Robert Haas writes:
> Hmm, it appears we had some pre-existing inconsistency here, because
> ALL TABLES IN currently includes views. That's weird, but
> it'll be even more weird if we adopt the approach suggested by this
> patch, which creates ALL FOREIGN TABLES IN but allows ALL
> TABLES IN t
On mån, 2011-04-25 at 13:12 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2011-04-25 at 11:22 -0400, Tom Lane wrote:
> >> The proposed patch is to fix it, not remove it. Surely that's more
> >> useful than a no-op target.
>
> > The proposed patch will support make check for contr
Magnus Hagander writes:
> Yeah, better make any misconfiguration very clear - let's throw an error.
OK, so we need something like (untested)
if (token[4] == 's')/* "hostssl" */
{
#ifdef USE_SSL
+if (!EnableSSL)
+{
+ereport(LOG,
+
On Wed, Apr 20, 2011 at 11:08 AM, Robert Haas wrote:
> On Wed, Apr 20, 2011 at 9:59 AM, Tom Lane wrote:
>> Shigeru Hanada writes:
>>> Attached patch implements along specifications below. It also includes
>>> documents and regression tests. Some of regression tests might be
>>> redundant and r
On Mon, Apr 25, 2011 at 19:18, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Apr 25, 2011 at 18:59, Robert Haas wrote:
>>> It's not clear to me what behavior you are proposing. Would we
>>> disregard the hostssl line or treat it as an error?
>
>> It would absolutely have to be treat it a
On Mon, Apr 25, 2011 at 1:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Apr 25, 2011 at 12:52 PM, Tom Lane wrote:
>>> I'm inclined to think that the correct fix is to make parse_hba_line,
>>> where it first realizes the line is "hostssl", check not only that SSL
>>> support is compiled
Magnus Hagander writes:
> On Mon, Apr 25, 2011 at 18:59, Robert Haas wrote:
>> It's not clear to me what behavior you are proposing. Would we
>> disregard the hostssl line or treat it as an error?
> It would absolutely have to be treat it as an error. another option
> would be to throw a more s
1 - 100 of 156 matches
Mail list logo
