Il 18/01/2010 18:42, Magnus Hagander ha scritto:
On Mon, Jan 18, 2010 at 18:31, Matteo Beccati wrote:
Il 18/01/2010 15:55, Magnus Hagander ha scritto:
If it wasn't for the fact that we're knee deep in two other major
projects for the infrastructure team right now, I'd be all over this
:-) But
On 1/17/2010 11:27 AM, Peter Eisentraut wrote:
I have found an Autoconf macro that checks whether the compiler properly
supports C99 inline semantics. This would allow us to replace the
__GNUC__ conditional with HAVE_C99_INLINE, in this case.
At present, PostgreSQL uses only "static inline", w
On Tue, Jan 19, 2010 at 09:11, Matteo Beccati wrote:
> Il 18/01/2010 18:42, Magnus Hagander ha scritto:
>>
>> On Mon, Jan 18, 2010 at 18:31, Matteo Beccati wrote:
>>>
>>> Il 18/01/2010 15:55, Magnus Hagander ha scritto:
If it wasn't for the fact that we're knee deep in two other major
>
2010/1/18 Robert Haas :
> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... Also, I prefer an
>>> API where the escaping function does include the quotes, so I've done
>>> it that way in the attached patch.
>>
>> IMO this function should act as much like PQescapeStr
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident th
2010/1/18 Tom Lane :
> Dean Rasheed writes:
>> Agreed. That's much neater. However, it does introduce a change in
>> behaviour - if you have 2 constraints with the same name in different
>> schemas, one deferrable, and one not, and the non-deferrable one is
>> first on the search path, then you'll
Hi,
In relation to the functions added recently, I found an annoying problem;
pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the
wrong name because pg_xlogfile_name() always uses the current timeline,
and a backend doesn't know the actual timeline related to the location
whi
Hi Jeff,
thanks a lot for your review. I will reply to your review again in
detail but I'd like to answer your two main questions already now.
On Tue, Jan 19, 2010 at 8:08 AM, Jeff Davis wrote:
> * AsyncCommitOrderLock
>
> I believe this needs a re-think. What is the real purpose for
> AsyncComm
On Tue, 2009-12-15 at 20:11 +0900, Hiroyuki Yamada wrote:
> Hot Standby node can freeze when startup process calls LockBufferForCleanup().
> This bug can be reproduced by the following procedure.
>
> 0. start Hot Standby, with one active node(node A) and one standby node(node
> B)
> 1. create tab
Regarding the send_notify function, I have been working on it and have a
patch (attached) that applies on top of Joachim's.
It introduces a send_notify SQL function that calls the Async_Notify C
function.
It's pretty straightforward and will need to be refined to take into
account the encodi
Hi,
Takahiro Itagaki írta:
> Hi, I'm reviewing your patch and have a couple of comments.
>
thanks for the review, comments below.
> Boszormenyi Zoltan wrote:
>
>
>> we have found that auto-prepare causes a problem if the connection
>> is closed and re-opened and the previously prepared qu
> In the
> documentation, the get_bit and set_bit methods are added to a list
> where we state "The following SQL-standard functions work on bit
> strings as well as character strings"; however they are not
> SQL-standard functions and are implemented on binary strings, not
> character strings.
O
On Mon, Jan 18, 2010 at 11:02, Magnus Hagander wrote:
> On Mon, Jan 18, 2010 at 00:52, Greg Smith wrote:
>> Magnus Hagander wrote:
>>>
>>> Maybe this should be "Unrecognized reset target: %s", target, and also
>>> a errhint() saying which targets are allowed. Thoughts?
>>>
>>
>> That seems reason
On Sun, Jan 17, 2010 at 9:57 PM, Alex Hunsaker wrote:
... The idea that we want to support
attdistinct for system tables and index columns was based on a very
specific understanding of what that was going to do; for attoptions,
well, it might make sense for the options that we
On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark wrote:
> Looking at this patch for the commitfest I have a few questions.
So I've touched this patch up a bit:
1) moved the posix_fadvise call to a new fd.c function
pg_fsync_start(fd,offset,nbytes) which initiates an fsync without
waiting on it. Curre
On Tue, Jan 19, 2010 at 2:52 PM, Greg Stark wrote:
> Barring any objections shall I commit it like this?
Actually before we get there could someone who demonstrated the
speedup verify that this patch still gets that same speedup?
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Leonardo F wrote:
>> In the documentation, the get_bit and set_bit methods are added
>> to a list where we state "The following SQL-standard functions
>> work on bit strings as well as character strings"; however they
>> are not SQL-standard functions and are implemented on binary
>> strings, no
On Tuesday 19 January 2010 15:52:25 Greg Stark wrote:
> On Mon, Jan 18, 2010 at 4:35 PM, Greg Stark wrote:
> > Looking at this patch for the commitfest I have a few questions.
>
> So I've touched this patch up a bit:
>
> 1) moved the posix_fadvise call to a new fd.c function
> pg_fsync_start(fd,
Hi,
I found a difference of behaviour between 8.3 and 8.4 on IS NULL with
multi-level arrays with NULL values.
I looked at the Changelog between 8.3 and 8.4, but I didn't find something
really clear about this.
Is this a bug or a known issue or a normal, documented,
difference of behaviour
2010/1/18 KaiGai Kohei :
> (2010/01/10 22:25), Magnus Hagander wrote:
>> The attached patch implements RADIUS authentication (RFC2865-compatible).
>>
>> The main usecase for me in this is the ability to use (token based)
>> one-time-password systems easily with PostgreSQL. These systems almost
>> a
Greg Stark writes:
> 1) moved the posix_fadvise call to a new fd.c function
> pg_fsync_start(fd,offset,nbytes) which initiates an fsync without
> waiting on it. Currently it's only implemented with
> posix_fadvise(DONT_NEED) but I want to look into using sync_file_range
> in the future -- it looks
On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
> the Git repository is missing parts of two non-recent commits.
>
>> We've seen this happen before.
>
> That seems like kind of a blasé attitude toward something upon which
> some people rely.
For the record, I
On Tue, Jan 19, 2010 at 07:49, Robert Haas wrote:
>That will mean that users can't use ALTER TABLE ... ALTER
> COLUMN ... SET STATISTICS DISTINCT for system tables, but I don't
> think that's much of a loss, and it certainly seems cleaner than
> hoping that any additional attoptions we add in the
On Tue, Jan 19, 2010 at 10:44 AM, Magnus Hagander wrote:
> On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
> wrote:
>> Magnus Hagander wrote:
>>
>> the Git repository is missing parts of two non-recent commits.
>>
>>> We've seen this happen before.
>>
>> That seems like kind of a blasé attitud
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
> On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
> We have some existing inline functions in .c files. These can be
> more complicated, so it might be ok if the compiler decides to
> leave them out-of-line. And they are never unreferenced, s
On Tuesday, January 19, 2010, Robert Haas wrote:
> On Tue, Jan 19, 2010 at 10:44 AM, Magnus Hagander wrote:
>> On Mon, Jan 18, 2010 at 01:53, Kevin Grittner
>> wrote:
>>> Magnus Hagander wrote:
>>>
>>> the Git repository is missing parts of two non-recent commits.
>>>
We've seen this h
* Magnus Hagander [100119 10:44]:
> > When we (at Wisconsin State Courts) were using CVS and had scripts to
> > automatically merge changes from one branch to another, we saw this
> > sort of thing unless people were very careful to grab a timestamp in
> > the past for their ranges and use it th
Magnus Hagander wrote:
> Kevin Grittner wrote:
>> Magnus Hagander wrote:
>>
>> the Git repository is missing parts of two non-recent
>> commits.
>>
>>> We've seen this happen before.
>>
>> That seems like kind of a blasé attitude toward something upon
>> which some people rely.
>
> For
iog...@free.fr writes:
> I found a difference of behaviour between 8.3 and 8.4 on IS NULL with
> multi-level arrays with NULL values.
8.3's behavior is just a bug --- try comparing the results when the
values are variables that happen to be null, rather than simple
constant nulls. 8.4 is consist
Magnus Hagander writes:
> 2010/1/18 KaiGai Kohei :
>> The random seed is initialized at BackendRun() with MyProcPid and
>> the time of backend process launched.
>> Then, PostgresMain() -> InitPostgres() -> PerformAuthentication()
>> will be called, and this random() shall be the first call jus
Peter Eisentraut writes:
> On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
>> Or compiler switches could be set to disable all such warnings
>> globally. Warning 4514 is specific to inline functions; so
>> maybe it would be alright to keep it turned off globally.
> ... I think that would
"Kevin Grittner" writes:
> Oh, and what sort of delay do you feel would be "long enough to
> cover any cvs commit including potential network slowness during it
> etc."?
Why should the script make any assumptions about delay at all?
It seems to me that the problem comes from failing to check for
Zoltan,
while testing your patch I went through the test cases and found this in
outofscope.pgc:
> + #include
As we know by now this won't work. :-)
Besides, would you mind simplifying the test case a little bit? There is no
need to have it test all the sqlda stuff, too. I don't mind having t
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Oh, and what sort of delay do you feel would be "long enough to
>> cover any cvs commit including potential network slowness during
>> it etc."?
>
> Why should the script make any assumptions about delay at all?
> It seems to me that the problem come
* Tom Lane [100119 11:47]:
> "Kevin Grittner" writes:
> > Oh, and what sort of delay do you feel would be "long enough to
> > cover any cvs commit including potential network slowness during it
> > etc."?
>
> Why should the script make any assumptions about delay at all?
> It seems to me that th
Takahiro Itagaki wrote:
The conclusion is splitting existing projects into some 'modules',
and getting the modules one by one into core. Voted features are here:
http://wiki.postgresql.org/wiki/ClusterFeatures
This page was a bit messy for someone who didn't attend the meeting to
follow. I j
Michael Meskes írta:
> Zoltan,
>
> while testing your patch I went through the test cases and found this in
> outofscope.pgc:
>
>
>> + #include
>>
>
> As we know by now this won't work. :-)
>
Okay, I will fix it. :-) I forgot it's in there as well.
> Besides, would you mind simplifyi
On Tue, Jan 19, 2010 at 4:13 AM, Pavel Stehule wrote:
> 2010/1/18 Robert Haas :
>> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
>>> Robert Haas writes:
... Also, I prefer an
API where the escaping function does include the quotes, so I've done
it that way in the attached patc
2010/1/19 Robert Haas :
> On Tue, Jan 19, 2010 at 4:13 AM, Pavel Stehule
> wrote:
>> 2010/1/18 Robert Haas :
>>> On Mon, Jan 18, 2010 at 3:26 PM, Tom Lane wrote:
Robert Haas writes:
> ... Also, I prefer an
> API where the escaping function does include the quotes, so I've done
>>>
"Kevin Grittner" wrote:
> I haven't looked at the fromcvs code yet to know how easy or
> hard it would be to use this logic within that package
Well, now I have looked. It's about 2,000 lines of pretty dense
Ruby code (not as many comments as one would hope, especially since
there appears to
On Tue, Jan 19, 2010 at 12:54 PM, Pavel Stehule wrote:
>> I think what you're saying is that you agree with Tom's position that
>> the new escaping function should not add the necessary surrounding
>> quotes, instead leaving that to the user. Is that correct?
>
> yes
Updated patch attached. I s
Robert Haas writes:
> Updated patch attached. I still think this is a bizarre API.
Well, if we had it to do over I'm sure we'd have done it differently,
but the functions are there now and we aren't going to change them ...
regards, tom lane
--
Sent via pgsql-hackers m
On Tue, Jan 19, 2010 at 1:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> Updated patch attached. I still think this is a bizarre API.
>
> Well, if we had it to do over I'm sure we'd have done it differently,
> but the functions are there now and we aren't going to change them ...
I agree, but
Robert Haas writes:
> ... I think as
> long as we're adding a new function, we should make it behave sanely.
> We could even take the opportunity to go back and add a saner version
> of PQescapeStringConn.
Well, it's a bit late in the devel cycle to be inventing from scratch,
but if we did want t
Hey -hackers,
I whipped up a quick patch for supporting some of the common mysql-
based "meta" commands; this is different than some things which have
been discussed in the past, in that it provides just a quick direction
to the appropriate psql command, not an actual alternative syntax for
2010/1/19 Robert Haas :
> On Tue, Jan 19, 2010 at 1:43 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Updated patch attached. I still think this is a bizarre API.
>>
>> Well, if we had it to do over I'm sure we'd have done it differently,
>> but the functions are there now and we aren't going to
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more people to review and test the
patches, and ho
Tim Bunce wrote:
What can I do to help the CommitFest, especially in relation to the
PL/Perl changes?
Tim.
p.s. I've sent an email to the dbi-users and dbi-announce lists
http://www.mail-archive.com/dbi-us...@perl.org/msg32649.html
in the hope of encouraging some more people to review and tes
On Tue, Jan 19, 2010 at 2:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... I think as
>> long as we're adding a new function, we should make it behave sanely.
>> We could even take the opportunity to go back and add a saner version
>> of PQescapeStringConn.
>
> Well, it's a bit late in the dev
On Tue, 2010-01-19 at 12:44 -0600, David Christensen wrote:
> Hey -hackers,
>
> I whipped up a quick patch for supporting some of the common mysql-
> based "meta" commands; this is different than some things which have
> been discussed in the past, in that it provides just a quick direction
On Jan 19, 2010, at 11:10 AM, Tim Bunce wrote:
> What can I do to help the CommitFest, especially in relation to the
> PL/Perl changes?
Start reviewing other patches. An active/helpful patch submitter gets more love.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
Jeff Davis wrote:
On Tue, 2010-01-19 at 12:44 -0600, David Christensen wrote:
Hey -hackers,
I whipped up a quick patch for supporting some of the common mysql-
based "meta" commands; this is different than some things which have
been discussed in the past, in that it provides just a quick d
Robert Haas writes:
> On Tue, Jan 19, 2010 at 2:01 PM, Tom Lane wrote:
>> * include boundary quotes (and E too in the literal case). This would
>> imply telling people they should leave whitespace around the value in
>> the constructed query ... or should we insert leading/trailing spaces
>> to
> I'm not convinced that we should start adding syntax helpers like that
> to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
> Also I can already see people asking "well you already know that this is
> that com
On Tue, 2010-01-19 at 11:43 -0800, Jeff Davis wrote:
> > I'm not convinced that we should start adding syntax helpers like that
> > to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> > to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
> > Also I can already see
Jeff Davis wrote:
I'm not convinced that we should start adding syntax helpers like that
to psql. For now it is an arbitrary subset of MySQL stuff, are we going
to add oracle/db2/mssql/drizzle/mariadb and whatnot later on?
Also I can already see people asking "well you already know that this is
2010/1/15 Boszormenyi Zoltan :
> Jaime Casanova írta:
>> 2010/1/13 Boszormenyi Zoltan :
>>
Your smaller patch is attached, with the above strangeness. :-)
ok, the patch is more simpler than before and seems to be doing things right...
it passes regression tests and my own tests...
David Christensen escreveu:
> I whipped up a quick patch for supporting some of the common mysql-based
> "meta" commands; this is different than some things which have been
> discussed in the past, in that it provides just a quick direction to the
> appropriate psql command, not an actual alternati
On Tue, Jan 19, 2010 at 2:38 PM, Tom Lane wrote:
> As long as it's documented it's okay ... probably ... note that
> conditionally inserting E would get us right back to the place where
> an unsafe usage might appear to work fine in light testing. Maybe
> prepend a space only if prepending E?
Th
2010/1/19 Hitoshi Harada :
> Yeah, that's my point, too. The planner has to distinguish "four" from
> sort pathkeys and to teach the executor the simple information which
> column should be used to determine frame. I was bit wrong because some
> of current executor code isn't like it, like using or
On Fri, Jan 15, 2010 at 12:52 AM, Alex Hunsaker wrote:
> ***
> *** 152,158 CATALOG(pg_attribute,1249) BKI_BOOTSTRAP
> BKI_WITHOUT_OIDS BKI_ROWTYPE_OID(75) BK
> aclitem attacl[1];
>
> /* Column-level options */
> ! aclitem attoptions[1];
> } For
On Tue, 2010-01-19 at 20:52 +0100, Stefan Kaltenbrunner wrote:
> Jeff Davis wrote:
> >> I'm not convinced that we should start adding syntax helpers like that
> >> to psql. For now it is an arbitrary subset of MySQL stuff, are we going
> >> to add oracle/db2/mssql/drizzle/mariadb and whatnot late
I wrote:
> Perhaps it is as simple, though, as using the client's time
> instead of the CVS server's time -- that's one of the things I've
> seen cause problems for this sort of thing using CVS before.
I got a brief consult with a Ruby programmer here under the "if it's
less than ten minutes yo
Robert Haas writes:
> Do you think we should malloc 2n+X bytes all the time, or do you want
> to scan the string once to determine how much space is needed and then
> allocate exactly that much space?
I'd vote for two scans, as I think we'll soon decide 2n doesn't cut it
anyway. One of the issue
Jaime Casanova írta:
> 2010/1/15 Boszormenyi Zoltan :
>
>> Jaime Casanova írta:
>>
>>> 2010/1/13 Boszormenyi Zoltan :
>>>
>>>
> Your smaller patch is attached, with the above strangeness. :-)
>
>
>
>
> ok, the patch is more simpler than before and seems to
Boszormenyi Zoltan escribió:
> May I change the interface of XactLockTableWait()
> and MultiXactIdWait()? Not the return value, only the number
> of parameters. E.g. with the relation name, like in the attached
> patch. This solves the problem of bad error messages...
> What do you think?
We alre
See:
http://monetdb.cwi.nl/SQL/Benchmark/TPCH/
If the result is correct, then the problem queries should be added to
the regression test suite.
If the result is not correct, then perhaps they could get assistance on
proper configuration of PostgreSQL and rerun the tests.
--
Sent via pgsql-hacke
Dann Corbit wrote:
See:
http://monetdb.cwi.nl/SQL/Benchmark/TPCH/
If the result is correct, then the problem queries should be added to
the regression test suite.
If the result is not correct, then perhaps they could get assistance on
proper configuration of PostgreSQL and rerun the tests.
this
Jeff Davis writes:
> That being said, I don't have much of an opinion, so if you see a
> problem, then we can forget it. After all, we would need some kind of a
> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
> that defeats a lot of the purpose.
Yeah, requiring a prefix wo
On Tue, Jan 19, 2010 at 21:44, Tom Lane wrote:
> Jeff Davis writes:
>> That being said, I don't have much of an opinion, so if you see a
>> problem, then we can forget it. After all, we would need some kind of a
>> prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
>> that defe
The previous discussion started from the idea that only DESCRIBE,
SHOW DATABASES/TABLES, and USE were worth worrying about. If we
were to agree that we'd go that far and no farther, the potential
conflict with SQL syntax would be pretty limited. I have little
enough experience with mysql to not
Hi,
Greg Smith wrote:
> Takahiro Itagaki wrote:
>> The conclusion is splitting existing projects into some 'modules',
>> and getting the modules one by one into core. Voted features are here:
>> http://wiki.postgresql.org/wiki/ClusterFeatures
That's certainly been one of the outcomes, however, th
Tom Lane wrote:
> Jeff Davis writes:
> > That being said, I don't have much of an opinion, so if you see a
> > problem, then we can forget it. After all, we would need some kind of a
> > prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
> > that defeats a lot of the purpose.
>
Tom Lane wrote:
Jeff Davis writes:
That being said, I don't have much of an opinion, so if you see a
problem, then we can forget it. After all, we would need some kind of a
prefix anyway to avoid conflicting with actual SQL... maybe "\m"? And
that defeats a lot of the purpose.
Yeah, requiring
David Christensen wrote:
+ if (MYSQL_HELP_CHECK("use"))
+ {
+ MYSQL_HELP_OUTPUT("\\c database");
+ }
[snip]
+ else if (MYSQL_HELP_CHECK("load data infile"))
+
On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
Tom Lane wrote:
Jeff Davis writes:
That being said, I don't have much of an opinion, so if you see a
problem, then we can forget it. After all, we would need some kind
of a
prefix anyway to avoid conflicting with actual SQL... maybe
On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote:
David Christensen wrote:
+ if (MYSQL_HELP_CHECK("use"))
+ {
+ MYSQL_HELP_OUTPUT("\\c database");
+ }
[snip]
+ else if (M
On Jan 19, 2010, at 12:58 PM, Stefan Kaltenbrunner wrote:
> well providing a hint that one should use different command will only lead to
> the path "uhm why not make it work as well"
I don't think so. People know it's a different database. They'd be thrilled
just to get the hint. I think it's
On Tue, Jan 19, 2010 at 3:13 PM, Tom Lane wrote:
>> It seems to me that it might be
>> sensible to do it this way:
>
>> 1. Do a locale-aware scan of the input string and count the number of
>> characters we need to escape (num_to_escape).
>> 2. If num_to_escape is 0, fast path: allocate len+3 byte
Hi,
Jan Urbański wrote:
> sorry to butt in to the conversation, but I have spent some time
> wrapping/refining the concepts in dtester, and the results are here:
>
> http://git.wulczer.org/?p=twisted-psql.git;a=summary
That seems to cover the concurrent psql part of dtester. But I don't see
how
David Christensen wrote:
Quite apart from any considerations covered by other people, these
two at least could be positively misleading ... the psql commands are
not exact equivalents of the MySQL commands, AIUI.
The \copy could definitely be considered a stretch; I know \c supports
more
David Christensen writes:
> On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
>> well those are the most common ones I guess for the current version
>> of the mysql commandline client - but what about future versions or
>> the fact that we only have partial replacements for some of thos
Robert Haas writes:
> I'd like to proceed by committing an initial patch which changes the
> "Escaping Strings for Inclusion in SQL Commands" to use a
> with one per function (as we do in
> surrounding functions) and consolidates it with the following section,
> "Escaping Binary Strings for Inc
David Christensen writes:
> On Jan 19, 2010, at 3:12 PM, Andrew Dunstan wrote:
>> Quite apart from any considerations covered by other people, these
>> two at least could be positively misleading ... the psql commands
>> are not exact equivalents of the MySQL commands, AIUI.
> The \copy could
On 1/19/2010 8:43 AM, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
Or compiler switches could be set to disable all such warnings
globally. Warning 4514 is specific to inline functions; so
maybe it would be alright to keep it turned off glob
On Tue, 2010-01-19 at 11:25 -0800, Jeff Davis wrote:
> I like that idea. There may be a lot of MySQL people that want to use
> the next postgresql release, and this would make it easier.
I disagree. If they want to use PostgreSQL, they should learn our
syntax. How can you make sure that this wil
On Jan 19, 2010, at 3:39 PM, Tom Lane wrote:
David Christensen writes:
On Jan 19, 2010, at 2:58 PM, Stefan Kaltenbrunner wrote:
well those are the most common ones I guess for the current version
of the mysql commandline client - but what about future versions or
the fact that we only have p
On Jan 19, 2010, at 3:57 PM, Devrim GÜNDÜZ wrote:
On Tue, 2010-01-19 at 11:25 -0800, Jeff Davis wrote:
I like that idea. There may be a lot of MySQL people that want to use
the next postgresql release, and this would make it easier.
I disagree. If they want to use PostgreSQL, they should le
I've been having a look at this, one master + one replica and also one
master + 2 replicas. I gotta say this is a nice piece of functionality
(particularly the multiple replicas).
I've been using the wiki page
(http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and
I notice th
On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
> I thought Magnus had a really good point: covering these four cases will
> probably be enough to teach newbies to look at psql's backslash
> commands. And once they absorb that, we're over a big hump.
+1
On Jan 19, 2010, at 1:57 PM, Devrim GÜNDÜZ w
On Tue, Jan 19, 2010 at 5:14 PM, David E. Wheeler wrote:
> Why would they want more? It's not MySQL, and they know that. If we give them
> some very minor helpful hints for the most common things they try to do, it
> would be a huge benefit to them. I know I've badly wanted the opposite when
>
Hackers,
So, here's a must-fix item for SR for release: we need adequate docs.
I'm happy to write these but *I* need to understand the answers first.
The current docs and wiki page do not explain:
* How (technically) the slave listens for LSNs
* Does the walreceiver need the archive (via archive
On Tue, Jan 19, 2010 at 3:14 PM, David E. Wheeler wrote:
> On Jan 19, 2010, at 1:39 PM, Tom Lane wrote:
>
>> I thought Magnus had a really good point: covering these four cases will
>> probably be enough to teach newbies to look at psql's backslash
>> commands. And once they absorb that, we're ov
On Tue, 2010-01-19 at 21:55 +0100, Markus Wanner wrote:
> Hi,
> So, that's what I'd recommend the Mammoth developers to do as well:
> cherry-picking, sort of. Maybe that fulfills one or the other item on
> our wish-list (in one way or another)...
>
I doubt we are going to spend the time to do th
Mark Kirkwood writes:
> I've been using the wiki page
> (http://wiki.postgresql.org/wiki/Streaming_Replication) as a guide, and I
> notice that it recommends the master (and replicas) have a non-trivial
> archive_command even after the backup step is completed. ISTM that after the
> backup the mas
Robert Haas writes:
> Although the deadline for patches for 8.5 has supposedly already passed
I guess it already got more review than some of the commit fest items
already…
Regards,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Wed, 2010-01-20 at 11:30 +1300, Josh Berkus wrote:
>
> Also, given that recovery.conf has become a key part of our
> replication, shouldn't we supply a recovery.example file which people
> can rename and edit? Happy to write this too.
We ship it already:
src/backend/access/transam/recovery.
Boszormenyi Zoltan writes:
> [ 5-pg85-locktimeout-14-ctxdiff.patch ]
I took a quick look at this. I am not qualified to review the Win32
implementation of PGSemaphoreTimedLock, but I am afraid that both of
the other ones are nonstarters on portability grounds. sem_timedwait()
and semtimedop() d
On Wed, 2009-12-09 at 11:43 +0100, Joachim Wieland wrote:
> Examples:
>
> Backend 1:Backend 2:
>
> transaction starts
> NOTIFY foo;
> commit starts
> transaction starts
> LISTEN foo;
> co
On Tue, Jan 19, 2010 at 6:40 PM, Tom Lane wrote:
> A larger question, which I think has been raised before but I have not
> seen a satisfactory answer for, is whether the system will behave sanely
> at all with this type of patch in place. I don't really think that a
> single lock timeout applica
1 - 100 of 139 matches
Mail list logo
