Tom Lane wrote:
> Michael Haggerty writes:
>> No, it is also possible to use "cvs tag -b REL8_4_STABLE filename". In
>> this case the file as it appears on the current branch is added to the
>> specified branch, but CVS records no commit, author, or timestamp.
>
> So, if we're prepared to assert
On 06/09/10 17:14, Simon Riggs wrote:
On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
The standby is sending a stream of messages to the master with current
LSN positions at the time the message is sent. Given a synchronous
transaction, the master would wait until the feedback stre
I haven't had a chance to do a great deal of work on this project, but
I'm hoping to get back to it at some point and, in the meantime,
thought that it might be useful to circulate a few thoughts I've had
so far.
1. As common architecture for both features, I think that it might
make sense to repl
On Sep 5, 2010, at 3:09 AM, Dean Rasheed wrote:
> On 15 August 2010 18:38, Dean Rasheed wrote:
>> Here is a WIP patch implementing triggers on VIEWs ...
>>
>> There are still a number of things left todo:
>> - extend ALTER VIEW with enable/disable trigger commands
>> - much more testing
>>
2010/7/22 Teodor Sigaev :
> http://www.sigaev.ru/misc/builtin_knngist_core-0.8.gz
> http://www.sigaev.ru/misc/builtin_knngist_itself-0.8.gz
> http://www.sigaev.ru/misc/builtin_knngist_proc-0.8.gz
> http://www.sigaev.ru/misc/builtin_knngist_contrib_pg_trgm-0.8.gz
> http://www.sigaev.ru/misc/builtin_
On Mon, Sep 6, 2010 at 5:02 PM, Simon Riggs wrote:
> Then I respectfully suggest that you're releasing locks too early.
>
> Your proposal would allow a 2nd user to see the results of the 1st
> user's transaction before the 1st user knew about whether it had
> committed or not.
Marking the transac
On Mon, Sep 6, 2010 at 10:14 AM, Simon Riggs wrote:
>> That doesn't really answer the question: *when* does standby send back
>> the acknowledgment?
>
> I think you should explain when you think this happens in your proposal.
>
> Are you saying that you think the standby should send back one messa
On 2010-08-31 12:07 AM +0300, I wrote:
The patch needs a bit more comments and some cleaning up ..
Here's a cleaned up version with a bit more comments.
This patch still silently breaks pg_parse_and_rewrite(). We only use it
in our source code for SQL-language functions, so I think we shoul
On Mon, 2010-09-06 at 16:11 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2010-09-06 at 21:45 +0200, Boszormenyi Zoltan wrote:
> >> The locks held by a transaction are released after
> >> RecordTransactionCommit(), and waiting for the sync ack
> >> happens in this function. Now what hap
On Mon, 2010-09-06 at 23:07 +0100, Greg Stark wrote:
> On Mon, Sep 6, 2010 at 10:02 PM, Simon Riggs wrote:
> > Then I respectfully suggest that you're releasing locks too early.
> >
> > Your proposal would allow a 2nd user to see the results of the 1st
> > user's transaction before the 1st user kn
On Mon, Sep 6, 2010 at 10:07 AM, Greg Stark wrote:
> I think that description pretty much settles the question in my mind.
> The implementation choice of scanning the WAL to find all the changed
> blocks is more relevant to the use cases where incremental backups are
> useful. If you still have to
On Mon, Sep 6, 2010 at 4:29 PM, David Fetter wrote:
> Oops. Sorry about the noise. I missed the 9.1 part :P
I was wondering what you were trying to figure out... :-)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing li
On Mon, Sep 6, 2010 at 10:02 PM, Simon Riggs wrote:
> Then I respectfully suggest that you're releasing locks too early.
>
> Your proposal would allow a 2nd user to see the results of the 1st
> user's transaction before the 1st user knew about whether it had
> committed or not.
>
> I know why you
On Fri, Sep 3, 2010 at 4:40 PM, John Adams wrote:
> If you guys care about money and time why would you spend the best years of
> your life basically copying commercial products for free?
I don't work for free. :-)
There was a point at which this was just a hobby for me, but as it has
since tur
On Fri, Sep 03, 2010 at 01:40:56PM -0700, John Adams wrote:
> OT:
>
> OFF TOPIC:
> I honestly do not mean any offence, just out of curiosity.
> If you guys care about money and time why would you spend the best
> years of your life basically copying commercial products for free?
> Because for a
Alvaro Herrera writes:
> Another thing that could raise eyebrows is that I chose to remove the
> "missing_ok" argument from get_role_oid_or_public, so it's not a perfect
> mirror of it. None of the current callers need it, but perhaps people
> would like these functions to be consistent.
Well, i
Excerpts from Jim Nasby's message of jue jun 10 17:54:43 -0400 2010:
> test...@workbook=# select has_table_privilege( 'public', 'test', 'SELECT' );
> ERROR: role "public" does not exist
Here's a patch implementing this idea.
I'm not too sure about the wording in the doc changes. If somebody
wan
Markus Wanner writes:
> AFAICT the custom select() implementation we are using for Windows could
> easily be changed to mimic pselect() instead. Thus most reasonably
> up-to-date Linux distributions plus Windows certainly provide a workable
> pselect() syscall. Would it be worth using pselect()
On Mon, 2010-09-06 at 22:32 +0200, Boszormenyi Zoltan wrote:
> (in commit)
> write wal record
> release locks/etcwait for sync ack
>
> In the first case, the contention is obviously increased.
> With this, we are creating more idle time in the server
> instead of letting other transactions do
Simon Riggs írta:
> On Mon, 2010-09-06 at 21:45 +0200, Boszormenyi Zoltan wrote:
>
>> Dimitri Fontaine írta:
>>
>>> Boszormenyi Zoltan writes:
>>>
>>>
Sorry for answering such an old mail, but what is the purpose of
a transaction level synchronous behaviour if async tra
On Mon, Sep 06, 2010 at 01:11:03PM -0700, David Fetter wrote:
> On Mon, Sep 06, 2010 at 08:07:33PM +0100, Dave Page wrote:
> > On Mon, Sep 6, 2010 at 7:41 PM, Peter Eisentraut wrote:
> > > On mån, 2010-09-06 at 19:38 +0100, Dave Page wrote:
> > >> On Mon, Sep 6, 2010 at 6:54 PM, Peter Eisentraut
On Mon, Sep 06, 2010 at 05:41:06AM +0200, Michael Haggerty wrote:
> Tom Lane wrote:
> > Michael Haggerty writes:
> >> CVS does not record when a branch was created or by whom. If a
> >> git commit has to be created for such events, cvs2git attributes
> >> them to a configurable username, which Ma
Simon Riggs writes:
> On Mon, 2010-09-06 at 21:45 +0200, Boszormenyi Zoltan wrote:
>> The locks held by a transaction are released after
>> RecordTransactionCommit(), and waiting for the sync ack
>> happens in this function. Now what happens when a sync
>> transaction hold a lock that an async one
On Mon, Sep 06, 2010 at 08:07:33PM +0100, Dave Page wrote:
> On Mon, Sep 6, 2010 at 7:41 PM, Peter Eisentraut wrote:
> > On mån, 2010-09-06 at 19:38 +0100, Dave Page wrote:
> >> On Mon, Sep 6, 2010 at 6:54 PM, Peter Eisentraut wrote:
> >> > On lör, 2010-09-04 at 18:35 +0100, Dave Page wrote:
> >>
On 09/06/2010 08:46 PM, Tom Lane wrote:
Well, it's not defined in the Single Unix Spec, which is our customary
reference for portability.
FWIW, I bet the self-pipe trick isn't mentioned there, either... any
good precedence that it actually works as expected on all of the target
platforms? Exi
On Mon, 2010-09-06 at 21:45 +0200, Boszormenyi Zoltan wrote:
> Dimitri Fontaine írta:
> > Boszormenyi Zoltan writes:
> >
> >> Sorry for answering such an old mail, but what is the purpose of
> >> a transaction level synchronous behaviour if async transactions
> >> can be held back by a sync tra
Dimitri Fontaine írta:
> Boszormenyi Zoltan writes:
>
>> Sorry for answering such an old mail, but what is the purpose of
>> a transaction level synchronous behaviour if async transactions
>> can be held back by a sync transaction?
>>
>
> I don't understand why it would be the case (sync h
On Mon, Sep 6, 2010 at 7:41 PM, Peter Eisentraut wrote:
> On mån, 2010-09-06 at 19:38 +0100, Dave Page wrote:
>> On Mon, Sep 6, 2010 at 6:54 PM, Peter Eisentraut wrote:
>> > On lör, 2010-09-04 at 18:35 +0100, Dave Page wrote:
>> >> Announcing on Monday doesn't give us any time to build installers
Markus Wanner writes:
> Is pselect() really as unportable as stated in the patch? What platforms
> have problems with pselect()?
Well, it's not defined in the Single Unix Spec, which is our customary
reference for portability. Also, it's alleged that some platforms have
it but in a form that's
On mån, 2010-09-06 at 19:38 +0100, Dave Page wrote:
> On Mon, Sep 6, 2010 at 6:54 PM, Peter Eisentraut wrote:
> > On lör, 2010-09-04 at 18:35 +0100, Dave Page wrote:
> >> Announcing on Monday doesn't give us any time to build installers.
> >
> > When are the installers ready?
>
> They're built no
On Mon, Sep 6, 2010 at 6:54 PM, Peter Eisentraut wrote:
> On lör, 2010-09-04 at 18:35 +0100, Dave Page wrote:
>> Announcing on Monday doesn't give us any time to build installers.
>
> When are the installers ready?
They're built now, and should be on the CDN & website tomorrow.
--
Dave Page
Bl
On Sep 6, 2010, at 12:07 AM, Pavel Stehule wrote:
> The work on PostgreSQL is adventure, and very good experience, very
> good school for me. It's job only for people who like programming, who
> like hacking, it isn't job for people, who go to office on 8 hours.
> Next I use PostgreSQL for my job
Michael Haggerty writes:
> Tom Lane wrote:
>> Actually, no I don't see. That sort of history might be possible in
>> some SCMs, but how is it possible in CVS? The only way to get a file
>> into a back branch is "cvs add" then "cvs commit", and the commit is
>> recorded, even if the file exactly
On lör, 2010-09-04 at 18:35 +0100, Dave Page wrote:
> Announcing on Monday doesn't give us any time to build installers.
When are the installers ready?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
Hi,
On 09/06/2010 06:27 PM, Heikki Linnakangas wrote:
Here's an updated patch, with all the issues reported this far fixed,
except for that naming issue, and Fujii's suggestion to use poll()
instead of select() where available. I've also polished it quite a bit,
improving comments etc. Magnus, c
On 06/09/10 17:18, Tom Lane wrote:
Heikki Linnakangas writes:
I think we have just a terminology issue. What you're describing is
exactly how it works now, if you just s/InitLatch/AcquireLatch.
No, it isn't. What I'm suggesting requires breaking InitLatch into two
operations.
We also need
Tom Lane wrote:
> I wrote:
>> Michael Haggerty writes:
>>> On the contrary, I prefer an obvious indication of "I don't know" to a
>>> value that might appear to be authoritative but is really just a guess.
>>> It could be that one user copied the file verbatim to the branch and a
>>> second user c
2010/9/6 Itagaki Takahiro :
> On Mon, Sep 6, 2010 at 11:24 PM, Tom Lane wrote:
>> So? You'd need to quote the values anyway, in general. If you want
>> something that will be valid SQL you'd better include the functionality
>> of quote_literal() in it.
>>
>> I'm not sure that it's a good idea to
I wrote:
> Michael Haggerty writes:
>> On the contrary, I prefer an obvious indication of "I don't know" to a
>> value that might appear to be authoritative but is really just a guess.
>> It could be that one user copied the file verbatim to the branch and a
>> second user changed the file as part
On Mon, Sep 6, 2010 at 11:24 PM, Tom Lane wrote:
> So? You'd need to quote the values anyway, in general. If you want
> something that will be valid SQL you'd better include the functionality
> of quote_literal() in it.
>
> I'm not sure that it's a good idea to have any type-specific special
> c
Pavel Stehule writes:
> Why I think so this is useful - sometimes people asked some GUC for
> formatting date, boolean and other. If these functions try to use a
> cast to text first, then there is some space for customization via
> custom cast functions.
This is basically nonsense. If you don't
Itagaki Takahiro writes:
> On Mon, Sep 6, 2010 at 10:47 PM, Tom Lane wrote:
>> No, you need to use the I/O functions. Â Not every type is guaranteed to
>> have a cast to text.
> One issue is that Pavel want to generate valid SQL statement using
> %v format. Boolean values are printed as t or f,
Heikki Linnakangas writes:
> On 03/09/10 21:50, Tom Lane wrote:
>> Well, in that case what we need to do is presume that the latch object
>> has a continuing existence but the owner/receiver can come and go.
>> I would suggest that InitLatch needs to initialize the object into a
>> valid but unown
On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
> >
> > The standby is sending a stream of messages to the master with current
> > LSN positions at the time the message is sent. Given a synchronous
> > transaction, the master would wait until the feedback stream reports
> > that the cu
On Sun, Sep 5, 2010 at 4:51 PM, Martijn van Oosterhout
wrote:
> If you're working from a known good version of the database at some
> point, yes you are right you have more interesting options. If you
> don't you want something that will fix it.
Sure, in that case you want to restore from backup
2010/9/6 Itagaki Takahiro :
> On Mon, Sep 6, 2010 at 10:47 PM, Tom Lane wrote:
>> No, you need to use the I/O functions. Not every type is guaranteed to
>> have a cast to text.
>
> One issue is that Pavel want to generate valid SQL statement using
> %v format. Boolean values are printed as t or f
2010/9/6 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/6 Itagaki Takahiro :
>>> Which should we use for such purposes? Consistent behavior is
>>> obviously preferred. Boolean type might be the only type that
>>> is converted to different representation in typoutput or cast-to-test,
>>> but we shoul
On Mon, Sep 6, 2010 at 10:47 PM, Tom Lane wrote:
> No, you need to use the I/O functions. Not every type is guaranteed to
> have a cast to text.
One issue is that Pavel want to generate valid SQL statement using
%v format. Boolean values are printed as t or f, so the unquoted
values are not vali
Magnus Hagander writes:
> On Mon, Sep 6, 2010 at 15:37, Tom Lane wrote:
>> Uh, no, not so. Marc used to use that ID for commits related to
>> pushing new versions. It's been retired, but there's nothing un-real
>> about the commits under that ID. Please pick something else. I thought
>> the s
On Mon, Sep 6, 2010 at 15:37, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Sep 6, 2010 at 06:09, Tom Lane wrote:
>>> If we can set it to a value different from any actual committer name,
>>> that would be a good thing to do.
>
>> I intentionally picked the "pgsql" user because AFAIK that
Pavel Stehule writes:
> 2010/9/6 Itagaki Takahiro :
>> Which should we use for such purposes? Consistent behavior is
>> obviously preferred. Boolean type might be the only type that
>> is converted to different representation in typoutput or cast-to-test,
>> but we should consider to have boolean-
Magnus Hagander writes:
> On Mon, Sep 6, 2010 at 06:09, Tom Lane wrote:
>> If we can set it to a value different from any actual committer name,
>> that would be a good thing to do.
> I intentionally picked the "pgsql" user because AFAIK that's what
> we've been previously using for "commits tha
Hello, David.
We are still using MinGW. Why? How? And other questions are answered
in my post:
http://pgolub.wordpress.com/2008/12/15/building-postgresql-client-library-using-mingw-under-winxp-sp3/
You wrote:
DF> Hello,
DF> At work, I've been tasked with providing some Windows connection
DF>
On 06/09/10 16:03, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
(scratches head..) What's the point of differentiating
received/fsynced/replayed, if the master receives the ack for all of them at
the same time?
It wouldn't the way I understand Simon's proposal.
What's happening is that
Disclaimer : I have understood things in a way that allows me to answer
here, I don't know at all if that's the way it's meant to be understood.
Heikki Linnakangas writes:
> (scratches head..) What's the point of differentiating
> received/fsynced/replayed, if the master receives the ack for all
Boszormenyi Zoltan writes:
> Sorry for answering such an old mail, but what is the purpose of
> a transaction level synchronous behaviour if async transactions
> can be held back by a sync transaction?
I don't understand why it would be the case (sync holding back async
transactions) — it's been
On Sat, Sep 4, 2010 at 00:26, Peter Geoghegan
wrote:
> Hi David
>
> I seem to recall the last time that I built Postgres on windows using
> VC++, there was a whole load of compiler warnings, because MS have
> taken it upon themselves to deprecate various C std lib functions (in
> particular, strin
On Mon, Sep 6, 2010 at 06:09, Tom Lane wrote:
> Michael Haggerty writes:
>> Tom Lane wrote:
>>> I suspect what it's doing is attributing the branch creation to the user
>>> who makes the first commit on the branch for that file. In general I'd
>>> expect that to give a reasonable result --- bett
On Sun, Sep 5, 2010 at 04:55, Robert Haas wrote:
> On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
and the result is that things are looking pretty clean :-)
>>>
>>> Hey, that's great. But I wonder why Magnus got a different result.
>>
>> This is the first time I've posted these incantat
On Sun, Sep 5, 2010 at 10:43, Max Bowsher wrote:
> On 05/09/10 03:55, Robert Haas wrote:
>> On Sat, Sep 4, 2010 at 9:17 AM, Max Bowsher wrote:
Can you post the repo you ended up with somewhere?
>>>
>>> Well, it's a Bazaar repository at the moment :-)
>>>
>>> But, I'll re-run it targetting gi
2010/9/3 John Adams :
> OT:
>
> OFF TOPIC:
>
> I honestly do not mean any offence, just out of curiosity.
>
> If you guys care about money and time why would you spend the best years of
> your life basically copying commercial products for free? Because for a
> person with higher than average IQ fa
61 matches
Mail list logo
