> Linux has *as many if not more* ... MySQL, if memory servers, has a half
> dozen or more ... etc ...
MySQL has a bunch of lists, none of which get much traffic. Honestly,
they should probably be combined.
--
Rob Wultsch
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, 15 May 2010, Jaime Casanova wrote:
On Fri, May 14, 2010 at 8:39 AM, Marc G. Fournier wrote:
And IMHO, that is as much a fault of the 'old timers' on the lists as the
newbies ... if nobody redirects / loosely enforces the mandates of the
various lists, newbies aren't going to learn to
Peter Eisentraut writes:
> On fre, 2010-05-14 at 15:04 +0200, Zdenek Kotala wrote:
>>> The problem is that it contains mix of DOS/Unix end of lines.
> I have added a check to the admin scripts to prevent this in the future.
I wonder if we shouldn't be trying to prevent this at the CVS-checkin
le
On lör, 2010-05-15 at 00:23 -0400, Robert Haas wrote:
> It's a commercial distribution of BSD. I remember it being pretty
> nice when I used it 10+ years ago, but it sounds like it's dead now.
BSDI is the company that produced BSD/OS, which was Bruce's main
development environment at some point,
On lör, 2010-05-15 at 00:15 -0400, Tom Lane wrote:
> I suppose that at least some of the *BSD herd really do predefine some
> of the symbols being attributed to them here, but I would like to see
> something authoritative about which and what.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porte
On fre, 2010-05-14 at 15:04 +0200, Zdenek Kotala wrote:
> Takahiro Itagaki píše v pá 14. 05. 2010 v 19:38 +0900:
> > Zdenek Kotala wrote:
> >
> > > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=2010-05-13%2021:06:01
> > > The problem is that it contains mix of DOS/Unix end of li
Robert Haas írta:
> On Fri, May 14, 2010 at 9:33 AM, Boszormenyi Zoltan wrote:
>
>> If min_sync_replication_clients == 0, then the replication is async.
>> If min_sync_replication_clients == max_wal_senders then the
>> replication is fully synchronous.
>> If 0 < min_sync_replication_clients <
On Fri, May 14, 2010 at 8:39 AM, Marc G. Fournier wrote:
>
> And IMHO, that is as much a fault of the 'old timers' on the lists as the
> newbies ... if nobody redirects / loosely enforces the mandates of the
> various lists, newbies aren't going to learn to post to more appropriate
> ones ...
>
o
On Sat, May 15, 2010 at 12:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, May 15, 2010 at 12:15 AM, Tom Lane wrote:
>>> I'm not even too sure what "bsdi" is, but I'm suspicious of that branch
>>> too. A search of our code finds
>
>> It's a commercial distribution of BSD. I remember it
Robert Haas writes:
> On Sat, May 15, 2010 at 12:15 AM, Tom Lane wrote:
>> I'm not even too sure what "bsdi" is, but I'm suspicious of that branch
>> too. A search of our code finds
> It's a commercial distribution of BSD. I remember it being pretty
> nice when I used it 10+ years ago, but it
On Sat, May 15, 2010 at 12:15 AM, Tom Lane wrote:
> I'm not even too sure what "bsdi" is, but I'm suspicious of that branch
> too. A search of our code finds
It's a commercial distribution of BSD. I remember it being pretty
nice when I used it 10+ years ago, but it sounds like it's dead now.
To
The recently added contrib/pg_upgrade code contains this bit:
/*
* scandir() is originally from BSD 4.3, which had the third argument as
* non-const. Linux and other C libraries have updated it to use a const.
*
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2005-12/
2010/5/14 Tom Lane :
> Robert Haas writes:
>> On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
>> wrote:
>>> [] retrieves a value of a JSON array/object by (one-based) index. In
>>> other words, value[n] is equivalent to selecting the nth row of
>>> json_values(value) (provided value is of type JSO
[moved to -chat]
On Fri, 14 May 2010, Kevin Grittner wrote:
I think that's exactly backwards -- we shouldn't have any traffic on
-general for issues which could reasonably happen in another list. You
can always configure your email to combine lists into a common folder
upon receipt.
*Exact
On Fri, May 14, 2010 at 10:35 PM, Joseph Adams
wrote:
> By the way, I'm considering making it so JSON arrays will be treated
> like objects when it comes to -> and the json_keys function. Thus,
> json_keys('[1,4,9,16,25]') would yield '{1,2,3,4,5}', and
> ('[1,4,9,16,25]'::JSON) -> 3 would yield
On Fri, May 14, 2010 at 11:33 AM, Bruce Momjian wrote:
> Joseph Adams wrote:
>> == array/object conversion ==
>>
>> The json_object function converts a tuple to a JSON object. If there
>> are duplicate column names, there will be duplicate keys in the
>> resulting JSON object.
>>
>> json_object([
"Erik Rijkers" writes:
> I am not sure this is a bug, but I was surprised by the following behaviour
> in HEAD and 8.4.4 (instances built today, 2010.05.14):
> Invalid (?) values like 123_456 are split before the underscore and
> interpreted as
> 123 as "456":
All versions of postgres will pars
I am not sure this is a bug, but I was surprised by the following behaviour
in HEAD and 8.4.4 (instances built today, 2010.05.14):
Invalid (?) values like 123_456 are split before the underscore and interpreted
as
123 as "456":
$ psql -p 6591 -d testdb -c "select 123_456, current_setting('serve
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > One odd thing is we have two paramters that mention hot_standby
> > --- on the master we have to do in postgresql.conf:
> >
> > wal_level = hot_standby
> >
> > and on the slave we do in postgresql.conf:
> >
> > hot_standby = on
> >
>
On Fri, May 14, 2010 at 6:11 PM, Tom Lane wrote:
> Peter Crabtree writes:
>> On Fri, May 14, 2010 at 5:29 PM, Robert Haas wrote:
>>> If we do this, I'm inclined to think that the extra argument to
>>> nextval() should be treated as overriding the base increment rather
>>> than specifying a multi
On Fri, May 14, 2010 at 5:51 PM, Josh Berkus wrote:
>
>>> This would be OK as long as we document it well. We patched the
>>> shutdown the way we did specifically because Fujii thought it would be
>>> an easy fix; if it's complicated, we should revert it and document the
>>> issue for DBAs.
>>
>>
Peter Crabtree writes:
> On Fri, May 14, 2010 at 5:29 PM, Robert Haas wrote:
>> If we do this, I'm inclined to think that the extra argument to
>> nextval() should be treated as overriding the base increment rather
>> than specifying a multiplier for it. Â Other than that nitpick, it
>> sounds li
On Fri, May 14, 2010 at 5:29 PM, Robert Haas wrote:
> On Fri, May 14, 2010 at 5:04 PM, hubert depesz lubaczewski
> wrote:
>> On Fri, May 14, 2010 at 02:07:27PM -0500, Kenneth Marshall wrote:
>>> Hi Peter,
>>>
>>> All you need to do is define your own sequence with an
>>> increment of 500. Look at
On Fri, May 14, 2010 at 5:27 PM, Tom Lane wrote:
> Peter Crabtree writes:
>> Now, I was reminded that I could simply do this:
>
>> SELECT nextval('my_seq') FROM generate_series(1, 500);
>
>> But of course then I would have no guarantee that I would get a
>> contiguous block of ids,
>
> The existi
>> This would be OK as long as we document it well. We patched the
>> shutdown the way we did specifically because Fujii thought it would be
>> an easy fix; if it's complicated, we should revert it and document the
>> issue for DBAs.
>
> I don't understand this comment.
In other words, I'm sayi
On Thu, May 13, 2010 at 1:12 PM, Josh Berkus wrote:
> On 5/12/10 8:07 PM, Robert Haas wrote:
>> I think that would be a good thing to check (it'll confirm whether
>> this is the same bug), but I'm not convinced we should actually fix it
>> that way. Prior to 8.4, we handled a smart shutdown durin
On Fri, May 14, 2010 at 5:04 PM, hubert depesz lubaczewski
wrote:
> On Fri, May 14, 2010 at 02:07:27PM -0500, Kenneth Marshall wrote:
>> Hi Peter,
>>
>> All you need to do is define your own sequence with an
>> increment of 500. Look at:
>>
>> http://www.postgresql.org/docs/8.4/static/sql-createse
Peter Crabtree writes:
> Now, I was reminded that I could simply do this:
> SELECT nextval('my_seq') FROM generate_series(1, 500);
> But of course then I would have no guarantee that I would get a
> contiguous block of ids,
The existing "cache" behavior will already handle that for you,
I belie
Robert Haas writes:
> PM_RECOVERY_CONSISTENT -> PM_HOT_STANDBY
> PMSIGNAL_RECOVERY_CONSISTENT -> PMSIGNAL_BEGIN_HOT_STANDBY
+1. From the point of view of the postmaster, whether the state
transition happens immediately upon reaching consistency, or at a
later time, or perhaps even earlier (if we
Bruce Momjian wrote:
> One odd thing is we have two paramters that mention hot_standby
> --- on the master we have to do in postgresql.conf:
>
> wal_level = hot_standby
>
> and on the slave we do in postgresql.conf:
>
> hot_standby = on
>
> That is a little confusing.
Why? I r
bruce wrote:
> > and my slave recovery.conf was:
> >
> > restore_command = 'cp /u/pg/archive/%f %p' # e.g. 'cp
> > /mnt/server/archivedir/%f %p'
> > standby_mode = 'on'
> > primary_conninfo = 'host=localhost port=5432' # e.g.
> > 'host=localhost port=5432'
> >
Greg Stark wrote:
> If they're interested in performance topics and they're not
> subscribed to -general then they're missing *most* of what they're
> interested in which doesn't take place on -performance.
Well, I for one can't currently suck the end of the fire hose which
is -general, and w
On Fri, May 14, 2010 at 02:07:27PM -0500, Kenneth Marshall wrote:
> Hi Peter,
>
> All you need to do is define your own sequence with an
> increment of 500. Look at:
>
> http://www.postgresql.org/docs/8.4/static/sql-createsequence.html
This is often not enough. For example - I want standard incr
On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
> Florian Pflug writes:
>> All in all, I believe that SHARE and UPDATE row-level locks should be
>> changed to cause concurrent UPDATEs to fail with a serialization
>> error.
>
> I don't see an argument for doing that for FOR SHARE locks, and it
>
On Thu, May 13, 2010 at 11:39 PM, Greg Smith wrote:
> The only real argument to keep some more targeted lists is for the benefit
> of the people who subscribe to them, not we the faithful, so that they can
> have something that isn't a firehose of messages to sort through. Is it
> helpful to novi
On Fri, 14 May 2010, Greg Stark wrote:
On Fri, May 14, 2010 at 4:39 AM, Greg Smith wrote:
Is it
helpful to novices that they can subscribe to a list when they won't be
overwhelmed by traffic, and can ask questions without being too concerned
about being harassed for being newbies? Probably.
On Fri, May 14, 2010 at 4:39 AM, Greg Smith wrote:
> Is it
> helpful to novices that they can subscribe to a list when they won't be
> overwhelmed by traffic, and can ask questions without being too concerned
> about being harassed for being newbies? Probably.
Only if they aren't hoping to get a
Tom Lane wrote:
I can see the need for small tightly-focused special lists.
How about a list devoted to discussions about reorganizing the lists?
It would get plenty of traffic, and then I could not subscribe to that
and have that many less messages to read.
There is only one viable soluti
Stephen Frost wrote:
-- Start of PGP signed section.
> Greetings,
>
> Toying around with FETCH_COUNT today, I discovered that it didn't do
> the #1 thing I really wanted to use it for- query large tables without
> having to worry about LIMIT to see the first couple hundred records.
> The r
On Fri, 14 May 2010, Bruce Momjian wrote:
FYI, I usually email new people privately that cross-posting a question
can cause the question to be ignored. They usually respond positively
and avoid it in the future.
We all have our own methods ... for instance, I just CC'd this to -chat
with a
Kevin Grittner wrote:
> Tom Lane wrote:
>
> > I can't imagine that there's not going to need to be a "catchall"
> > list for problems that don't fit into any of the subcategories.
> >
> > More generally, we already have most of the lists that you
> > suggest, and we already know that people fre
On Fri, May 14, 2010 at 9:33 AM, Boszormenyi Zoltan wrote:
> If min_sync_replication_clients == 0, then the replication is async.
> If min_sync_replication_clients == max_wal_senders then the
> replication is fully synchronous.
> If 0 < min_sync_replication_clients < max_wal_senders then
> the r
On Fri, May 14, 2010 at 9:51 AM, Josh Berkus wrote:
> Second, regarding advocacy: no, absolutely not. -advocacy is a working list
> and not a virtual water cooler.
+1. I would find it very difficult to manage having -advocacy thrown
into -general.
If folks think that information isn't getting
On Fri, 14 May 2010, Josh Berkus wrote:
First off, this is absolutely the wrong list to be discussing management of
PostgreSQL lists. That belongs on pgsql-www.
Actually, this is as good a list as any ... -www is for WWW related
issues, not mailing list ... be as inappropriate there as it wo
Robert Haas writes:
> On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
> wrote:
>> [] retrieves a value of a JSON array/object by (one-based) index. In
>> other words, value[n] is equivalent to selecting the nth row of
>> json_values(value) (provided value is of type JSON). Examples:
>>
>> SELECT
Hi Peter,
All you need to do is define your own sequence with an
increment of 500. Look at:
http://www.postgresql.org/docs/8.4/static/sql-createsequence.html
Regards,
Ken
On Fri, May 14, 2010 at 02:56:18PM -0400, Peter Crabtree wrote:
> Recently, in preparation for migrating an application to p
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie may 14 14:19:30 -0400 2010:
>> What seems more rational is to provide toast.fillfactor but give it
>> min/max/default = 100.
> Adding an entry to intRelOpts should be enough to fix this bug, correct?
I think so, but haven't tested.
Recently, in preparation for migrating an application to postgres, I
got to this part of the manual (which is *excellent* so far, by the
way):
http://www.postgresql.org/docs/8.4/interactive/functions-sequence.html
A quick check with the folks on #postgresql confirmed my
understanding, which was t
Excerpts from Tom Lane's message of vie may 14 14:19:30 -0400 2010:
> The problem is that if any reloption is set for the toast table,
> we build a StdRdOptions struct in which fillfactor is zero, and
> then all the code that actually uses fillfactor honors that.
> And the reason fillfactor gets l
On Fri, May 14, 2010 at 12:03 AM, Takahiro Itagaki
wrote:
> We can index multiple scalar values per row with GIN access method,
> and also can index single vector value per row with GiST AM.
>
> Is it worth having a new AM to index multiple vector values per row?
> It will be an AM for the missing
On Thu, May 13, 2010 at 1:28 AM, Fujii Masao wrote:
> On Thu, May 13, 2010 at 12:10 PM, Robert Haas wrote:
>> Hmm, it seems this is my night to rediscover the wisdom of your
>> previous proposals. I think that state would only be appropriate when
>> we shutdown after reaching consistency, not an
I've been able to reproduce the problem described here:
http://archives.postgresql.org/pgsql-bugs/2010-05/msg00100.php
Do this:
create table foo(f1 text);
alter table foo set (toast.autovacuum_enabled = false);
insert into foo values(repeat('xyzzy',10));
vacuum verbose foo;
Notice that the va
While looking through postmaster.c and xlog.c I discovered that we're
being a little bit loose about our use of terminology. Maybe this was
right when committed (I think, at that point, Hot Standby was always
on) but it's not right any more. It appears that we only enter the
PM_RECOVERY_CONSISTEN
On Fri, May 14, 2010 at 1:15 PM, Robert Haas wrote:
> On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
> wrote:
[snip]
>> == array/object conversion ==
>>
>> The json_object function converts a tuple to a JSON object. If there
>> are duplicate column names, there will be duplicate keys in the
>>
On Fri, 14 May 2010, Kevin Grittner wrote:
Well, redoubling our current efforts to direct people to more
specific lists would accomplish nothing, since doubling zero leaves
you with zero. The description of -general includes:
Agreed ...
Given that, the fact that -admin, -novice, -sql, and -p
On Thu, May 13, 2010 at 9:47 PM, Joseph Adams
wrote:
> The following function returns the type of any JSON value.
>
> json_type as enum ('null', 'string', 'number', 'boolean', 'object', 'array')
> json_type(json) returns json_type
Seems reasonable.
> Would it be a bad idea to give an enum and a
Marc G. Fournier wrote:
On Fri, 14 May 2010, Yeb Havinga wrote:
Marc G. Fournier wrote:
On Thu, 13 May 2010, Alvaro Herrera wrote:
Excerpts from Yeb Havinga's message of jue may 13 15:06:53 -0400 2010:
My $0.02 - I like the whole 'don't sort, search' (or how did they
call
it?) just let th
There is no reason why advocacy can't happen on general. Theoretically
www could be on hackers (although I do see the point of a separate
list).
First off, this is absolutely the wrong list to be discussing management
of PostgreSQL lists. That belongs on pgsql-www. And, I'll point out,
tha
Tom Lane wrote:
> I can't imagine that there's not going to need to be a "catchall"
> list for problems that don't fit into any of the subcategories.
>
> More generally, we already have most of the lists that you
> suggest, and we already know that people frequently don't find the
> most approp
2010/5/14 Bruce Momjian :
> Joseph Adams wrote:
>> == array/object conversion ==
>>
>> The json_object function converts a tuple to a JSON object. If there
>> are duplicate column names, there will be duplicate keys in the
>> resulting JSON object.
>>
>> json_object([content [AS name] [, ...]]) re
Greetings,
Toying around with FETCH_COUNT today, I discovered that it didn't do
the #1 thing I really wanted to use it for- query large tables without
having to worry about LIMIT to see the first couple hundred records.
The reason is simple- psql ignores $PAGER exiting, which means that it
On Fri, 14 May 2010, Yeb Havinga wrote:
Marc G. Fournier wrote:
On Thu, 13 May 2010, Alvaro Herrera wrote:
Excerpts from Yeb Havinga's message of jue may 13 15:06:53 -0400 2010:
My $0.02 - I like the whole 'don't sort, search' (or how did they call
it?) just let the inbox fill up, google is
Joseph Adams wrote:
> == array/object conversion ==
>
> The json_object function converts a tuple to a JSON object. If there
> are duplicate column names, there will be duplicate keys in the
> resulting JSON object.
>
> json_object([content [AS name] [, ...]]) returns json
>
> Likewise, the jso
Bruce Momjian wrote:
> I was able to easily crash the standby server today just by starting it
> and connecting to it via psql. The master was idle. The failure was:
>
> LOG: streaming replication successfully connected to primary
> TRAP: FailedAssertion("!(((xmax) >= ((TransactionI
"Marc G. Fournier" writes:
> why not close down -general so that ppl *have* to use better pick where to
> post their question ...
I can't imagine that there's not going to need to be a "catchall" list
for problems that don't fit into any of the subcategories.
More generally, we already have mos
"Marc G. Fournier" wrote:
> -sql : how to write a query
> -performance : how to improve performance of my queries
> -admin : how to admin the server
> -novice : I'm a new user
> -odbc : how to use ...
> -php : php related interface questions
> -interfaces : more general then -odbc
>
> why not c
On Fri, 14 May 2010, Kevin Grittner wrote:
"Greg Sabino Mullane" wrote:
Would anyone argue against rolling those two (sql and admin) into
-general as a first step?
At the risk of repeating myself, I won't be able to keep up with the
traffic of the combined list; so rather than read 100% of
On Fri, 14 May 2010, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
There is no reason why advocacy can't happen on general. Theoretically
www could be on hackers (although I do see the point of a separate
list).
I don't feel as strong about -advocacy being r
On Fri, 14 May 2010, Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
... is there a reason why, other the fact that we don't do now, that we
can't just put in a restriction against cross posting altogether?
Because that would be shooting ourselves in the foot.
Florian Pflug wrote:
> I must admit that I wasn't able to find an explicit reference to
> Oracle's behavior in their docs, so I had to resort to
> experiments. They do have examples showing how to do FK-like
> constraints with triggers, and those don't contain any warning
> whatsoever about prob
"Greg Sabino Mullane" wrote:
> Would anyone argue against rolling those two (sql and admin) into
> -general as a first step?
At the risk of repeating myself, I won't be able to keep up with the
traffic of the combined list; so rather than read 100% of the
messages from a smaller set, I'll need
On May 14, 2010, at 15:54 , Kevin Grittner wrote:
> Florian Pflug wrote:
>> On May 14, 2010, at 12:56 , Kevin Grittner wrote:
>> unless your patch completely removes support for snapshot
>> isolation (what is current called SERIALIZABLE)
>
> Both SERIALIZABLE and REPEATABLE READ currently map to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> There is no reason why advocacy can't happen on general. Theoretically
> www could be on hackers (although I do see the point of a separate
> list).
I don't feel as strong about -advocacy being removed, but we certainly
can fold in -sql and
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> ... is there a reason why, other the fact that we don't do now, that we
> can't just put in a restriction against cross posting altogether?
Because that would be shooting ourselves in the foot. Cross-posting
is often desirable. If we had a
Florian Pflug wrote:
> On May 14, 2010, at 12:56 , Kevin Grittner wrote:
>> I think that SIREAD locks will generally be cheaper than SELECT
>> FOR UPDATE, since the former don't require any disk I/O and the
>> latter do.
> I can see how a single SIREAD lock can potentially be cheaper than
> a
Fujii Masao írta:
> 2010/4/29 Boszormenyi Zoltan :
>
>> attached is a patch that does $SUBJECT, we are submitting it for 9.1.
>> I have updated it to today's CVS after the "wal_level" GUC went in.
>>
>
> I'm planning to create the synchronous replication patch for 9.0, too.
> My design is o
Takahiro Itagaki píše v pá 14. 05. 2010 v 19:38 +0900:
> Zdenek Kotala wrote:
>
> > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=2010-05-13%2021:06:01
> > The problem is that it contains mix of DOS/Unix end of lines.
>
> I removed two CRs in ja.po.
Thanks. Gothic moth is gree
On May 14, 2010, at 12:56 , Kevin Grittner wrote:
>> True serializable transaction are much more powerful than what I
>> proposed, but at a much higher price too, due to the necessity of
>> SIREAD locks.
>
> I think that SIREAD locks will generally be cheaper than SELECT FOR
> UPDATE, since the fo
On Thu, May 13, 2010 at 8:20 PM, Tatsuo Ishii wrote:
>> > Maybe we could make PostgreSQL a little bit smarter so that it returns
>> > a different code than 57P01 when killed by pg_terminate_backend().
>>
>> Seems reasonable. Does the victim backend currently know why it has been
>> killed?
>
> I d
2010/4/29 Boszormenyi Zoltan :
> attached is a patch that does $SUBJECT, we are submitting it for 9.1.
> I have updated it to today's CVS after the "wal_level" GUC went in.
I'm planning to create the synchronous replication patch for 9.0, too.
My design is outlined in the wiki. Let's work together
[slight rearrangement]
Florian Pflug wrote:
> I'm very exited about the work you're doing
Always nice to hear. :-)
> I view my proposal as pretty orthogonal to that work.
> My proposal allows for simple FK-like constraints to be
> implemented at user-level that are correct for all isola
Zdenek Kotala wrote:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_moth&dt=2010-05-13%2021:06:01
> The problem is that it contains mix of DOS/Unix end of lines.
I removed two CRs in ja.po.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers m
On May 14, 2010, at 5:56 , Jaime Casanova wrote:
> On Thu, May 13, 2010 at 10:13 PM, Takahiro Itagaki
> wrote:
>>
>> Jaime Casanova wrote:
>>
>>> i migrate a ms sql server database to postgres and was trying some
>>> queries from the application to find if everything works right...
>>> when i w
On May 14, 2010, at 2:37 , Greg Stark wrote:
> On Thu, May 13, 2010 at 10:25 PM, Florian Pflug wrote:
>> C1: BEGIN
>> C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
>> C2: BEGIN
>> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> C2: SELECT * FROM t -- Take snapshot before C1 commits
>> C1: COMM
2010/5/14 Greg Stark :
> On Thu, May 13, 2010 at 10:25 PM, Florian Pflug wrote:
>
>> C1: BEGIN
>> C1: SELECT * FROM t WHERE id = 1 FOR UPDATE
>> C2: BEGIN
>> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> C2: SELECT * FROM t -- Take snapshot before C1 commits
>> C1: COMMIT
>> C2: DELETE FROM
Marc G. Fournier wrote:
On Thu, 13 May 2010, Alvaro Herrera wrote:
Excerpts from Yeb Havinga's message of jue may 13 15:06:53 -0400 2010:
My $0.02 - I like the whole 'don't sort, search' (or how did they call
it?) just let the inbox fill up, google is fast enough. What would be
really interes
86 matches
Mail list logo
