On Thu, Jul 28, 2011 at 3:51 AM, Robert Haas wrote:
> All that having been said, even if I haven't made any severe
> conceptual errors in the above, I'm not sure how well it will work in
> practice. On the plus side, taking a snapshot becomes O(1) rather
> than O(MaxBackends) - that's good. On
On Jul28, 2011, at 04:51 , Robert Haas wrote:
> One fly in the ointment is that 8-byte
> stores are apparently done as two 4-byte stores on some platforms.
> But if the counter runs backward, I think even that is OK. If you
> happen to read an 8 byte value as it's being written, you'll get 4
> byt
On Wed, Oct 20, 2010 at 10:07 PM, Tom Lane wrote:
> > I wonder whether we could do something involving WAL properties --- the
> > current tuple visibility logic was designed before WAL existed, so it's
> > not exploiting that resource at all. I'm imagining that the kernel of a
> > snapshot is jus
2011/7/26 _石头 :
[... cut ...]
> I do not know how to use the second syntax:RETURNS TABLE '('
> table_func_column_list ')' createfunc_opt_list opt_definition.
> May someone help me to write a simple example of this syntax!
> Thank you very much. Looking forward for your help!
(
On Thu, Jul 28, 2011 at 3:46 AM, Simon Riggs wrote:
> Sounds like the right set of thoughts to be having.
Thanks.
> If you do this, you must cover subtransactions and Hot Standby. Work
> in this area takes longer than you think when you take the
> complexities into account, as you must.
Right.
On Thu, Jul 28, 2011 at 4:16 AM, Florian Pflug wrote:
> On Jul28, 2011, at 04:51 , Robert Haas wrote:
>> One fly in the ointment is that 8-byte
>> stores are apparently done as two 4-byte stores on some platforms.
>> But if the counter runs backward, I think even that is OK. If you
>> happen to r
On Thu, Jul 28, 2011 at 6:50 AM, Hannu Krosing wrote:
> On Wed, Oct 20, 2010 at 10:07 PM, Tom Lane wrote:
>> > I wonder whether we could do something involving WAL properties --- the
>> > current tuple visibility logic was designed before WAL existed, so it's
>> > not exploiting that resource at
> Now that we have coninhcnt, conislocal etc... we can probably support
> ONLY. But I agree with Robert it's probably a bit more than an
> afternoon to crank out :-)
>
Heh, agreed :), I was just looking for some quick and early feedback. So
what we need is basically a way to indicate that a partic
On Wed, Jul 27, 2011 at 7:51 PM, Tom Lane wrote:
> Phil Sorber writes:
>> Currently if you use 'ALTER ROLE rolename SET ROLE', pg_dumpall will
>> dump an 'ALTER ROLE' out right after the 'CREATE ROLE' statement.
>
> I think pg_dumpall is the very least of your problems if you do
> something like
On Wed, Jul 27, 2011 at 8:28 PM, daveg wrote:
> My client has been seeing regular instances of the following sort of problem:
On what version of PostgreSQL?
> If simplicity worked, the world would be overrun with insects.
I thought it was... :-)
--
Robert Haas
EnterpriseDB: http://www.enterp
Nikhil Sontakke writes:
> What we need is to persist information of a particular constraint to be as
> specified - ONLY for this table. We could do that by adding a new column in
> pg_constraint like 'connoinh' or something, but I guess we would prefer not
> to get into the initdb business.
Uh, w
On Thu, Jul 28, 2011 at 9:43 AM, Nikhil Sontakke
wrote:
> Alternatively we could bring about the same
> by using a combination of conislocal and coninhcnt. For ONLY constraints, we
> will need to percolate this information down to the point where we define it
> in the code. We can then mark ONLY c
> This approach certainly can't work, because a table can be both an
> inheritance parent and an inheritance child. It could have an ONLY
> constraint, and also inherit a copy of the same constraint for one or
> more parents. IOW, the fact that conislocal = true does not mean that
> coninhcount i
On Wed, Jul 27, 2011 at 2:29 PM, Robert Haas wrote:
> The reason the benefit is smaller is, I believe, because the previous
> numbers were generated with the lazy vxid locks patch applied, and
> these were generated against master. With the lock manager as a
> bottleneck, the sinval stuff doesn't
Robert Haas writes:
> On Wed, Jul 27, 2011 at 7:51 PM, Tom Lane wrote:
>> I think pg_dumpall is the very least of your problems if you do
>> something like that. We probably ought to forbid it entirely.
> Well, we had a long discussion of that on the thread Phil linked to,
> and I don't think t
On Thu, Jul 28, 2011 at 10:01 AM, Nikhil Sontakke
wrote:
> Yeah, in your case too an initdb would be required, so might as well go down
> the route of a new column. Any preferences for the name?
> connoinh
> conisonly
> constatic or confixed
I'd probably pick conisonly from those choices.
--
Ro
On Thu, 2011-07-28 at 09:38 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 6:50 AM, Hannu Krosing wrote:
> > On Wed, Oct 20, 2010 at 10:07 PM, Tom Lane wrote:
> >> > I wonder whether we could do something involving WAL properties --- the
> >> > current tuple visibility logic was designed bef
On Tue, Jul 26, 2011 at 7:58 PM, Josh Berkus wrote:
> Jim,
>
>> That's why I'd be opposed to any partitioning scheme that removed the
>> ability to have different fields in different children. We've found that
>> ability to be very useful. Likewise, I think we need to have intelligent
>> plans
On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing wrote:
> My hope was, that this contention would be the same than simply writing
> the WAL buffers currently, and thus largely hidden by the current WAL
> writing sync mechanisma.
>
> It really covers just the part which writes commit records to WAL,
Robert Haas writes:
> On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing wrote:
>> My hope was, that this contention would be the same than simply writing
>> the WAL buffers currently, and thus largely hidden by the current WAL
>> writing sync mechanisma.
>>
>> It really covers just the part which
Hi.
I install netbeans 7. When i try to configure postgresql project, path
is set up incorectly - gcc not found
How to set the path ?
--
pasman
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/ma
On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing wrote:
> > My hope was, that this contention would be the same than simply writing
> > the WAL buffers currently, and thus largely hidden by the current WAL
> > writing sync mechanisma.
> >
> >
Hannu Krosing writes:
> On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote:
>> I'm confused by this, because I don't think any of this can be done
>> when we insert the commit record into the WAL stream.
> The update to stored snapshot needs to happen at the moment when the WAL
> record is cons
On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 28, 2011 at 10:17 AM, Hannu Krosing
>> wrote:
>>> My hope was, that this contention would be the same than simply writing
>>> the WAL buffers currently, and thus largely hidden by the current WAL
>>> writing
On Thu, 2011-07-28 at 10:45 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote:
> >> I'm confused by this, because I don't think any of this can be done
> >> when we insert the commit record into the WAL stream.
>
> > The update to stored snaps
On Thu, Jul 28, 2011 at 11:10 AM, Hannu Krosing wrote:
> My main point was, that we already do synchronization when writing wal,
> why not piggyback on this to also update latest snapshot .
Well, one problem is that it would break sync rep.
Another problem is that pretty much the last thing I wa
Robert Haas wrote:
> Peter Eisentraut wrote:
>> I would like to argue for reverting this. If you want to
>> word-smith details like this, "relation" doesn't carry any
>> additional meaning. PG hackers know that internally, a
>> "relation" is a table, view, index, sequence, etc., but for the
>
2011/7/28 pasman pasmański :
> I install netbeans 7. When i try to configure postgresql project, path
> is set up incorectly - gcc not found
>
> How to set the path ?
Install GCC?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
-
On Thu, 2011-07-28 at 17:10 +0200, Hannu Krosing wrote:
> On Thu, 2011-07-28 at 10:45 -0400, Tom Lane wrote:
> > Hannu Krosing writes:
> > > On Thu, 2011-07-28 at 10:23 -0400, Robert Haas wrote:
> > >> I'm confused by this, because I don't think any of this can be done
> > >> when we insert the co
On Thu, 2011-07-28 at 11:15 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 11:10 AM, Hannu Krosing wrote:
> > My main point was, that we already do synchronization when writing wal,
> > why not piggyback on this to also update latest snapshot .
>
> Well, one problem is that it would break sy
Robert Haas writes:
> On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane wrote:
>> But should we rethink that? Your point that hot standby transactions on
>> a slave could see snapshots that were impossible on the parent was
>> disturbing. Should we look for a way to tie "transaction becomes
>> visible
On Wed, 2011-07-27 at 22:51 -0400, Robert Haas wrote:
> On Wed, Oct 20, 2010 at 10:07 PM, Tom Lane wrote:
> > I wonder whether we could do something involving WAL properties --- the
> > current tuple visibility logic was designed before WAL existed, so it's
> > not exploiting that resource at all.
On Thu, 2011-07-28 at 11:57 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane wrote:
> >> But should we rethink that? Your point that hot standby transactions on
> >> a slave could see snapshots that were impossible on the parent was
> >> disturbing. Sh
On Thu, 2011-07-28 at 18:05 +0200, Hannu Krosing wrote:
> But it is also possible, that you can get logically consistent snapshots
> by protecting only some ops. for example, if you protect only insert and
> get snapshot, then the worst that can happen is that you get a snapshot
> that is a few co
Robert,
> If the value is less than v1, put it in a partition called p1.
> If the value is less than v2, put it in a position called p2.
>
> If the value is not less than any of the above, put it in a partition
> called poverflow.
>
> I like that design, not least but also not only because it's
On Thu, 2011-07-28 at 18:48 +0200, Hannu Krosing wrote:
> On Thu, 2011-07-28 at 18:05 +0200, Hannu Krosing wrote:
>
> > But it is also possible, that you can get logically consistent snapshots
> > by protecting only some ops. for example, if you protect only insert and
> > get snapshot, then the w
On Thu, Jul 28, 2011 at 12:53 PM, Josh Berkus wrote:
> Robert,
>
>> If the value is less than v1, put it in a partition called p1.
>> If the value is less than v2, put it in a position called p2.
>>
>> If the value is not less than any of the above, put it in a partition
>> called poverflow.
> S
On Thu, Jul 28, 2011 at 11:57 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane wrote:
>>> But should we rethink that? Your point that hot standby transactions on
>>> a slave could see snapshots that were impossible on the parent was
>>> disturbing. Should
On Thu, Jul 28, 2011 at 11:36 AM, Hannu Krosing wrote:
> On Thu, 2011-07-28 at 11:15 -0400, Robert Haas wrote:
>> On Thu, Jul 28, 2011 at 11:10 AM, Hannu Krosing
>> wrote:
>> > My main point was, that we already do synchronization when writing wal,
>> > why not piggyback on this to also update l
On Thu, Jul 28, 2011 at 10:05 AM, Robert Haas wrote:
>> I'll also test out creating and dropping some tables.
>
> Still need to work on this one.
And there results are in. I set up the following sophisticated test
script for pgbench:
CREATE TEMP TABLE foo (a int);
DROP TABLE foo;
And then did
On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 11:57 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Thu, Jul 28, 2011 at 10:33 AM, Tom Lane wrote:
> >>> But should we rethink that? Your point that hot standby transactions on
> >>> a slave could see snapshot
Hannu Krosing writes:
> So the basic design could be "a sparse snapshot", consisting of 'xmin,
> xmax, running_txids[numbackends] where each backend manages its own slot
> in running_txids - sets a txid when aquiring one and nulls it at commit,
> possibly advancing xmin if xmin==mytxid.
How is th
On Thu, 2011-07-28 at 21:32 +0200, Hannu Krosing wrote:
> On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
>
> > Hmm, interesting idea. However, consider the scenario where some
> > transactions are using synchronous_commit or synchronous replication,
> > and others are not. If a transacti
Hannu Krosing writes:
> On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
>> We can't make either transaction visible without making
>> both visible, and we certainly can't acknowledge the second
>> transaction to the client until we've made it visible. I'm not going
>> to say that's so horri
On Thu, 2011-07-28 at 15:42 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
> >> We can't make either transaction visible without making
> >> both visible, and we certainly can't acknowledge the second
> >> transaction to the client until we
On Thu, 2011-07-28 at 15:38 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > So the basic design could be "a sparse snapshot", consisting of 'xmin,
> > xmax, running_txids[numbackends] where each backend manages its own slot
> > in running_txids - sets a txid when aquiring one and nulls it at co
Hannu Krosing wrote:
> but I still think that it is right semantics to make your commit
> visible to others, even before you have gotten back the
> confirmation yourself.
Possibly. That combined with building snapshots based on the order
of WAL entries of commit records certainly has several
On Thu, Jul 28, 2011 at 3:32 PM, Hannu Krosing wrote:
>> Hmm, interesting idea. However, consider the scenario where some
>> transactions are using synchronous_commit or synchronous replication,
>> and others are not. If a transaction that needs to wait (either just
>> for WAL flush, or for WAL
On Thu, Jul 28, 2011 at 3:40 PM, Hannu Krosing wrote:
> On Thu, 2011-07-28 at 21:32 +0200, Hannu Krosing wrote:
>> On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
>>
>> > Hmm, interesting idea. However, consider the scenario where some
>> > transactions are using synchronous_commit or synch
On Thu, Jul 28, 2011 at 4:12 PM, Kevin Grittner
wrote:
> Hannu Krosing wrote:
>> but I still think that it is right semantics to make your commit
>> visible to others, even before you have gotten back the
>> confirmation yourself.
>
> Possibly. That combined with building snapshots based on the o
On Thu, Jul 28, 2011 at 10:20:57AM -0400, Robert Haas wrote:
> What Itagaki Takahiro proposed a year ago was basically something
> where you would say, OK, I want to partition on this column (or maybe
> expression). And then you say:
>
> If the value is less than v1, put it in a partition called
On Thu, 2011-07-28 at 16:20 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 3:40 PM, Hannu Krosing wrote:
> > On Thu, 2011-07-28 at 21:32 +0200, Hannu Krosing wrote:
> >> On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
> >>
> >> > Hmm, interesting idea. However, consider the scenario wh
Aidan Van Dyk writes:
> On Thu, Jul 28, 2011 at 12:53 PM, Josh Berkus wrote:
>> Second, the key-based partitioning I described would actually be
>> preferred to what you describe by a lot of users I know, because it's
>> even simpler than what you propose, which means less contract DBA work
>> th
On Thu, Jul 28, 2011 at 4:36 PM, Hannu Krosing wrote:
> so in case of stuck slave the syncrep transcation is committed after
> crash, but is not committed before the crash happens ?
Yep.
> ow will the replay process get stuc gaian during recovery ?
Nope.
--
Robert Haas
EnterpriseDB: http://ww
On ons, 2011-07-27 at 23:21 +0200, Florian Pflug wrote:
> On Jul27, 2011, at 23:08 , Peter Eisentraut wrote:
> > Well, offhand I would expect that passing an XML value to XMLATTRIBUTES
> > would behave as in
> >
> > SELECT XMLELEMENT(NAME "t", XMLATTRIBUTES(XMLSERIALIZE(content '&'::XML
> > AS te
Robert Haas wrote:
> Having transactions become visible in the same order on the master
> and the standby is very appealing, but I'm pretty well convinced
> that allowing commits to become visible before they've been
> durably committed is throwing the "D" an ACID out the window. If
> synchrono
On Tue, Jul 26, 2011 at 9:24 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
>
> Let me know if you have questions on the approach taken.
I realized that approach which comes as replace to loaded-subtrees keeping
is unclear to me. We save paths between node buffers. But those
On 28.07.2011 23:57, Alexander Korotkov wrote:
On Tue, Jul 26, 2011 at 9:24 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Let me know if you have questions on the approach taken.
I realized that approach which comes as replace to loaded-subtrees keeping
is unclear to m
On Thu, Jul 28, 2011 at 09:46:41AM -0400, Robert Haas wrote:
> On Wed, Jul 27, 2011 at 8:28 PM, daveg wrote:
> > My client has been seeing regular instances of the following sort of
> > problem:
> On what version of PostgreSQL?
9.0.4.
I previously said:
> > This occurs on postgresql 9.0.4. on 3
On Thu, 2011-07-28 at 14:27 -0400, Robert Haas wrote:
> > Right, but if the visibility order were *defined* as the order in which
> > commit records appear in WAL, that problem neatly goes away. It's only
> > because we have the implementation artifact that "set my xid to 0 in the
> > ProcArray" i
Jeff Davis wrote:
> Wouldn't the same issue exist if one transaction is waiting for
> sync rep (synchronous_commit=on), and another is waiting for just
> a WAL flush (synchronous_commit=local)? I don't think that a
> synchronous_commit=off is required.
I think you're right -- basically, to mak
"Kevin Grittner" wrote:
> to make visibility atomic with commit
I meant:
to make visibility atomic with WAL-write of the commit record
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgs
On Fri, Jul 29, 2011 at 1:10 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> gistFindCorrectParent() should take care of that.
>
OK, now it seems that I understood. I need to verify amount memory needed
for paths because it seems that they tends to accumulate. Also I need to
- Цитат от Hannu Krosing (ha...@2ndquadrant.com), на 28.07.2011 в 22:40
-
>>
>> Maybe this is why other databases don't offer per backend async commit ?
>>
>
Isn't Oracle's
COMMIT WRITE NOWAIT;
basically the same - ad hoc async commit? Though their idea of backend do not
maps
exac
On Thu, Jul 28, 2011 at 4:54 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Having transactions become visible in the same order on the master
>> and the standby is very appealing, but I'm pretty well convinced
>> that allowing commits to become visible before they've been
>> durably committ
On Thu, 2011-07-28 at 16:42 -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 4:36 PM, Hannu Krosing wrote:
> > so in case of stuck slave the syncrep transcation is committed after
> > crash, but is not committed before the crash happens ?
>
> Yep.
>
> > ow will the replay process get stuc gai
On Thu, Jul 28, 2011 at 5:46 PM, daveg wrote:
> On Thu, Jul 28, 2011 at 09:46:41AM -0400, Robert Haas wrote:
>> On Wed, Jul 27, 2011 at 8:28 PM, daveg wrote:
>> > My client has been seeing regular instances of the following sort of
>> > problem:
>> On what version of PostgreSQL?
>
> 9.0.4.
>
> I
On Thu, Jul 28, 2011 at 11:54 PM, Kevin Grittner
wrote:
> (4) We communicate acceptable snapshots to the replica to make the
> order of visibility visibility match the master even when that
> doesn't match the order that transactions returned from commit.
I wonder if some interpretation of 2 pha
On Fri, Jul 29, 2011 at 2:20 AM, Robert Haas wrote:
> Well, again, there are three levels:
>
> (A) synchronous_commit=off. No waiting!
> (B) synchronous_commit=local transactions, and synchronous_commit=on
> transactions when sync rep is not in use. Wait for xlog flush.
> (C) synchronous_commit=
On Thu, Jul 28, 2011 at 7:54 PM, Ants Aasma wrote:
> On Thu, Jul 28, 2011 at 11:54 PM, Kevin Grittner
> wrote:
>> (4) We communicate acceptable snapshots to the replica to make the
>> order of visibility visibility match the master even when that
>> doesn't match the order that transactions retu
On Thu, Jul 28, 2011 at 8:12 PM, Ants Aasma wrote:
> On Fri, Jul 29, 2011 at 2:20 AM, Robert Haas wrote:
>> Well, again, there are three levels:
>>
>> (A) synchronous_commit=off. No waiting!
>> (B) synchronous_commit=local transactions, and synchronous_commit=on
>> transactions when sync rep is
On Thu, Jul 28, 2011 at 03:03:05PM -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 10:05 AM, Robert Haas wrote:
> >> I'll also test out creating and dropping some tables.
> >
> > Still need to work on this one.
>
> And there results are in. I set up the following sophisticated test
> script
On Thu, Jul 28, 2011 at 11:05 PM, Noah Misch wrote:
> The comparison I had in mind was (a) master + lazy-vxid + [1]sinval-fastpath
> vs. (b) master + lazy-vxid + [2]sinval-hasmessages. The only claimed benefit
> of
> [2] over [1], as far as I can see, is invulnerability to the hazard described
On Thu, Jul 28, 2011 at 07:45:01PM -0400, Robert Haas wrote:
> On Thu, Jul 28, 2011 at 5:46 PM, daveg wrote:
> > On Thu, Jul 28, 2011 at 09:46:41AM -0400, Robert Haas wrote:
> >> On Wed, Jul 27, 2011 at 8:28 PM, daveg wrote:
> >> > My client has been seeing regular instances of the following sort
74 matches
Mail list logo
