On Tue, 2011-10-11 at 13:22 -0400, Robert Haas wrote:
> The real issue is that the costing estimates need to be accurate, and
> that's where the rubber hits the road. Otherwise, even if we pick the
> right way to scan the table, we may do silly things up the line when
> we go to start constructing
On 11.10.2011 23:21, Simon Riggs wrote:
If the normal default_transaction_isolation = read committed and all
transactions that require serializable are explicitly marked in the
application then there is no way to turn off SSI without altering the
application. That is not acceptable, since it caus
Josh Berkus writes:
> The reason I want to have the dependant roles created as part of a
> database dump is so that we can ship around dump files as a single file,
> and restore them with a single command. This is considerably simpler
> than the current requirements, which are:
> 1. pg_dumpall t
On Tue, Oct 11, 2011 at 4:21 PM, Kääriäinen Anssi
wrote:
> This is probably a silly idea, but I have been wondering about the
> following idea: Instead of having visibility info in the row header,
> have a couple of row visibility slots in the page header. These slots
> could be shared between row
Joe Conway writes:
> On 10/11/2011 02:07 PM, Kevin Grittner wrote:
>> I would certainly vote for enforcing on the SET and not causing an
>> error on the attempt to change the limit. ...
>> What problems do you see with that?
> Yeah, I don't know why it need be handled any different than say
> A
On Tue, Oct 11, 2011 at 4:00 PM, Florian Pflug wrote:
> On Oct11, 2011, at 21:27 , Robert Haas wrote:
>> Alternatively, we could try to graft the concept of a self-clustering
>> table on top of the existing heap implementation. But I'm having
>> trouble seeing how that would work. The TODO descr
On Tue, Oct 11, 2011 at 3:18 PM, Josh Berkus wrote:
>
>> The trouble is that if we VACUUM and then ANALYZE, we'll often get
>> back a value very close to 100%, but then the real value may diminish
>> quite a bit before the next auto-analyze fires. I think if we can
>> figure out what to do about
> Some testing notes
> --
> select pg_start_backup('x');
> ERROR: full_page_writes on master is set invalid at least once since
> latest checkpoint
>
> I think this error should be rewritten as
> ERROR: full_page_writes on master has been off at some point since
> late
> There seems to be agreement on something for (2), and it won't be hard.
> (1) would probably be much more complex. Essentially we'd need to add a
> new object type for roles, I think. But won't (2) give you most of what
> you need for (1) anyway? AIUI, your problem is that the roles might not
>
On 10/11/2011 02:07 PM, Kevin Grittner wrote:
> Tom Lane wrote:
>
>> This isn't exactly a trivial matter. What happens for instance if
>> you try to change the limit, and there are already active values
>> outside the limit in some processes?
>
> I would certainly vote for enforcing on the SE
Andrew Dunstan wrote:
> Attached are two patches, one to remove some infelicity in the entab
> makefile, and the other to allow skipping specifying the typedefs file
I have applied the 'entab' Makefile fix.
--
Bruce Momjian http://momjian.us
EnterpriseDB
Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug wrote:
>
> > That experience has taught me that backwards compatibility, while very
> > important in a lot of cases, has the potential to do just as much harm
> > if overdone.
>
> Agreed. Does my suggestion represent overdoing
On 11-10-11 11:17 AM, Jun Ishiduka wrote:
> Done.
>
> Updated patch attached.
>
I have taken Jun's latest patch and applied it on top of Fujii's most
recent patch. I did some testing with the result but nothing theory
enough to stumble on any race conditions.
Some testing notes
--
Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 10:22 PM, Tom Lane wrote:
> > Simon Riggs writes:
> >> How could I change the viewpoint of the group without making rational
> >> arguments when it matters?
> >
> > Well, you make your arguments, and you see if you convince anybody.
> > On these specif
On Tue, Oct 11, 2011 at 10:30 PM, Florian Pflug wrote:
> That experience has taught me that backwards compatibility, while very
> important in a lot of cases, has the potential to do just as much harm
> if overdone.
Agreed. Does my suggestion represent overdoing it? I ask for balance,
not an ext
Simon Riggs wrote:
> They ask comparative questions like "What is the risk of
> upgrade?", "How much testing is required?"
> I never met a customer yet that has an automated test suite
> designed to stress the accuracy of results under concurrent
> workloads
I'll try to provide some informat
On 10/11/2011 03:50 PM, Josh Berkus wrote:
Acording the docs, I assume -r is only roles, while -g includes
tablespace, so what you want is already available in pg_dumpall.
No, it's not. You don't seem to be actually reading any of my proposals.
(1) I cannot produce a single file in custom du
Robert Haas wrote:
> On Wed, Mar 23, 2011 at 1:48 AM, Fujii Masao wrote:
> > On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas wrote:
> >> On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers wrote:
> >>> This is OK and expected. ?But then it continues (in the logfile) with:
> >>>
> >>> FATAL: ?lock file "
On Tue, Oct 11, 2011 at 10:22 PM, Tom Lane wrote:
> Simon Riggs writes:
>> How could I change the viewpoint of the group without making rational
>> arguments when it matters?
>
> Well, you make your arguments, and you see if you convince anybody.
> On these specific points, you've failed to sway
On Oct11, 2011, at 22:55 , Simon Riggs wrote:
> Probably as a matter of policy all new features that effect semantics
> should have some kind of compatibility or off switch, if easily
> possible.
There's a huge downside to that, though. After a while, you end up
with a gazillion settings, each inf
On Tue, Oct 11, 2011 at 10:00 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> "You'll have to retest your apps" just isn't a good answer
>
> For which major PostgreSQL releases have you recommended that people
> deploy their apps without retesting?
None. People don't always follow my advice,
Simon Riggs writes:
> How could I change the viewpoint of the group without making rational
> arguments when it matters?
Well, you make your arguments, and you see if you convince anybody.
On these specific points, you've failed to sway the consensus AFAICT,
and at some point you have to accept t
On Tue, Oct 11, 2011 at 9:53 PM, Bruce Momjian wrote:
> Simon Riggs wrote:
>> > Simon seems to value backward-compatibility more than the average
>> > hackers poster. ?The lack of complaints about 9.1 I think means that the
>> > hackers decision of _not_ providing a swich was the right one.
>>
>>
Tom Lane wrote:
> This isn't exactly a trivial matter. What happens for instance if
> you try to change the limit, and there are already active values
> outside the limit in some processes?
I would certainly vote for enforcing on the SET and not causing an
error on the attempt to change the l
Robert Haas writes:
> Alternatively, we could try to graft the concept of a self-clustering
> table on top of the existing heap implementation. But I'm having
> trouble seeing how that would work. The TODO describes it as
> something like "maintain CLUSTER ordering", but that's a gross
> oversim
On Tue, Oct 11, 2011 at 9:37 PM, Kevin Grittner
wrote:
> It would certainly be a trivial change to
> implement; the problem is convincing others that it's a good idea.
I don't want it, I just think we need it now. "You'll have to retest
your apps" just isn't a good answer and we should respect t
Alexander Korotkov writes:
> On Wed, Oct 12, 2011 at 12:35 AM, Tom Lane wrote:
>> Maybe, instead of a simple constant amcanreturn column, we need an AM
>> API function that says whether the index can return data.
> I like idea of such AM API function. Since single multicolumn index can use
> mul
Simon Riggs wrote:
> "You'll have to retest your apps" just isn't a good answer
For which major PostgreSQL releases have you recommended that people
deploy their apps without retesting?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Simon Riggs wrote:
> > Simon seems to value backward-compatibility more than the average
> > hackers poster. ?The lack of complaints about 9.1 I think means that the
> > hackers decision of _not_ providing a swich was the right one.
>
> So its been out 1 month and you think that is sufficient time
Tom Lane writes:
> I haven't thought as far ahead as how we might get the information
> needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
> CLASS might be the only way.
It looks to me like it's related to the RECHECK property. Maybe it's
just too late, though.
Regards,
--
Di
Greg Sabino Mullane wrote:
> Kevin Grittner:
>
>> Did these transactions write anything? If not, were they
>> declared to be READ ONLY? If they were, in fact, only reading,
>> it would be interesting to see what the performance looks like if
>> the recommendation to use the READ ONLY attrib
Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 9:28 PM, Bruce Momjian wrote:
>
> > Standard conforming strings
> > was tricky because it was more user-facing, or certainly SQL-facing.
>
> Why is SQL more important than backup?
Because the percentage of database users it affects is different.
Adm
Simon Riggs writes:
> There is no off switch and there should be.
As Greg said, that ship has sailed. I believe that we specifically
discussed the notion of an "off switch" via a GUC or similar during
9.1 development, and rejected it on the grounds that GUCs changing
fundamental transactional be
> Acording the docs, I assume -r is only roles, while -g includes
> tablespace, so what you want is already available in pg_dumpall.
No, it's not. You don't seem to be actually reading any of my proposals.
(1) I cannot produce a single file in custom dump format which includes
both a single dat
On Tue, Oct 11, 2011 at 9:32 PM, Bruce Momjian wrote:
> Greg Sabino Mullane wrote:
> -- Start of PGP signed section.
>> > If the normal default_transaction_isolation = read committed and all
>> > transactions that require serializable are explicitly marked in the
>> > application then there is no
Robert Haas writes:
> On Mon, Oct 10, 2011 at 2:52 PM, Tom Lane wrote:
>> The underlying issue here is whether objects dependent on an extension
>> member should have direct dependencies on the extension too, and if not,
>> how do we prevent that? The recordDependencyOnCurrentExtension calls
>>
On Wed, Oct 12, 2011 at 12:35 AM, Tom Lane wrote:
>
> Hm. I had been supposing that lossless compress functions would just be
> no-ops. If that's not necessarily the case then we might need something
> different from the opclass's decompress function to get back the
> original data. However, th
On Tue, Oct 11, 2011 at 04:32:45PM -0400, Bruce Momjian wrote:
...
> Simon seems to value backward-compatibility more than the average
> hackers poster. The lack of complaints about 9.1 I think means that the
> hackers decision of _not_ providing a swich was the right one.
I wouldn't go that far:
"Kevin Grittner" writes:
> Dimitri Fontaine wrote:
>> Adding the information visible at the right places is a fun
>> project in itself, too :)
> I was thinking a couple new columns in pg_settings (and what backs
> it) would be the main thing, but I haven't searched the source code
> yet. Does
Simon Riggs wrote:
> Greg Sabino Mullane wrote:
>> Eh? It has an off switch: repeatable read.
>
> You mean: if we recode the application and retest it, we can get
> it to work same way as it used to.
>
> To most people that is the same thing as "it doesn't work with
> this release", ask any a
On Tue, Oct 11, 2011 at 9:28 PM, Bruce Momjian wrote:
> Standard conforming strings
> was tricky because it was more user-facing, or certainly SQL-facing.
Why is SQL more important than backup?
There is no good reason to do this so quickly.
--
Simon Riggs http://www.2ndQuad
Josh Berkus wrote:
>
> > Acording the docs, I assume -r is only roles, while -g includes
> > tablespace, so what you want is already available in pg_dumpall.
>
> No, it's not. You don't seem to be actually reading any of my proposals.
>
> (1) I cannot produce a single file in custom dump format
Alexander Korotkov writes:
> On Tue, Oct 11, 2011 at 5:22 PM, Tom Lane wrote:
>> I haven't thought as far ahead as how we might get the information
>> needed for a per-opclass flag. A syntax addition to CREATE OPERATOR
>> CLASS might be the only way.
>>
> Shouldn't it be implemented through add
Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner
> wrote:
>
> >> If you alter the default_transaction_isolation then you will break
> >> applications like this, so it is not a valid way to turn off SSI.
> >
> > I don't follow you here. ?What would break? ?In what fashion? ?Sin
Greg Sabino Mullane wrote:
-- Start of PGP signed section.
> > If the normal default_transaction_isolation = read committed and all
> > transactions that require serializable are explicitly marked in the
> > application then there is no way to turn off SSI without altering the
> > application. That
> The trouble is that if we VACUUM and then ANALYZE, we'll often get
> back a value very close to 100%, but then the real value may diminish
> quite a bit before the next auto-analyze fires. I think if we can
> figure out what to do about that problem we'll be well on our way...
It's not so much
On Tue, Oct 11, 2011 at 9:21 PM, Greg Sabino Mullane wrote:
> Simon Riggs:
>> Most apps use mixed mode serializable/repeatable read and therefore
>> can't be changed by simple parameter. Rewriting the application isn't
>> a sensible solution.
>>
>> I think it's clear that SSI should have had and
On 10/11/2011 04:19 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 10/11/2011 12:40 PM, Bruce Momjian wrote:
Josh Berkus wrote:
pg_dumpall -r --no-passwords which would dump the roles but without
CREATE PASSWORD statements. This would be useful for cloning databases
for use in Dev, Test and
Simon Riggs wrote:
> On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian wrote:
>
> > As much as I appreciate Simon's work in this area, I think we are still
> > unclear if keeping backward-compatibility is worth the complexity
> > required for future users. ?Historically we have been bold in changing
On Tue, Oct 11, 2011 at 3:29 PM, Bruce Momjian wrote:
> As much as I appreciate Simon's work in this area, I think we are still
> unclear if keeping backward-compatibility is worth the complexity
> required for future users. Historically we have been bold in changing
> postgresql.conf settings t
On Tue, Oct 11, 2011 at 5:45 AM, Greg Stark wrote:
> On Mon, Oct 10, 2011 at 9:17 PM, Tom Lane wrote:
>> My intention was to allow it to consider any covering index. You're
>> thinking about the cost estimate, which is really entirely different.
>>
>
> Is there any reason to consider more than o
> If the normal default_transaction_isolation = read committed and all
> transactions that require serializable are explicitly marked in the
> application then there is no way to turn off SSI without altering the
> application. That is not acceptable, since it causes changes in
> application behavi
Robert Haas wrote:
"""
And it seems to me that there could easily be format changes that
would make sense for particular cases, but not across the board,
like:
- index-organized tables (heap is a btree, and secondary indexes
reference the PK rather than the TID; this is how MySQL does it, and
Orac
Robert Haas:
> Serializable mode is much slower on this test, though. On
> REL9_1_STABLE, it's about 8% slower with a single client. At 8
> clients, the difference rises to 43%, and at 32 clients, it's 51%
> slower.
Bummer. Thanks for putting some numbers out there; glad I was able
to jump star
On Tue, Oct 11, 2011 at 6:44 PM, Kevin Grittner
wrote:
>> If you alter the default_transaction_isolation then you will break
>> applications like this, so it is not a valid way to turn off SSI.
>
> I don't follow you here. What would break? In what fashion? Since
> the standard allows any isol
Andrew Dunstan writes:
> On 10/11/2011 12:40 PM, Bruce Momjian wrote:
>> Josh Berkus wrote:
>>> pg_dumpall -r --no-passwords which would dump the roles but without
>>> CREATE PASSWORD statements. This would be useful for cloning databases
>>> for use in Dev, Test and Staging, where you don't what
"Kevin Grittner" writes:
> Well, we've identified a few people who like the idea, but I'm not
> sure we have the degree of consensus we normally look for before
> putting something on the TODO list. After the discussion on this
> thread, are there still any *objections* to allowing bounds or
> su
On Oct11, 2011, at 21:27 , Robert Haas wrote:
> Alternatively, we could try to graft the concept of a self-clustering
> table on top of the existing heap implementation. But I'm having
> trouble seeing how that would work. The TODO describes it as
> something like "maintain CLUSTER ordering", but
Heikki Linnakangas wrote:
> On 11.03.2011 19:41, Tom Lane wrote:
> > Heikki Linnakangas writes:
> >> On 11.03.2011 17:59, Tom Lane wrote:
> >>> But that will be fixed during WAL replay.
> >
> >> Not under the circumstances that started the original thread:
> >
> >> 1. Backend splits a page
> >> 2.
Florian Pflug writes:
> On Oct11, 2011, at 14:43 , David Fetter wrote:
>> I'd recoil at not having ranges default to left-closed, right-open.
>> The use case for that one is so compelling that I'm OK with making it
>> the default from which deviations need to be specified.
I agree with David on t
Josh Berkus wrote:
>
> > What is the logic for not dumping passwords but the CREATE ROLE
> > statement? I don't see how anyone would recognize that behavior as
> > logical. If you want to add a --no-passwords option to pg_dumpall, that
> > seems more logical to me.
>
> That's what I'm suggestin
Magnus Hagander writes:
> On Sun, Oct 9, 2011 at 06:34, Tom Lane wrote:
>> Robert Haas writes:
>>> Should we have another counter for heap fetches avoided? Seems like that
>>> could be useful to know.
>> Hm. I'm hesitant to add another per-table (or per index?) statistics
>> counter because
> What is the logic for not dumping passwords but the CREATE ROLE
> statement? I don't see how anyone would recognize that behavior as
> logical. If you want to add a --no-passwords option to pg_dumpall, that
> seems more logical to me.
That's what I'm suggesting.
Incidentally, what's the diff
On Sun, Oct 9, 2011 at 06:34, Tom Lane wrote:
> Robert Haas writes:
>> On Oct 8, 2011, at 11:04 AM, Tom Lane wrote:
>>> I'm inclined to fix this by changing the test to examine idx_tup_read
>>> not idx_tup_fetch. Alternatively, we could have the test force
>>> enable_indexonlyscan off. Thought
On Tue, Oct 11, 2011 at 3:02 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>>> [implement "clustered index" as a covering index with all columns
>>> which are present in the heap]
>> I guess we could do that, but I'm not convinced there would be
>> much benefit.
>
> The "traditional" way to impl
On 10/10/11 9:53 PM, Fujii Masao wrote:
> Or you think that, to keep the backward compatibility completely,
> recovery.conf should be used as not only a configuration file but also a
> recovery trigger one and it should be renamed to recovery.done at
> the end of recovery?
That's precisely my poin
Robert Haas wrote:
>> [implement "clustered index" as a covering index with all columns
>> which are present in the heap]
> I guess we could do that, but I'm not convinced there would be
> much benefit.
The "traditional" way to implement a clustered index is to have the
leaf level of the ind
On 10/11/2011 11:53 AM, Kevin Grittner wrote:
> Bruce Momjian wrote:
>> Is this a TODO? We might not want to make work_mem SUSET, but it
>> would allow administrators to control this.
>
> Well, we've identified a few people who like the idea, but I'm not
> sure we have the degree of consensus
On Tue, Oct 11, 2011 at 7:08 AM, Royce Ausburn wrote:
> I wonder, could the recent work on index only scans pave the way for auto
> clustered tables? Consider a wide, mostly insert table with some subset of
> columns that I'd like to cluster on. I'm after locality of tuples that are
> very fr
Bruce Momjian wrote:
> Kevin Grittner wrote:
>> Joe Conway wrote:
>>> On 10/10/2011 01:52 PM, Gurjeet Singh wrote:
>>
ALTER USER novice SET MIN_VAL OF statement_timeout TO '1';
-- So that the user cannot turn off the timeout
ALTER DATABASE super_reliable SET ENUM_VALS OF
>>
On Tue, Oct 11, 2011 at 8:36 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> 2011/10/11 Robert Haas :
>>> On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule
>>> wrote:
What do you think about this idea?
>
> It's a bad one.
>
>>> Well, a ROW can contain values of different types; an ARRAY can't.
On Tue, Oct 11, 2011 at 12:18:18PM -0400, Robert Haas wrote:
> On Tue, Oct 11, 2011 at 12:12 PM, David Fetter wrote:
> > Nothing's bad about '[]' per se. What's better, but possibly out
> > of the reach of our current lexing and parsing system, would be
> > things like:
> >
> > [1::int, 10)
>
>
Jeff Davis writes:
> Tom made an observation about '[1,INT_MAX]' thowing an error because
> canonicalization would try to increment INT_MAX. But I'm not
> particularly disturbed by it. If you want a bigger range, use int8range
> or numrange -- the same advice we give to people who want unsigned
>
On Tue, 2011-10-11 at 12:40 -0400, Robert Haas wrote:
> I think using '[)' is fine. At some level, this is just a question of
> expectations. If you expect that int4range(1,4) will create a range
> that includes 4, well, you're wrong. Once you get used to it, it will
> seem normal, and you'll kn
Simon Riggs wrote:
> It's common to find applications that have some transactions
> explicitly coded to use SERIALIZABLE mode, while the rest are in
> the default mode READ COMMITTED. So common that TPC-E benchmark
> has been written as a representation of such workloads.
I would be willing to
Robert Haas wrote:
> Kevin Grittner wrote:
>> Did these transactions write anything? If not, were they
>> declared to be READ ONLY? If they were, in fact, only reading,
>> it would be interesting to see what the performance looks like if
>> the recommendation to use the READ ONLY attribute is
On Tue, Oct 11, 2011 at 6:14 PM, Robert Haas wrote:
> On Tue, Oct 11, 2011 at 1:11 PM, Simon Riggs wrote:
>> On Mon, Oct 10, 2011 at 11:31 PM, Kevin Grittner
>> wrote:
>>> Simon Riggs wrote:
>>>
How do we turn it on/off to allow the overhead to be measured?
>>>
>>> User REPEATABLE READ tra
On Tue, Oct 11, 2011 at 12:43 PM, Bruce Momjian wrote:
> Greg Stark wrote:
>> On Mon, Oct 10, 2011 at 9:17 PM, Tom Lane wrote:
>> > My intention was to allow it to consider any covering index. ?You're
>> > thinking about the cost estimate, which is really entirely different.
>> >
>>
>> Is there a
On Tue, Oct 11, 2011 at 1:11 PM, Simon Riggs wrote:
> On Mon, Oct 10, 2011 at 11:31 PM, Kevin Grittner
> wrote:
>> Simon Riggs wrote:
>>
>>> How do we turn it on/off to allow the overhead to be measured?
>>
>> User REPEATABLE READ transactions or SERIALIZABLE transactions. The
>> easiest way, i
On Tue, Oct 11, 2011 at 12:46 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> I ran my good old pgbench -S, scale factor 100, shared_buffers =
>> 8GB test on Nate Boley's box. I ran it on both 9.1 and 9.2dev,
>> and at all three isolation levels. As usual, I took the median of
>> three 5-minu
On Mon, Oct 10, 2011 at 11:31 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> How do we turn it on/off to allow the overhead to be measured?
>
> User REPEATABLE READ transactions or SERIALIZABLE transactions. The
> easiest way, if you're doing it for all transactions (which I
> recommend) is
Andrew Dunstan wrote:
>
>
> On 10/11/2011 12:40 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> It occurs to me that we could really use two things to make it easier to
> >> move copies of database stuff around:
> >>
> >> pg_dump -r, which would include a CREATE ROLE for all roles needed to
Robert Haas wrote:
> I ran my good old pgbench -S, scale factor 100, shared_buffers =
> 8GB test on Nate Boley's box. I ran it on both 9.1 and 9.2dev,
> and at all three isolation levels. As usual, I took the median of
> three 5-minute runs, which I've generally found adequate to
> eliminate
On 10/11/2011 12:40 PM, Bruce Momjian wrote:
Josh Berkus wrote:
It occurs to me that we could really use two things to make it easier to
move copies of database stuff around:
pg_dump -r, which would include a CREATE ROLE for all roles needed to
restore the database (probably without passwords
Greg Stark wrote:
> On Mon, Oct 10, 2011 at 9:17 PM, Tom Lane wrote:
> > My intention was to allow it to consider any covering index. ?You're
> > thinking about the cost estimate, which is really entirely different.
> >
>
> Is there any reason to consider more than one? I would have expected
> th
Josh Berkus wrote:
> It occurs to me that we could really use two things to make it easier to
> move copies of database stuff around:
>
> pg_dump -r, which would include a CREATE ROLE for all roles needed to
> restore the database (probably without passwords), and
>
> pg_dumpall -r --no-passwords
On Tue, Oct 11, 2011 at 12:30 PM, Jeff Davis wrote:
> On Tue, 2011-10-11 at 12:09 -0400, Robert Haas wrote:
>> The cure seems worse than the disease. What is so bad about '[]'?
>
> OK, so we stick with the 3-argument form. Do we have a default for the
> third argument, or do we scrap it to avoid
On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote:
> > Certainly not the end of the world, but is the convenience of being
> > able to write somerange(a, b) instead of somerange(a, b, '[)')
> > really worth it? I kind of doubt that...
>
> You're making a persuasive argument for the latter base
On Tue, 2011-10-11 at 12:09 -0400, Robert Haas wrote:
> The cure seems worse than the disease. What is so bad about '[]'?
OK, so we stick with the 3-argument form. Do we have a default for the
third argument, or do we scrap it to avoid confusion?
There were some fairly strong objections to using
On Tue, Oct 11, 2011 at 12:12 PM, David Fetter wrote:
> Nothing's bad about '[]' per se. What's better, but possibly out of
> the reach of our current lexing and parsing system, would be things
> like:
>
> [1::int, 10)
That's been discussed before. Aside from the parser issues (which are
formid
On Tue, Oct 11, 2011 at 12:09:01PM -0400, Robert Haas wrote:
> On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis wrote:
> > On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote:
> >> > Certainly not the end of the world, but is the convenience of being
> >> > able to write somerange(a, b) instead of s
On Tue, Oct 11, 2011 at 12:03 PM, Jeff Davis wrote:
> On Tue, 2011-10-11 at 06:28 -0700, David Fetter wrote:
>> > Certainly not the end of the world, but is the convenience of being
>> > able to write somerange(a, b) instead of somerange(a, b, '[)')
>> > really worth it? I kind of doubt that...
>>
On Mon, Oct 10, 2011 at 3:59 PM, Kevin Grittner
wrote:
> I do have some concern about whether the performance improvements
> from reduced LW locking contention elsewhere in the code may (in
> whack-a-mole fashion) cause the percentages to go higher in SSI.
> The biggest performance issues in some
> > I can't see a reason why we would use a new WAL record for this,
> > rather than modify the XLOG_PARAMETER_CHANGE record type which was
> > created for a very similar reason.
> > The code would be much simpler if we just extend
> > XLOG_PARAMETER_CHANGE, so please can we do that?
>
> Sure.
>
Kevin Grittner wrote:
> Joe Conway wrote:
> > On 10/10/2011 01:52 PM, Gurjeet Singh wrote:
>
> >> ALTER USER novice SET MIN_VAL OF statement_timeout TO '1';
> >> -- So that the user cannot turn off the timeout
> >>
> >> ALTER DATABASE super_reliable SET ENUM_VALS OF synchronous_commit
> >> TO
Fujii Masao wrote:
> On Tue, Oct 11, 2011 at 6:37 AM, Simon Riggs wrote:
> > On Mon, Oct 10, 2011 at 6:52 PM, Josh Berkus wrote:
> >
> >>> Tatsuo/Josh/Robert also discussed how recovery.conf can be used to
> >>> provide parameters solely for recovery. That is difficult to do
> >>> without causing
Pavel Stehule writes:
> 2011/10/11 Robert Haas :
>> On Tue, Oct 11, 2011 at 4:40 AM, Pavel Stehule
>> wrote:
>>> What do you think about this idea?
It's a bad one.
>> Well, a ROW can contain values of different types; an ARRAY can't.
> yes, I know - but it should be problem only in few cases
On Oct 7, 2011, at 8:47 PM, Joshua D. Drake wrote:
>
> On 10/07/2011 11:40 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Please find attached a patch implementing a basic version of
>>> index-only scans.
>>
>> I'm making some progress with this, but I notice what seems like a
>> missing featur
On Mon, Oct 10, 2011 at 1:38 PM, Kohei KaiGai wrote:
> I'm sorry again. I tought it was obvious from the filenames.
I guess I got confused because you re-posted part 2 without the other
parts, and I got mixed up and thought you were reposting part one.
I've committed a stripped-down version of t
2011/10/11 Merlin Moncure :
> On Tue, Oct 11, 2011 at 8:18 AM, Pavel Stehule
> wrote:
>> 2011/10/11 Merlin Moncure :
>>> On Tue, Oct 11, 2011 at 3:40 AM, Pavel Stehule
>>> wrote:
Hello
A current limits of dynamic work with row types in PL/pgSQL can be
decreased with a possib
1 - 100 of 127 matches
Mail list logo
