Josh Berkus writes:
> The idea behind having new reviewers take on all the small patches, was,
> of course, to give the main committers more time with patches like
> SEPostgres. It worked with other stuff (like Windowing and CTE).
Huh? There were certainly non-committer reviewers for the wind
Bruce Momjian wrote:
OK, time for me to chime in.
I think the outstanding commit-fest items can be broken down into four
sections:
o Log streaming
o Hot standby
o SE-PostgreSQL
o Others
- snip -
SE-PostgreSQL has been in steady development for a year so
Sorry for long description.
Tom Lane wrote:
> Joshua Brindle writes:
>> http://marc.info/?l=selinux&m=115762285013528&w=2
>> Is the original discussion thread for the security model used in the
>> sepostgresql work. Hopefully you'll see some of the evidence you speak of
>> there.
>
> Thanks fo
Pavel Stehule wrote:
2009/1/27 Jaime Casanova :
On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule wrote:
so it could be released. 8.5 should be implemented in shorted
cycle - only one commitfest, that is enough (+3 month) for well
completing SE and replication patches.
we tried this before (8.2
On Tue, Jan 27, 2009 at 3:25 PM, Brendan Jurd wrote:
> On Tue, Jan 27, 2009 at 3:05 PM, Tom Lane wrote:
>>
>> strncpy is generally deprecated; any remaining uses you find of it
>> are probably only there for lack of round tuits. Use strlcpy in new
>> code, unless there's a pretty strong argument
2009/1/27 Jaime Casanova :
> On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule
> wrote:
>> so it could be released. 8.5 should be implemented in shorted
>> cycle - only one commitfest, that is enough (+3 month) for well
>> completing SE and replication patches.
>
> we tried this before (8.2 to 8.3
On Tue, Jan 27, 2009 at 12:40 AM, Pavel Stehule wrote:
> so it could be released. 8.5 should be implemented in shorted
> cycle - only one commitfest, that is enough (+3 month) for well
> completing SE and replication patches.
we tried this before (8.2 to 8.3 i think), the idea was that the next
r
On Mon, Jan 26, 2009 at 6:07 PM, Gregory Stark wrote:
>> I realize in the current system (emailed patches), this would be a horrible
>> pain to maintain such a branch; but perhaps some of the burden could be
>> pushed down to the patch submitters (asking them to merge their own changes
>> into thi
2009/1/27 Joshua D. Drake :
> On Mon, 2009-01-26 at 23:39 -0500, Tom Lane wrote:
>> Josh Berkus writes:
>> > FWIW, I'll comment that what we're seeing here is nothing new.
>
>> Meanwhile it's emerging that the selinux people don't feel qualified to
>> review it either. I'm not quite sure what to
>> The reviewing that happened during this CommitFest did not happen on
>> the basis of who was interested in which patches. There was a bit of
>> that, but for the most part people reviewed the patches that they were
>> asked to review. I assumed (am I the only one?) that the REASON why
>> we we
Robert,
The reviewing that happened during this CommitFest did not happen on
the basis of who was interested in which patches. There was a bit of
that, but for the most part people reviewed the patches that they were
asked to review. I assumed (am I the only one?) that the REASON why
we were n
> I basically applied your fixes as is, expect for the following items:
> - You replaced
> ! Its providing access controls are not _bypassable_ for any clients ...
>by
> ! The access controls implemented by SE-PostgrSQL may not be _biased_ even
> I wanted to express it is "unavoidable" here,
> SEPostgres seems qualitatively different to me, though. I think PG
> people have avoided reviewing it because (a) they weren't interested in
> it and (b) they knew they were unqualified to review it.
I think that you are off-base here. As I've pointed out previously,
nobody was ever ASSIGNED t
On Mon, 2009-01-26 at 23:39 -0500, Tom Lane wrote:
> Josh Berkus writes:
> > FWIW, I'll comment that what we're seeing here is nothing new.
> Meanwhile it's emerging that the selinux people don't feel qualified to
> review it either. I'm not quite sure what to do about that. But "throw
> it in
Josh Berkus writes:
> FWIW, I'll comment that what we're seeing here is nothing new.
Certainly the Hot Standby situation is the same old song, different verse.
(I'm personally of the opinion that the project has usually been better
served when we decided not to postpone a release to wait for a s
On Tue, Jan 27, 2009 at 3:05 PM, Tom Lane wrote:
> Brendan Jurd writes:
>> A quick grep through the backend code shows that strlcpy and strncpy
>> are both in use, with neither having a clear majority. I used strncpy
>> because it is more prevalent within src/backend/utils/adt.
>
> strncpy is ge
All,
FWIW, I'll comment that what we're seeing here is nothing new. We have:
--One invasive patch which everybody (myself included) procrastinated on
reviewing even though we got it early, and:
--One "must have" big complex patch which arrived very late in the
development cycle.
These are
Andrew Dunstan writes:
>> There are same warning on vaquita in buildfarm.
>> http://www.pgbuildfarm.org/cgi-bin/show_stage_log.pl?nm=vaquita&dt=2009-01-26%20210011&stg=make
> Wouldn't we be better off using defined(ENABLE_NLS) instead of
> defined(LC_MESSAGES) ?
No, because the purpose of that
Brendan Jurd writes:
> A quick grep through the backend code shows that strlcpy and strncpy
> are both in use, with neither having a clear majority. I used strncpy
> because it is more prevalent within src/backend/utils/adt.
strncpy is generally deprecated; any remaining uses you find of it
are
Jaime, Bernd,
having said that, i don't think that inventing new syntax is the way
to go... a reloption seems better (thinking a little more, it could be
a problem if the user changes the reloptions of an already created
view)
There's also the issue with backup/restore: we need some kind of sy
OK, time for me to chime in.
I think the outstanding commit-fest items can be broken down into four
sections:
o Log streaming
o Hot standby
o SE-PostgreSQL
o Others
I think we all agree that log streaming is not ready for 8.4, and that
delaying for this featur
Joshua Brindle writes:
> http://marc.info/?l=selinux&m=115762285013528&w=2
> Is the original discussion thread for the security model used in the
> sepostgresql work. Hopefully you'll see some of the evidence you speak of
> there.
Thanks for the link. I took a look through that thread and saw
Dann Corbit wrote:
-Original Message-
From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
ow...@postgresql.org] On Behalf Of Joshua D. Drake
Sent: Monday, January 26, 2009 7:42 PM
To: KaiGai Kohei
Cc: Tom Lane; Ron Mayer; Josh Berkus; Robert Haas; Merlin Moncure;
Jonah H. Harr
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Joshua D. Drake
> Sent: Monday, January 26, 2009 7:42 PM
> To: KaiGai Kohei
> Cc: Tom Lane; Ron Mayer; Josh Berkus; Robert Haas; Merlin Moncure;
> Jonah H. Harris; Gre
On Tue, 2009-01-27 at 12:30 +0900, KaiGai Kohei wrote:
>
> BTW, I have not walked on water yet.
>
I have but I always end up wet. :)
Joshua D. Drake
> Thanks,
--
PostgreSQL - XMPP: jdr...@jabber.postgresql.org
Consulting, Development, Support, Training
503-667-4564 - http://www.command
On Mon, Jan 26, 2009 at 8:47 PM, Josh Berkus wrote:
> Bruce,
>
>>> yes. we detect that and send a warning saying that there not be any rules
>>
>> OK, so we are going to need an option to suppress that warning, even
>> without the problems of upgrades and customization.
>
> Per my response earlier
Tom Lane wrote:
> Ron Mayer writes:
>> Tom Lane wrote:
>>> The second problem is that we're not sure it's really the right thing,
>>> because we have no one who is competent to review the design from a
>>> security standpoint.
>
>> Are we underestimating Kaigai Kohei?
>
> Perhaps he walks on wat
ITAGAKI Takahiro wrote:
Peter Eisentraut wrote:
ITAGAKI Takahiro wrote:
Here is a patch to surpress compiler warnings in pg_locale.c and pg_regress.c.
There are following warnings if nls is enabled:
pg_locale.c: In function `pg_perm_setlocale':
pg_locale.c:161: warning: ass
Joshua Brindle wrote:
> While we haven't been able to analyze the patches directly to
> determine whether the security goals are indeed being met we
> have had much discussion and eventually community agreement on
> the security model being implemented. This happened years ago
> and has since been
On Mon, Jan 26, 2009 at 8:32 AM, Alex Hunsaker wrote:
>
> -the various (only moved not added)
> strncpy(...)
> copy[len] = '\0';
>
> just use strlcpy?
>
Thanks for having a look Alex.
strlcpy would be easier, but I thought there might be portability
concerns re its non-entirely-standard status.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Well, I've been trying to get Red Hat to interest their NSA contacts in
> it, and Bruce and Josh B have been making efforts via EDB and Sun that
> I don't have details about, but nothing much has come of any of that.
It's certainly frustrating to hear that
Jaime Casanova wrote:
SE-Linux: this patch has effectively been in development for 2 years
ourside the core process before putting it in; the forked SEPostgres is in
use in production. KaiGai has been available for 20 hours a week (or more)
to troubleshoot issues and change APIs. I really don't
Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> The problem, in words of one syllable, is that we are not sure we want
>>> it. Do you see a user community clamoring for SEPostgres, or a hacker
>>> community that is willing or able to maintain it?
>
>> No, it
Stephen Frost writes:
> * Ron Mayer (rm...@cheapcomplexdevices.com) wrote:
>> Ah! Then yes, that does say something about the lack of interest.
>> It wasn't obvious to me that people were reaching out beyond these lists.
> Where were we reaching outside the postgres community..?
Well, I've been
Bruce,
yes. we detect that and send a warning saying that there not be any rules
OK, so we are going to need an option to suppress that warning, even
without the problems of upgrades and customization.
Per my response earlier, I think we really logically need an error if
the user specifies
Tom Lane wrote:
Ron Mayer writes:
Tom Lane wrote:
The second problem is that we're not sure it's really the right thing,
because we have no one who is competent to review the design from a
security standpoint.
Are we underestimating Kaigai Kohei?
Perhaps he walks on water, but still I'd l
On Mon, 2009-01-26 at 20:28 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
> >> Then why has *nobody* stepped up to review the design, much less the
> >> whole patch?
>
> > It was only today that I saw an announcement go out to our announ
* Ron Mayer (rm...@cheapcomplexdevices.com) wrote:
> Tom Lane wrote:
> > Hmm, you think selinux people read pgsql-announce? But seriously,
> > we *have* been trying to get people's attention for this patch, both
> > inside and outside the postgres community, for well over a year now.
> > The lack
Tom Lane wrote:
> Hmm, you think selinux people read pgsql-announce? But seriously,
> we *have* been trying to get people's attention for this patch, both
> inside and outside the postgres community, for well over a year now.
> The lack of response has been depressing and (IMHO) telling. Nowhere
On Mon, 2009-01-26 at 20:27 -0500, Stephen Frost wrote:
> * Ron Mayer (rm...@cheapcomplexdevices.com) wrote:
> > What's the right way for us to ask them? No doubt there are some,
> > but how do we expect them to find & join our email list? If we
> > wanted more feedback would it make sense for so
"Joshua D. Drake" writes:
> On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
>> Then why has *nobody* stepped up to review the design, much less the
>> whole patch?
> It was only today that I saw an announcement go out to our announce list
> to try and get people to pop their heads up and help.
* Ron Mayer (rm...@cheapcomplexdevices.com) wrote:
> What's the right way for us to ask them? No doubt there are some,
> but how do we expect them to find & join our email list? If we
> wanted more feedback would it make sense for someone who can speak
> for the project to call them and ask if th
Tom Lane wrote:
> Ron Mayer writes:
>> Are we underestimating Kaigai Kohei?
> Perhaps he walks on water, but still I'd like to have more than one
> person who has confidence that this design and implementation are correct.
Totally fair. I know I'm totally unqualified to review his buoyancy on
wa
On Mon, 2009-01-26 at 15:46 -0600, Kevin Grittner wrote:
> After the COMMIT succeeds, the locks from Session1 are released.
> Session2 acquires its update lock and reads row 2, finds that it
> doesn't match its update criteria, downgrades the lock to shared,
> acquires an update lock on row 3, fin
Ron Mayer writes:
> Tom Lane wrote:
>> The second problem is that we're not sure it's really the right thing,
>> because we have no one who is competent to review the design from a
>> security standpoint.
> Are we underestimating Kaigai Kohei?
Perhaps he walks on water, but still I'd like to hav
On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:
> Then why has *nobody* stepped up to review the design, much less the
> whole patch? The plain truth is that no one appears to care enough to
> expend any real effort. But this patch is far too large and invasive
> to accept on the basis that o
On Monday 26 January 2009 6:31:48 pm Ron Mayer wrote:
> Tom Lane wrote:
[...snip...]
> > The second problem is that we're not sure it's really the right thing,
> > because we have no one who is competent to review the design from a
> > security standpoint. But unless we get past the first problem
Jaime Casanova wrote:
> On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bernd Helmle writes:
> >> > Or what about
> >> > CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
> >> > This looks closer to TEMP|TEMPORARY VIEW, which we already have.
> >>
> >> But per spec, UPDATA
Peter Eisentraut wrote:
> ITAGAKI Takahiro wrote:
> > Here is a patch to surpress compiler warnings in pg_locale.c and
> > pg_regress.c.
> >
> > There are following warnings if nls is enabled:
> > pg_locale.c: In function `pg_perm_setlocale':
> > pg_locale.c:161: warning: assignment di
Tom Lane wrote:
> The problem, in words of one syllable, is that we are not sure we want
> it. Do you see a user community clamoring for SEPostgres, or a hacker
This is a chicken-and-egg type of problem.
Security-conscious users, applications, hackers, and customers will
flock towards whichever
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> The problem, in words of one syllable, is that we are not sure we want
>> it. Do you see a user community clamoring for SEPostgres, or a hacker
>> community that is willing or able to maintain it?
> No, it doesn't have as large a
decibel writes:
> How can I tell which FK constraint that's for? Could we have backend/
> tablecmds.c:transformColumnNameList() report the constraint name?
If it has a name at all, the name was probably made up from the given
column names, so this seems a mite useless.
At some point we might
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus writes:
> > Users: care about HS more than anything else in the world.
>
> I don't think this is correct. There are certainly a lot of users who
> would like an in-core replication solution, but HS by itself is not that
> --- you also need (ne
Joshua Brindle writes:
> Yes, I will look at them to the extent I am able. As I am not familiar with
> the
> postgresql codebase I won't be able to assert the correctness of the hook
> placement (that is, where the security functions are called with respect to
> the
> data they are protecting b
Christopher Browne wrote:
> On Mon, Jan 26, 2009 at 5:42 PM, Ron Mayer
> wrote:
> There has been enough experimentation with git usage during the 8.4 ...
I certainly didn't mean for the idea to be advocating git nor any
changes in 8.4.
I was hoping the main idea was that the part you didn't quot
Ron Mayer writes:
> I realize in the current system (emailed patches), this would be a horrible
> pain to maintain such a branch; but perhaps some of the burden could be
> pushed down to the patch submitters (asking them to merge their own changes
> into this merged branch).
I've considered
On Mon, Jan 26, 2009 at 5:42 PM, Ron Mayer
wrote:
> I realize in the current system (emailed patches), this would be a horrible
> pain to maintain such a branch; but perhaps some of the burden could be
> pushed down to the patch submitters (asking them to merge their own changes
> into this merged
Gregory Stark wrote:
> I think a lot of people weren't aware there was anybody testing this patch
> ...I wonder how many more people are trying it out?
I think I have an idea to improve this aspect for future commit fests.
For a long time at each of my workplaces I've been running a development
i
create table a(a_id serial primary key, a int);
create table b(b_id serial primary key, a_id int not null references a
(id), b int, c_id int not null references c(id));
NOTICE: CREATE TABLE will create implicit sequence "b_id_seq" for
serial column "b.b_id"
NOTICE: CREATE TABLE / PRIMARY KEY
Josh Berkus wrote:
Joshua,
So the security model has been looked at, though not the
implementation and we do have a community of developers, users and
customers interested in this work.
Can you please take a look at it ASAP, then? In the next week, we will
probably decide on whether or not
Bruce Momjian wrote:
Tom Lane wrote:
Bernd Helmle writes:
Or what about
CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
This looks closer to TEMP|TEMPORARY VIEW, which we already have.
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
CREATE [O
On Mon, Jan 26, 2009 at 5:18 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bernd Helmle writes:
>> > Or what about
>> > CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
>> > This looks closer to TEMP|TEMPORARY VIEW, which we already have.
>>
>> But per spec, UPDATABLE should be the default (if not now,
Tom Lane wrote:
> Bernd Helmle writes:
> > Or what about
> > CREATE [OR REPLACE] [UPDATABLE] VIEW ... ?
> > This looks closer to TEMP|TEMPORARY VIEW, which we already have.
>
> But per spec, UPDATABLE should be the default (if not now, then
> eventually). Are you proposing
> CREATE [OR REP
Gregory Stark wrote:
>
> I think a lot of people weren't aware there was anybody testing this patch
> other than Simon and Heikki -- I wasn't until just today. I wonder how many
> more people are trying it out?
I've been running the patch (I think since Jan 5) on a couple dev instances
that were
On Mon, 2009-01-26 at 09:26 -0800, Jeff Davis wrote:
> On Mon, 2009-01-26 at 10:48 -0600, Kevin Grittner wrote:
> > I guess the issue of whether this violation of ACID properties should
> > be considered a bug or a feature is a separate discussion, but calling
> > it a feature seems like a hard sel
On 1/26/09 4:28 PM, "Joshua Brindle" wrote:
> Tom Lane wrote:
>> Josh Berkus writes:
>>> SE-Linux: this patch has effectively been in development for 2 years
>>> ourside the core process before putting it in; the forked SEPostgres is
>>> in use in production. KaiGai has been available for 20
>>> Gregory Stark wrote:
> This example is a case of the same issue we were discussing earlier
> involving "predicate locking". To solve it you need a way to lock
> records that your query *isn't* accessing and may not even exist yet
> to prevent them from being turned into (or inserted as) reco
On Monday 26 January 2009 2:12:02 pm Tom Lane wrote:
> Josh Berkus writes:
> > So, some feedback to make this decision more difficult:
> >
> > Users: care about HS more than anything else in the world.
>
> I don't think this is correct. There are certainly a lot of users who
> would like an in-co
Joshua,
So the security model has been looked at, though not the implementation
and we do have a community of developers, users and customers interested
in this work.
Can you please take a look at it ASAP, then? In the next week, we will
probably decide on whether or not to defer SEPostgres
Josh Berkus wrote:
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in the
On Mon, 2009-01-26 at 15:49 -0500, Tom Lane wrote:
> The problem is that it's not ready and no one is very sure about when
> it will be.
With respect, I've done more than any other developer has done to give
you and the community full information on the patch as it develops. I'm
sorry you don't
On Mon, 2009-01-26 at 15:47 -0500, Merlin Moncure wrote:
> I'd also like to see Simon and or
> Heikki make a strong statement on where things stand _right now_ (not
> in two weeks) :-)
Well, we just found 2 bugs over the weekend, one of which is a
regression from refactoring.
The second bug is
Jeff Davis writes:
> It seems like it would be a challenge to know that the tuple with i=3
> would be updated to a value that matches the search condition j=10. So
> can you tell me a little more about the mechanism by which Sybase solves
> this problem?
This example is a case of the same issue
>>> Jeff Davis wrote:
> On Mon, 2009-01-26 at 14:31 -0600, Kevin Grittner wrote:
>> > Do you re-run the query to find new tuples that might now satisfy
>> > the search condition that didn't before?
>>
>> There can't be any. Blocks taken during the reading of rows so far
>> have not been releas
Tom Lane wrote:
Josh Berkus writes:
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an in-core replication solution, but HS by itself is not
On Mon, 2009-01-26 at 20:12 +, Gregory Stark wrote:
> Merlin Moncure writes:
>
> > HS is working very well (Simon's ongoing work aside). I am pretty
> > confident based on my personal testing that it would represent the
> > project well if committed today.
>
> I think a lot of people weren
bgrosper...@laposte.net
Bernard Grosperrin
BGSoftFactory
Bureau/Domicile 09 53 41 58 18
Mobile 06 75 13 97 17
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, 2009-01-26 at 14:31 -0600, Kevin Grittner wrote:
> > Do you re-run the query to find new tuples that might now satisfy
> > the search condition that didn't before?
>
> There can't be any. Blocks taken during the reading of rows so far
> have not been released, and would preclude the upda
Gregory Stark writes:
> Here's a thought experiment. If it was committable *today* would we be
> willing to go with it and plan to release with it? Assume that it
> would *still* mean a longer beta process, so it would still mean
> releasing in, say April instead of February or March.
"April inst
On 1/26/09, Gregory Stark wrote:
>
> Merlin Moncure writes:
>
> > HS is working very well (Simon's ongoing work aside). I am pretty
> > confident based on my personal testing that it would represent the
> > project well if committed today.
>
>
> I think a lot of people weren't aware there wa
>>> Jeff Davis wrote:
> The tricky part is when an UPDATE with a search condition reads,
> modifies, and writes a value that is used in a search condition for
> another UPDATE.
>
> Every DBMS will block waiting for the first UPDATE to finish. Then
> what?
Either it's totally safe to proceed, o
On 1/26/09, Josh Berkus wrote:
> All,
>
>>> 1) having the last CF on Nov. 1 was a mistake. That put us square in the
>>> path of the US & Christian holidays during the critical integration phase
>>> ..
>>> which means we haven't really had 3 months of integration, we've had
>>> *two*.
>
> Actuall
Merlin Moncure writes:
> HS is working very well (Simon's ongoing work aside). I am pretty
> confident based on my personal testing that it would represent the
> project well if committed today.
I think a lot of people weren't aware there was anybody testing this patch
other than Simon and Hei
On Mon, 2009-01-26 at 13:50 -0600, Kevin Grittner wrote:
> A somewhat dated description for Sybase (it predates their support of
> row level locks and the related predicate locks on indexes) is here:
>
> http://manuals.sybase.com/onlinebooks/group-asarc/srv10024/sag/@Generic__BookTextView/41766;p
Josh Berkus writes:
> So, some feedback to make this decision more difficult:
> Users: care about HS more than anything else in the world.
I don't think this is correct. There are certainly a lot of users who
would like an in-core replication solution, but HS by itself is not that
--- you also
All,
1) having the last CF on Nov. 1 was a mistake. That put us square in the
path of the US & Christian holidays during the critical integration phase ..
which means we haven't really had 3 months of integration, we've had *two*.
Actually, I'm thinking about this again, and made a mistake ab
>>> I wrote:
> Simplified, in a READ COMMITTED transaction a SELECT takes a lock
> which conflicts with update before reading, and holds it until the
> executing statement is done with that table;
That should have said "until after the executing statement completes."
Apologies, but but I just
On Mon, Jan 26, 2009 at 2:36 PM, Josh Berkus wrote:
> All,
>
> So, some feedback to make this decision more difficult:
>
> Users: care about HS more than anything else in the world. I'm convinced
> that if we took a staw poll, 80% of our users would be in favor of waiting
> for HS. This one feat
Merlin,
Not completely. HS is in much better shape than win32 was when it was
pulled from 7.4...the build system wasn't even in place yet nor any of
the major challenges solved (like fork/exec).
HS is working very well (Simon's ongoing work aside). I am pretty
confident based on my personal t
>>> Jeff Davis wrote:
> I don't think this is PostgreSQL-specific, I think non-MVCC database
> systems face this same choice (although the terminology would be
> different).
A somewhat dated description for Sybase (it predates their support of
row level locks and the related predicate locks on
On 1/26/09, Josh Berkus wrote:
> All,
>
> So, some feedback to make this decision more difficult:
>
> Users: care about HS more than anything else in the world. I'm convinced
> that if we took a staw poll, 80% of our users would be in favor of waiting
> for HS. This one feature will make more
On Mon, 2009-01-26 at 11:36 -0800, Josh Berkus wrote:
> All,
>
> So, some feedback to make this decision more difficult:
>
> Users: care about HS more than anything else in the world. I'm
> convinced that if we took a staw poll, 80% of our users would be in
> favor of waiting for HS. This one
Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > I'm not sure that we have any use for the top level you propose; the
> > attached patch just uses the two lower levels, and I think it fits
> > autovacuum usage just fine. Thanks for the idea.
>
> Of course, there's no need to pass the relkind;
Greg,
Things I was hoping for some input on:
-Using default_stats_target=100 doesn't seem controversial anymore,
which makes we wonder if it makes sense to restore the original DW
suggestion of 400 Josh suggested?
I'm going to back off from this. Following our discussion, I did some
testin
All,
So, some feedback to make this decision more difficult:
Users: care about HS more than anything else in the world. I'm
convinced that if we took a staw poll, 80% of our users would be in
favor of waiting for HS. This one feature will make more of a
difference in the number of PG users
On Mon, 2009-01-26 at 11:34 -0600, Kevin Grittner wrote:
> READ COMMITTED is not supposed to be able to view the work of a
> concurrent transactions as PARTLY applied and PARTLY committed, which
> is what's happening here. If one statement in a READ COMMITTED
> transaction sees the uncommitted vie
On 2009-01-26, at 17:34, Kevin Grittner wrote:
. It may not
surprise someone who is intimately familiar with PostgreSQL internals
for a single SELECT statement to see PART of a transactions work, but
it would surprise most users, and is certainly not compliant with the
standard.
+1000
--
Sen
On Mon, 2009-01-26 at 12:47 -0500, Robert Haas wrote:
> How is that going to help? People will still write new code in the
> meanwhile and some of it may be better or more important than the
> stuff that doesn't get committed to 8.4. Artificially saying that
> nothing will be allowed for 8.5 tha
Robert Haas wrote:
The other thing going on here is that HS is extremely important to the
project. If it was up to me, 100% effort would be geared to getting
it out as quickly as possible. I'm just looking for a way to get HS
in the hands of people as quickly as possible that is fair to
everybo
> I think that's baked in the cards no matter what. IMO, the issue is
> that code to review is building up faster than it is getting reviewed,
> so maybe a festless release is nesessary to flush out the difference
> (along with the other held over patches from 8.4).
How is that going to help? Pe
1 - 100 of 153 matches
Mail list logo
