On Tue, Jan 13, 2009 at 10:05:45AM -0300, Alvaro Herrera wrote:
> pgace.h: you have a bunch of "static inline" functions in here. As far
> as I know this doesn't work in compilers other than GCC :-( See
> pg_list.h (list_head) for an example. I think we can tolerate this for
> the three function
I updated patch set of SE-PostgreSQL and related stuff (r1408).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1408.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-utils-8.4devel-3-r1408.patch
[3/5]
http://sepgsql.googlecode.com/files/sepostgresql-polic
Thanks for picking this up, despite my report was so vague.
Simon Riggs wrote:
Best way seems to be to do (almost) the same thing as ExtendSubtrans()
during recovery, so we zero out pages at the point that recovering
transactions get written to pg_subtrans.
Yep.
Do we have the same bug with E
> However, since there's no standard strftime escape for epoch,
> Robert's proposal to rip out the functionality would break any existing
> code that still depends on this formatting option. I can't say that
> there is any, but by the same token he can't say there isn't.
Absolutely - so the quest
Pg_readahead is a tool to prefetch data pages before redoing, based on
the contents of archive/active WAL segment. For 8.3 and 8.4 without
sync.rep, this works together with restore_command. Pg_readahead
analyze WAL segment, schedule and issue posix_fadvise() to prefetch
data pages quickly befo
Forgot to mention, there is an easy fix:
~]# LDFLAGS="-lnsl" ./configure --enable-thread-safety
But I assume that only works if I use gethostbyname_r(), right?
No, works for gethostbyname as well. They are all in libnsl.
But we do check for that in thread_test.c.
The problem with
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
> Stephen Frost wrote:
>> Yes, logrotate will happily call external applications. Maybe I'm
>> missing something, but obviously if PG can't be configured with a fixed
>> filename, pg_rotate_logfile() doesn't help the situation.
>
> I should th
Tom Lane wrote:
> BTW, another corner case that I'm not sure gets handled right is
> that the join columns in JOIN USING or NATURAL JOIN need to be marked
> as requiring ACL_SELECT. (Or so I'd expect anyway; I didn't run through
> the SQL spec looking for chapter and verse on that.) I forget whet
Andrew Chernow wrote:
> Andrew Chernow wrote:
> > Bruce Momjian wrote:
> >> I supposed Solaris 2.5.1 (release 1996) is just too old to add
> >> threading, and this code has been unchanged for years.
> >>
> >
> > Yeah, its old. Unfortunately for us, we still have to support it.
> >
> > To set the
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > I supposed Solaris 2.5.1 (release 1996) is just too old to add
> > threading, and this code has been unchanged for years.
> >
>
> Yeah, its old. Unfortunately for us, we still have to support it.
>
> To set the record straight, the issue is not t
D'Arcy J.M. Cain wrote:
> On Mon, 12 Jan 2009 12:19:51 -0500 (EST)
> Bruce Momjian wrote:
> > Yep, that is my analysis as well. If you want a pretty ReST-like
> > output, that can be added later.
>
> Not if you use "border 3" for full ReST. I see nothing but pushback
> later if you try to make
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> >> You missed updating the sgml docs, and personally I'd be inclined to
> >> list -l before the individual --lc switches; otherwise it looks fine.
> > Thanks, committed that way. I noticed that --lc-ctype and --lc-collate
> > were fo
Andrew Dunstan writes:
> I'm not sure what postgres does if the filename contains %% as the only
> escape, although that's would be a fairly ugly hack.
Yes, any %-escape is enough to disable the addition of the timestamp.
Looking back at the archives, I believe the real reason it's like this
is
Koichi Suzuki wrote:
> Hi,
>
> I have no intention to make pglesslog to conflict to PostgreSQL
> license. Any advice is welcome to make pglesslog available without
> any license concern.
I certainly have no concerns.
> I've a question and ideas.
>
> Bruce's modification directly points to my
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> It seems to me you didn't add "success cases" for JOINs.
> The previous patch tries to check privilege for each columns within
> JOIN'ed tables unexpectedly, so the test case always fails.
Right, I realized that when I went back and looked at
Stephen Frost wrote:
Surely a good log rotator allows a custom rotation action (in this case,
connecting to postgres and calling 'select pg_rotate_logfile()' )
Yes, logrotate will happily call external applications. Maybe I'm
missing something, but obviously if PG can't be configured w
Stephen Frost wrote:
> Tom, er al,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I'm thinking make_var is not the place to do this. The places that are
>> supposed to be taking care of permissions are the ones that do this:
>>
>> /* Require read access --- see comments in setTargetTa
Alvaro Herrera wrote:
KaiGai Kohei wrote:
I updated patch set of SE-PostgreSQL and related stuff (r1403).
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1403.patch
Random observations:
Thanks for your comment!
heapam.c: you've got a bunch of elog(ERROR) calls
Andrew,
* Andrew Dunstan (and...@dunslane.net) wrote:
> Then Debian is (surprise!) not doing the smartest thing.
As Gregory pointed out, Debian is doing it for some very good reasons,
and is doing it the best it can. Also, I have a huge amount of respect
for Martin Pitt (the Debian maintainer),
"Koichi Suzuki" wrote:
> > This patc also include additional patch for posix_fadvise to skip
> > prefetch of pages which does not exist.
I reviewed your patch and found items to be fixed and improved.
- You should not claim your copyrights.
There are your copyright claims in two files newly ad
On Tue, Jan 13, 2009 at 4:58 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> I have perfectly good log rotation utility that exists on my OS. (yes I
>> am aware of the possibility of losing a log entry when using logrotate).
>
> You might think you do, but it won't work with PG; external rotat
Andrew Dunstan writes:
> Then Debian is (surprise!) not doing the smartest thing. Not using the logging
> collector means you miss several possible advantages, including CSV logs and
> protection against multiplexed log lines.
Well it's not the smartest thing by your set of priorities. Debian's
Alvaro Herrera writes:
> This uses a new parse node.
You need at least equalfuncs.c support for that, and outfuncs would be
advisable.
> One possible disadvantage is that a command
> like this works, but does nothing:
> alvherre=# alter table foo set (test.foo = 1);
Uh, why doesn't it throw an
On Tue, 13 Jan 2009 12:30:09 -0300 Alvaro Herrera wrote:
> The other cases were already handled, so Andreas' initial patch was
> enough -- applied.
Thank you.
Bye
--
Andreas 'ads' Scherbaum
German PostgreSQL User Group
European PostgreSQL User Group - Board of
Attached is a patch that adds a namespace capability to reloptions. It
works this way:
alter table foo set (namespace.option = value)
Currently the only namespace that does anything is "toast". What it
does is store the option in the toast table pg_class.reloptions.
It works fine, i.e. I can
Stephen Frost wrote:
Joshua,
* Joshua D. Drake (j...@commandprompt.com) wrote:
When I set it up, it automatically appended the time so I got:
postgresql.log.1231878270
That seems a bit, well wrong. If I say I want postgresql.log I should
get postgresql.log.
Or am I completely cranked?
While regress/GNUmakefile appears to make an effort to run the regressions
tests with or without locale depending on the users choice, .e.g.,
# locale
NOLOCALE =
ifdef NO_LOCALE
NOLOCALE += --no-locale
endif
the pg_regress.c implementation spoils that completely by unconditionally
unsetting all l
* Joshua D. Drake (j...@commandprompt.com) wrote:
> On Tue, 2009-01-13 at 16:58 -0500, Tom Lane wrote:
> > You might think you do, but it won't work with PG; external rotators
> > only work with programs that respond to SIGHUP by re-opening their log
> > files.
>
> copytruncate resolves this issue
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> "Joshua D. Drake" writes:
> > I have perfectly good log rotation utility that exists on my OS. (yes I
> > am aware of the possibility of losing a log entry when using logrotate).
>
> You might think you do, but it won't work with PG; external rotators
> on
Joshua,
* Joshua D. Drake (j...@commandprompt.com) wrote:
> When I set it up, it automatically appended the time so I got:
>
> postgresql.log.1231878270
>
> That seems a bit, well wrong. If I say I want postgresql.log I should
> get postgresql.log.
>
> Or am I completely cranked?
No. I agree
On Tue, 2009-01-13 at 16:58 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > I have perfectly good log rotation utility that exists on my OS. (yes I
> > am aware of the possibility of losing a log entry when using logrotate).
>
> You might think you do, but it won't work with PG; external r
"Joshua D. Drake" writes:
> I have perfectly good log rotation utility that exists on my OS. (yes I
> am aware of the possibility of losing a log entry when using logrotate).
You might think you do, but it won't work with PG; external rotators
only work with programs that respond to SIGHUP by re-
On Tue, 2009-01-13 at 16:20 -0500, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > When I set it up, it automatically appended the time so I got:
> > postgresql.log.1231878270
> > That seems a bit, well wrong. If I say I want postgresql.log I should
> > get postgresql.log.
>
> You'd probably reco
Robert Haas wrote:
> > "Joshua D. Drake" writes:
> >> When I set it up, it automatically appended the time so I got:
> >> postgresql.log.1231878270
> >> That seems a bit, well wrong. If I say I want postgresql.log I should
> >> get postgresql.log.
> >
> > You'd probably reconsider around the tim
On Tue, Jan 13, 2009 at 4:20 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> When I set it up, it automatically appended the time so I got:
>> postgresql.log.1231878270
>> That seems a bit, well wrong. If I say I want postgresql.log I should
>> get postgresql.log.
>
> You'd probably reconsider
"Joshua D. Drake" writes:
> When I set it up, it automatically appended the time so I got:
> postgresql.log.1231878270
> That seems a bit, well wrong. If I say I want postgresql.log I should
> get postgresql.log.
You'd probably reconsider around the time the log file filled your disk.
You really
Hello,
O.k. so I admit I probably should have known this already but I didn't.
Normally I setup logging to use -%a.log. However I had a requirement
today that is having me setup a flat filename... as in postgresql.log.
When I set it up, it automatically appended the time so I got:
postgresql.log
Dear hackers,
during the last three months, I've compiled my thoughts and ideas around
Postgtres-R into a rounded concept covering lots of aspects. It
integrates findings from up-to-date research papers and it's meant to
lighten up the future direction of development for Postgres-R. See
www.postgr
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
> There's still something wrong with the way subtransactions are handled.
> I got:
>
> postgres=# SELECT * FROM foo;
> ERROR: could not access status of transaction 118649
> DETAIL: Could not open file "pg_subtrans/0001": No such fil
On Sat, 2009-01-10 at 09:40 +, Simon Riggs wrote:
> But looking at that, I
> think the 6a patch had a bug there: a subtransaction abort record
> would release locks for the whole top level xact.
Fixed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Suppor
On Tue, 2008-12-30 at 18:31 +0200, Heikki Linnakangas wrote:
> You have to be careful to ignore the flags in read-only transactions
> that started in hot standby mode, even if recovery has since ended and
> we're in normal operation now.
My initial implementation in v6 worked, but had a corner
>>> Gregory Stark wrote:
> "Kevin Grittner" writes:
>> In what way would an application want to treat deadlocks and update
>> conflicts differently? Both result from conflicts with concurrent
>> transactions and can be retried automatically. It seems like an
>> implementation detail with littl
On Sat, 2009-01-03 at 22:34 -0500, Bruce Momjian wrote:
> Now that we are two months into the final commit fest, it is time to
> finalize all the open patches so we can target a February beta.
>
> The two major outstanding patches are:
...
> o Recovery, Replication, Hot Standby: We need a
"Kevin Grittner" writes:
Josh Berkus wrote:
>> we'd break 100,000 existing Java applications if we changed the
> error.
>
> In what way would an application want to treat deadlocks and update
> conflicts differently? Both result from conflicts with concurrent
> transactions and can be
>>> Josh Berkus wrote:
> we'd break 100,000 existing Java applications if we changed the
error.
In what way would an application want to treat deadlocks and update
conflicts differently? Both result from conflicts with concurrent
transactions and can be retried automatically. It seems like a
Deadlocks like this are the only kind of serialization error possible
under "traditional" (non-MVCC) databases. These are much more rare in
MVCC than update conflicts, but that doesn't mean they aren't
serialization failures there, too. I think it is a violation of the
standard for PostgreSQL
>>> Josh Berkus wrote:
> That's not how SELECT FOR UPDATE works. SFU is pessimistic manual
> locking, which is supposed to *wait* for the rows to be exclusively
> available. The deadlock timeout you encountered is the correct
> behaviour, not "serialization failure", which is what happens at
Kevin,
So, wouldn't it be better, if it's actually feasible to detect the
problem situation, to make this another situation where SELECT FOR
UPDATE can cause serialization failures? That would allow
applications to count on getting the rows in the requested order if
the query completes successf
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Oh, I didn't see that. Still, this doesn't test whether the behavior
>> is correct with respect to ADD/DROP COLUMN --- if that were implemented
>> like SELECT * you'd not see any change in the regression result.
> Hrm. If a colum
On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote:
> Normally, GetRunningTransactionData determines the xid of the latest
> running xid by scanning the procarray. If the subxid cache has
> overflowed, it simply gives up. Comment there suggests that it could
> call ReadNewTransactionId
>>> Tom Lane wrote:
> Huh? Deadlocks were not the issue here. What you asked for was a
> failure if someone else had updated the rows you're selecting for
> update.
Logically, these are both forms of serialization failure when doing
SELECT FOR UPDATE in READ COMMITTED mode. One currently dea
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> What I see being tested is SELECT *, which is a different animal
> >> entirely.
>
> > Wouldn't this test cover those?
> > SELECT atest5 FROM atest5; -- fail
>
> Oh, I didn't see that.
"Kevin Grittner" writes:
> Tom Lane wrote:
>> If that's what you want then you run the transaction in serializable
>> mode. The point of doing it in READ COMMITTED mode is that you
>> don't want such a failure.
> Wait a minute -- there is not such guarantee in PostgreSQL when you
> start usin
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> Hmm, I remember I pondered for a long time if it should be COLLATE and
>> CTYPE or LC_COLLATE and LC_CTYPE. I think the rationale in the end was
>> that a) COLLATE/CTYPE looks nicer and b) if we add support for ICU or
>> some other collat
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> What I see being tested is SELECT *, which is a different animal
>> entirely.
> Wouldn't this test cover those?
> SELECT atest5 FROM atest5; -- fail
Oh, I didn't see that. Still, this doesn't test whether the behavior
is correc
>>> Tom Lane wrote:
> "Kevin Grittner" writes:
>> Would it make any sense to roll back and generate a
>> SERIALIZATION_FAILURE?
>
> If that's what you want then you run the transaction in serializable
> mode. The point of doing it in READ COMMITTED mode is that you
> don't want such a failure.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What I see being tested is SELECT *, which is a different animal
> entirely. As required by spec, SELECT * is expanded to a list of
> ordinary variables at parse time and then it's not really a special
> case anymore. A true whole-row variable only occurs
Andrew Chernow wrote:
Bruce Momjian wrote:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
Yeah, its old. Unfortunately for us, we still have to support it.
To set the record straight, the issue is not threads. Threads w
>>> Peter Eisentraut wrote:
> Kevin Grittner wrote:
>> (In Microsoft SQL Server and Sybase ASE we actually had to run our
>> read-only web application at the READ UNCOMMITTED transaction
>> isolation level because so many SELECT queries were rolled back
>> when they deadlocked with the traffic fr
Heikki Linnakangas wrote:
> Peter Eisentraut wrote:
>> I notice in the documentation that the createdb --lc-ctype sets the
>> lc_ctype setting for the database, but the corresponding parameter for
>> CREATE DATABASE is CTYPE, but the global GUC setting is lc_ctype.
>> Should that be more cons
Peter Eisentraut wrote:
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an
Sorry, I didn't attatch the patch file. This is the second try.
2009/1/12 Koichi Suzuki :
> This is V4 patch to improve file read during startup for review.
>
> Basic algorithm is same as V3 but works with Gregory's fadvise patch.
>
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg00026.
Bruce Momjian wrote:
I supposed Solaris 2.5.1 (release 1996) is just too old to add
threading, and this code has been unchanged for years.
Yeah, its old. Unfortunately for us, we still have to support it.
To set the record straight, the issue is not threads. Threads work fine
on 2.5.1. Th
Tom Lane wrote:
> Alvaro Herrera writes:
> > This was fixed on 1.84 of formatting.c for 8.0 (but not backpatched for
> > no apparent reason), which also changed some other stuff in that file.
> > The complete patch is attached.
>
> I dunno why I didn't back-patch that; feel free to do so. Better
Stephen Frost writes:
>> It's possible that we've missed some --- in particular, right at the
>> moment I am not sure that whole-row Vars are handled properly.
> I added specific regression test for whole-row Vars, so I'd be concerned
> if something isn't working there.
What I see being tested i
Stephen Frost writes:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> - The markColumnForSelectPriv() uses walker function internally, because
>> there is no guarantee all the entities within RangeTblEntry->joinaliasvars
>> are Var type node.
> If any of them aren't Vars, then wouldn't it be a
Tom Lane writes:
> Heikki Linnakangas writes:
>> Robert Haas wrote:
>>> (It would be interesting to here how much value people think it has
>>> added, and get suggestions on how to do things better next time.)
>
>> I'm not sure how much round-robin-review has taken load off committers,
>> you
On 13 jan 2009, at 15.20, Gregory Stark wrote:
Magnus Hagander writes:
Now that we have support for mappings, I expect it will be more
common
for a user to authenticate with princ 'A' and then connect using
their
Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
support f
Heikki Linnakangas writes:
> Robert Haas wrote:
>> (It would be interesting to here how much value people think it has
>> added, and get suggestions on how to do things better next time.)
> I'm not sure how much round-robin-review has taken load off committers,
> you have to read and understand
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> The attached patch is proof of the concept.
Thanks!
> It can be applied on the latest CVS HEAD with colprivs_2009011001.diff.gz.
> - It unpatches unnecessary updates at parser/parse_expr.c, parser/parse_node.c
> and parser/parse_relation.c
Magnus Hagander writes:
>> Now that we have support for mappings, I expect it will be more common
>> for a user to authenticate with princ 'A' and then connect using their
>> Unix id 'B' to a PG user 'B'. As such, I'm alright with dropping
>> support for this. Users can always use -U (or equiv)
Heikki Linnakangas wrote:
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would
Tom, er al,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm thinking make_var is not the place to do this. The places that are
> supposed to be taking care of permissions are the ones that do this:
>
> /* Require read access --- see comments in setTargetTable() */
> rte-
2009/1/12 Bruce Momjian :
>
> I supposed Solaris 2.5.1 (release 1996) is just too old to add
> threading, and this code has been unchanged for years.
>
> ---
>
> Andrew Chernow wrote:
>> for anyone interested
>>
>> Solaris
KaiGai Kohei wrote:
> I updated patch set of SE-PostgreSQL and related stuff (r1403).
>
> [1/5]
> http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1403.patch
Random observations:
heapam.c: you've got a bunch of elog(ERROR) calls in there that should
be ereport(ERROR), and sh
Stephen Frost wrote:
> Magnus, et al,
>
> * Magnus Hagander (mag...@hagander.net) wrote:
>> Looking at the open item about the new error message shown when Kerberos
>> is compiled in, and not used:
>> assword:
>> FATAL: password authentication failed for user "mha"
>> psql: pg_krb5_init: krb5_cc_
On Mon, 12 Jan 2009 12:19:51 -0500 (EST)
Bruce Momjian wrote:
> Yep, that is my analysis as well. If you want a pretty ReST-like
> output, that can be added later.
Not if you use "border 3" for full ReST. I see nothing but pushback
later if you try to make "border 4" give less than "border 3."
Peter Eisentraut wrote:
Which raises yet another question, why CTYPE and COLLATE have to be
hardcoded settings and catalog columns instead of being stored in
datconfig as database-startup-only settings?
Because changing CTYPE or COLLATE in an existing database would render
indexes broken.
P
Robert Haas wrote:
I am just explaining how it works in practice. If the patch is still
being improved, the feeling is that the author wants more time to adjust
things, and with other things on our plate, we are glad to leave their
patch until last.
Well, it's good that you have an explanation
Bruce Momjian wrote:
You missed updating the sgml docs, and personally I'd be inclined to
list -l before the individual --lc switches; otherwise it looks fine.
Thanks, committed that way. I noticed that --lc-ctype and --lc-collate
were forgotten in SGML docs, so I added them too.
Should we hav
Joshua D. Drake wrote:
Does bzr, mecurial or monotone offer the same or better solution? Bzr in
particular is in very wide use and I run into mecurial all the time.
I have found that mercurial is pretty much feature-equivalent to git, at
least until you get to the really wizard-like use cases.
Tom Lane wrote:
> Magnus Hagander writes:
>> On 12 jan 2009, at 17.46, Tom Lane wrote:
>>> However, one of the properties -1 is supposed to have is that any
>>> failure aborts the whole restore; it's not immediately clear how to
>>> preserve that with CREATE DATABASE issued separately.
>
>> Good
Tom Lane wrote:
> Stefan Kaltenbrunner writes:
>> Tom Lane wrote:
>>> David Fetter writes:
1. Remove the messages size limits on -hackers. They serve no useful
purpose, and they interfere with our development process.
>>> Agreed, or at least boost it up a good bit more.
>
>> the ques
Kevin Grittner wrote:
Well, that's a PostgreSQL-specific point of view, although I
understand the point of maintaining that guarantee. (In Microsoft SQL
Server and Sybase ASE we actually had to run our read-only web
application at the READ UNCOMMITTED transaction isolation level
because so many
Tom Lane wrote:
"Kevin Grittner" writes:
Tom Lane wrote:
A re-sort after locking doesn't really make things all nice and
intuitive either.
Would it make any sense to roll back and generate a
SERIALIZATION_FAILURE?
If that's what you want then you run the transaction in serializable
mode.
On Mon, 2009-01-12 at 20:52 -0500, Robert Haas wrote:
> I think the
> base backup should be integrated into the mechanism as well. I want
> to just be able to configure the master and slave for replication,
> fire up the slave, and walk away. Without that, I agree that it's
> likely to be too c
Aidan Van Dyk wrote:
With git, you pull down the complete *history* of whatever branch, tag,
or reference you want to pull down.
You can do a so-called shallow clone, pulling only X most recent
commits, with "git clone --depth=X". There's some limitations on what
you can do with a shallow clo
Hi,
On Sun, Jan 11, 2009 at 7:29 PM, Fujii Masao wrote:
> Hi,
>
> On Thu, Jan 8, 2009 at 2:14 AM, Bruce Momjian wrote:
>> Greg Stark wrote:
>>>
>>> On 7 Jan 2009, at 09:47, Bruce Momjian wrote:
>>>
>>> > Heikki Linnakangas wrote:
>>> >> It's required by the sync replication patch, but has no va
The attached patch is proof of the concept.
It can be applied on the latest CVS HEAD with colprivs_2009011001.diff.gz.
- It unpatches unnecessary updates at parser/parse_expr.c, parser/parse_node.c
and parser/parse_relation.c.
- It adds markColumnForSelectPriv() to mark proper rte->cols_sel for
Hi,
On Mon, Jan 12, 2009 at 1:16 AM, Simon Riggs wrote:
>
> On Sun, 2009-01-11 at 15:11 +0900, Fujii Masao wrote:
>
>> Yes, using semaphores for the communication is also my first approach.
>> The problem of this approach is that walsender cannot wait for both
>> signal from backends and the resp
On Tue, 2009-01-13 at 13:21 +0900, Koichi Suzuki wrote:
> I have no intention to make pglesslog to conflict to PostgreSQL
> license. Any advice is welcome to make pglesslog available without
> any license concern.
I understand, no part of my comments were against you or your work.
> I've a qu
Joshua D. Drake wrote:
On Mon, 2009-01-12 at 13:23 -0500, Robert Haas wrote:
But wasn't I just reading something about having to wipe that repository
and re-import the CVS history to fix various problems?
Not sure; I hope not.
Actually yes we did. There was a bug in git-cvs that we fixed. Its
On Tue, 2009-01-13 at 16:39 +0900, Fujii Masao wrote:
> > May as well leave it in, so people can use it with 8.3.
>
> I'd like this patch to be reviewed and committed for 8.4 even if
> synch-rep
> is postponed to 8.5. Because this is very useful for existing
> warm-standby
> mechanism, and only w
93 matches
Mail list logo
