Here is a test of the fast insert patch. The patch has gone through some
changes, so this set of tests is to see the current performance impact
compared with HEAD.
The test is simple: inserting a bunch of integer arrays into a table
with a GIN index on the array column.
I'm testing with small wo
Koichi Suzuki writes:
> It's simply because we should not refer to system catalog during the recovery.
I don't understand how this is connected to anything to do with prefetching?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand P
Sorry, I attached incorrect patch file.
It is the correct one.
KaiGai Kohei wrote:
Robert,
The attached patch is a draft to replace RedHat/Fedora RPM centric
expressions, to add a reference at "Database Roles and Privileges"
chapter and a bit cleanups for the latest revision (r1467).
In the pre
On Mon, 2009-01-26 at 09:48 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > In various places in current HEAD we throw a checkpoint when we want to
> > be certain that all buffers have been flushed.
> >
> > In recovery, a checkpoint isn't always a restartpoint for two reasons:
> > timin
On Sun, 2009-01-25 at 19:56 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >> 2. Kill all connections by given user. Hmm, not used for anything,
> >> actually. Should remove the roleId argument from GetConflictingVirtualXIDs.
> >
> > No, because we still need to add code to kill-connect
On Sun, 2009-01-25 at 12:13 +, Grzegorz Jaskiewicz wrote:
> On 2009-01-25, at 09:04, Simon Riggs wrote:
>
> >
> > On Sat, 2009-01-24 at 21:58 +0200, Heikki Linnakangas wrote:
> >> When replaying a DROP TABLE SPACE, you first try to remove the
> >> directory, and if that fails, you assume that
--On 25. Januar 2009 13:36:35 -0500 Tom Lane wrote:
But per spec, UPDATABLE should be the default (if not now, then
eventually). Are you proposing
CREATE [OR REPLACE] [[NOT] UPDATABLE] VIEW ...
? Seems confusing.
Good point. We need a better phrasing to restore the old behavior, m
Hi,
Simon Riggs wrote:
> On Sun, 2009-01-25 at 19:56 +0200, Heikki Linnakangas wrote:
>> Simon Riggs wrote:
2. Kill all connections by given user. Hmm, not used for anything,
actually. Should remove the roleId argument from GetConflictingVirtualXIDs.
>>> No, because we still need to add
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
> If we want to ensure that 8.5 development opens soon, what we have to
> do is reject those two patches, revert updatable views, and finish up
> the other stuff (which is all small and could likely be dealt with in
> a week or two). That puts u
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
> If we want to ensure that 8.5 development opens soon, what we have to
> do is reject those two patches, revert updatable views, and finish up
> the other stuff (which is all small and could likely be dealt with in
> a week or two). That puts us
Simon Riggs wrote:
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
Any release with big
features in it will take longer, whether you wait a year, or not.
Well, big features that land early in the release cycle don't delay the
release. Just the ones that are submitted in the last commit f
> There is another thing that's bothering me, though, which is that the
> present approach to dumping rules isn't adequate. Consider the
> following scenario:
>
> 1. You create a view that the system considers updatable, so
> it creates
> some automatic rules.
>
> 2. You don't want those rules
On Mon, Jan 26, 2009 at 11:35 AM, Heikki Linnakangas
wrote:
> I'm sure it depends on the user. Users that are more interested in the
> features we already have in the bag like window functions and WITH-clause,
> will obviously prefer to release earlier without hot standby. And users that
> want h
Simon Riggs wrote:
I don't think that particular example is a good one since the whole
point of the archive is that it should be off-server. If we're going to
be exact about the example then we should give a more realistic one,
like using scp. Unfortunately, there is no secure-remote-move command
Zdenek Kotala wrote:
Alvaro Herrera píše v pá 23. 01. 2009 v 11:04 -0300:
Zdenek Kotala wrote:
I attached patch which add capability to have single record for all
realation kind in the reloption list. It is usefull in situation when
all parameters are same for all relation kinds.
Do you have a
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 discards qualifiers from pointer
target type
and if n
On Sun, Jan 25, 2009 at 12:06 PM, Tom Lane wrote:
> Particularly with regard to hot standby, which by any sane reading was
> not close to being committable on 1 November (a fortiori from the fact
> that it's *still* not committable despite large amounts of later work).
While I haven't follwed e
On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
> Particularly with regard to hot standby, which by any sane reading was
> not close to being committable on 1 November (a fortiori from the fact
> that it's *still* not committable despite large amounts of later
> work).
I've wasted much time i
> Simon has put a lot of time into Hot Standby and has followed the
> pseudo-defacto community process from design through what he believes to be
> near-completion; he can't be sure of completion until someone reviews his
> work.
I think this is a fair critique.
> Yet, albeit with almost no revie
On Sun, 2009-01-25 at 16:19 +, Simon Riggs wrote:
> On Fri, 2009-01-23 at 21:30 +0200, Heikki Linnakangas wrote:
>
> > Ok, then I think we have a little race condition. The startup process
> > doesn't get any reply indicating that the target backend has
> > processed
> > the SIGINT and set
On Mon, 2009-01-26 at 13:35 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sun, 2009-01-25 at 12:06 -0500, Tom Lane wrote:
> >
> >> Any release with big
> > features in it will take longer, whether you wait a year, or not.
>
> Well, big features that land early in the release cycle
Simon Riggs wrote:
>
> On Mon, 2009-01-26 at 13:35 +0200, Heikki Linnakangas wrote:
>
> > Well, big features that land early in the release cycle don't delay the
> > release. Just the ones that are submitted in the last commit fest.
>
> Has that ever happened? :-)
>
> I don't think its chance w
Jonah H. Harris wrote:
Looking forward, if no one
wanted to review these patches in November,
I did, and many others were active in the discussion too.
and seemingly no one wants to review them now,
I do. Thank you for your appreciation :-(.
how can we expect this to change for 8.5? Can
>>> Robert Haas wrote:
> Still, I agree that if there's anything we should be putting our
> effort into as a community right now, it's this feature. If we got
> Hot Standby in the next release and everything else in the
CommitFest
> got bumped, I think a lot of people would consider that a good
Robert Haas wrote:
At a minimum, I think the following patches from the CommitFest wiki
should be returned with feedback or rejected:
1. SE-PostgreSQL. We handled this one badly, but there's not enough
time to fix it now. 8.5.
Unacceptable.
Please make it clear how many items should be fixed
On Mon, 2009-01-26 at 12:05 -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> >
> > On Mon, 2009-01-26 at 13:35 +0200, Heikki Linnakangas wrote:
> >
> > > Well, big features that land early in the release cycle don't delay the
> > > release. Just the ones that are submitted in the last commit
Simon Riggs writes:
> I fail to see how rejecting unreviewed patches provides benefit for
> users, developers or sponsors.
Nobody has suggested rejecting either sync replication or standby database.
The debate here is over whether to commit into 8.4 or into 8.5.
Put another way, the choice he
Heikki Linnakangas writes:
> Not really, except maybe started 6 months too late. Big patches simply take a
> long time to mature.
>
> Looking back at the timeline for hot standby, it doesn't look unreasonable at
> all:
>
> September: First discussion about the user-visible behavior, transaction
>
Peter Eisentraut wrote:
>> I don't think that particular example is a good one since the whole
>> point of the archive is that it should be off-server. If we're going to
>> be exact about the example then we should give a more realistic one,
>> like using scp. Unfortunately, there is no secure-remo
Gregory Stark writes:
> Put another way, the choice here is whether to have a half-baked delayed 8.4
> release in 6 months or a polished on-time 8.5 release in 12 months. Either way
> the feature ships and on a not terribly different timeline either.
This is pretty much exactly how I see it. *Ho
On Mon, Jan 26, 2009 at 6:48 AM, Zeugswetter Andreas OSB sIT
wrote:
>
>
> Is that why other db's only make views updateable, that are created
> "WITH CHECK OPTION" ? Should we also follow that path ?
>
no, the standard says that if the query expression is updatable the
view is updatable
--
At
Andrew Dunstan wrote:
Something happened about 80 hours ago that caused my mingw buildfarm
member (gcc 3.4.2 on Win XP Pro SP2) to hang at the check stage. It
looks like it's hung in initdb.
I wonder if it could be this commit:
Log Message:
---
Make win32 builds always do SetEnvir
Tom Lane writes:
> Gregory Stark writes:
>> Put another way, the choice here is whether to have a half-baked delayed 8.4
>> release in 6 months or a polished on-time 8.5 release in 12 months. Either
>> way
>> the feature ships and on a not terribly different timeline either.
>
> This is pretty
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 23. 01. 2009 v 23:57 -0500:
Zdenek Kotala wrote:
Andrew Dunstan píše v pá 09. 01. 2009 v 12:16 -0500:
Sure, we can easily have buildfarm's initdb step set any locale (and
encoding, for that matter) we like. That's a simple ch
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
> Gregory Stark writes:
>> Put another way, the choice here is whether to have a half-baked delayed 8.4
>> release in 6 months or a polished on-time 8.5 release in 12 months. Either
>> way
>> the feature ships and on a not terribly different timel
Heikki Linnakangas writes:
> Jonah H. Harris wrote:
>> how can we expect this to change for 8.5? Can anyone point
>> out something Simon did wrong in this process?
> Not really, except maybe started 6 months too late. Big patches simply
> take a long time to mature.
Yeah, exactly. When we dec
On 1/26/09, Tom Lane wrote:
> Gregory Stark writes:
> > Put another way, the choice here is whether to have a half-baked delayed
> 8.4
> > release in 6 months or a polished on-time 8.5 release in 12 months. Either
> way
> > the feature ships and on a not terribly different timeline either.
>
On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure wrote:
> What about a compromise solution: release 8.4 now, then focus on
> wrapping up the big ticket items that didn't make it into 8.4 into a
> quick (as possible) 8.5 release. This means no fests.
That would depend on timing then. Trying to
Dave Page writes:
> On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
>> This is pretty much exactly how I see it. *Hot standby is not ready*,
> So can you give us an idea of what parts of the code are in need of
> rethinking etc? I assume you've looked at it now if you can estimate
> it's going
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
>>> This is pretty much exactly how I see it. *Hot standby is not ready*,
>
>> So can you give us an idea of what parts of the code are in need of
>> rethinking etc? I assume
On Mon, Jan 26, 2009 at 04:40:12PM +0100, Albe Laurenz wrote:
> Peter Eisentraut wrote:
> >> I don't think that particular example is a good one since the
> >> whole point of the archive is that it should be off-server. If
> >> we're going to be exact about the example then we should give a
> >> mo
"Jonah H. Harris" writes:
> On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure wrote:
>> What about a compromise solution: release 8.4 now, then focus on
>> wrapping up the big ticket items that didn't make it into 8.4 into a
>> quick (as possible) 8.5 release. This means no fests.
> That would d
On 1/26/09, Jonah H. Harris wrote:
> On Mon, Jan 26, 2009 at 11:11 AM, Merlin Moncure wrote:
> > What about a compromise solution: release 8.4 now, then focus on
> > wrapping up the big ticket items that didn't make it into 8.4 into a
> > quick (as possible) 8.5 release. This means no fests.
>
>
On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane wrote:
> > That would depend on timing then. Trying to get people to upgrade to 8.4
> is
> > going to be difficult if they're waiting on Hot Standby, which means less
> > in-the-field testing of the 8.4 code base until the 8.5 release.
>
> [ deja vu...
>>> Tom Lane wrote:
> Jeff Davis writes:
>> There you see a snapshot of the table that never existed. Either
the
>> snapshot was taken before the UPDATE, in which case i=3 should be
>> included, or it was taken after the UPDATE, in which case i=4 should
be
>> included. So atomicity is broken for
pgtune is now on pgFoundry: http://pgfoundry.org/projects/pgtune/
I just released an update to there, and attached here for the archives is
that same code.
Progress since the last code drop to this list:
-All of the necessary integer handling needed was extracted from guc.c and
implemented,
Tom Lane writes:
> Dave Page writes:
>> On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
>>> This is pretty much exactly how I see it. *Hot standby is not ready*,
>
>> So can you give us an idea of what parts of the code are in need of
>> rethinking etc? I assume you've looked at it now if you
Simon Riggs wrote:
Rather than signalling, we could use a hasconflict boolean for each proc
in a shared data structure. It can be read without spinlock, but should
only be written while holding spinlock.
Each time we read a block we check if hasconflict is set. If it is, we
grab spinlock, rechec
Dave Page wrote:
On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane wrote:
Dave Page writes:
On Mon, Jan 26, 2009 at 3:58 PM, Tom Lane wrote:
This is pretty much exactly how I see it. *Hot standby is not ready*,
So can you give us an idea of what parts of the code are in need of
rethinking etc? I
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 sell to me.
>
I think I understand the other perspective on t
>>> Jeff Davis wrote:
> In fact, it's probably most similar to UPDATE ... RETURNING, which
will
> give the same result (that breaks atomicity or isolation, depending
on
> your point of view), which is correct for READ COMMITTED isolation
> level.
READ COMMITTED is not supposed to be able to vie
Dave Page writes:
> On Mon, Jan 26, 2009 at 4:20 PM, Tom Lane wrote:
>> ... (If you expect me to sign off on it you can
>> figure it'll be a couple of months even for that to happen...)
> Well there is one of the problems imho - the project is getting too
> big and the patches are getting too c
On Mon, Jan 26, 2009 at 11:44 AM, Jonah H. Harris
wrote:
> On Mon, Jan 26, 2009 at 11:33 AM, Tom Lane wrote:
>>
>> > That would depend on timing then. Trying to get people to upgrade to
>> > 8.4 is
>> > going to be difficult if they're waiting on Hot Standby, which means
>> > less
>> > in-the-fi
> 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
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
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
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 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
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
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
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;
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
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
>>> 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
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
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
>>> 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
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
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
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
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 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
>>> 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, 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
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 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
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 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
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
>>> 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
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
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
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
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
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
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
>>> 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 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
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
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
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
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,
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
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
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
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
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
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
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
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
1 - 100 of 153 matches
Mail list logo
