On 09/28/2015 05:50 AM, YUriy Zhuravlev wrote:
On Thursday 24 September 2015 12:10:07 Ryan Pedela wrote:
Kam Lasater wrote:
I'd suggest: Github Issues, Pivotal Tracker or Redmine (probably in
that order). There are tens to hundreds of other great ones out there,
I'm sure one of them would also
On 09/28/2015 03:40 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Now, running gitlab on community-owned hardware would potentially be an
option, if we find gitlab attractive from a functionality standpoint.
The question I'd have about that is whether it has a real development
community, or is open
On 09/28/2015 04:08 PM, Gavin Flower wrote:
JD
Linux kernel project uses bugzilla (https://bugzilla.kernel.org)
and so does LibreOffice (https://bugs.documentfoundation.org)
I think they are both fairly big projects in for the long haul.
I am not anti-bugzilla, just not all that familiar w
On 09/28/2015 07:18 PM, Stephen Frost wrote:
JD,
debbugs is being used by Debian, and has been since before our first
release (I believe- according to wikipedia, it started in 1994..).
Further, it's now being used by the GNU project for things as important
(well, to some ;) as Emacs.
I thin
On 09/29/2015 07:25 AM, Merlin Moncure wrote:
On Wed, Sep 23, 2015 at 1:18 PM, Kam Lasater wrote:
Hello,
Last night I heard that Postgres had no issue/bug tracker. At first I
thought the guy was trolling me. Seriously, how could this be. Certainly a
mature open source project that is the datab
On 09/29/2015 03:46 PM, Tom Lane wrote:
Alvaro Herrera writes:
Merlin Moncure wrote:
I've read this email about three times now and it's not clear at all
to me what a issue/bug tracker brings to the table.
In my opinion, this thread is about a bug tracker, not a patch tracker.
We already ha
On 09/30/2015 07:44 AM, Merlin Moncure wrote:
I'm not trolling in any way. I'm just challenging you to back up your
blanket assertions with evidence. For example, you're assertion that
mailing lists are insufficient is simply stated and expected to be
taken on faith: *How* is it insufficient a
On 09/30/2015 12:02 AM, Jim Nasby wrote:
If people are hell-bent on every tool being separate then fine, but I
get the distinct impression that everyone is discarding GitLab out of
hand based on completely bogus information.
Right, we need to stop thinking that every task is not interrelated.
On 09/30/2015 10:45 AM, Andrew Dunstan wrote:
Frankly, an insistence on moving to some integrated solution is likely
to result in the adoption of nothing. And your "educating hackers who
don't understand" is more than a little patronizing. What makes you
think your experience in software develop
On 09/30/2015 11:23 AM, Christopher Browne wrote:
It's well and nice to think that an issue tracker resolves all of this,
and, if we
had tiny numbers of issues, we could doubtless construct a repository
indicating so. (Seems to me that the bit of "fan service" for GitHub's
bug tracker fits into
On 09/30/2015 11:33 AM, Andrew Dunstan wrote:
Who exactly is "some guy sitting in a den pushing out code"? And if
that's not a patronizing put down I don't know what is. If you're
referring to me you couldn't be more wrong. I have been a development
director managing a couple of substantial tea
On 09/30/2015 03:28 PM, Josh Berkus wrote:
On 09/30/2015 03:27 PM, Tom Lane wrote:
Josh Berkus writes:
On 09/30/2015 03:10 PM, Tom Lane wrote:
I'd be feeling a lot more positive about this whole thread if any people
had stepped up and said "yes, *I* will put in a lot of grunt-work to make
som
On 09/30/2015 03:49 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
Well, it's hard for anyone to volunteer when we don't know what the
actual volunteer tasks are. I certainly intend to do *something* to
support the bug tracker system, but I don't know yet what that something is.
I volunteer to
On 10/01/2015 07:48 AM, Magnus Hagander wrote:
But using the bugtracker for the discussion itself is usually not a win.
I know you said usually but:
In fact, I'd say in most cases it's counterproductive because it forces
a single tool upon everybody, instead of email which allows each person
On 10/01/2015 08:18 AM, Tom Lane wrote:
Andres Freund writes:
On 2015-10-01 11:07:12 -0400, Tom Lane wrote:
I'm inclined to think that commit messages are not really the right medium
for that at all. Commit messages ought to be primarily text for
consumption by humans. If we had a tracker,
Hello,
I believe it is pretty obvious we are moving in the direction of having
a tracker at this point. The problem is exactly which direction. Stephen
has offered some resources for his ideas and now I am offering some
resources for mine.
I am proposing to setup a redmine instance on a VM.
On 10/02/2015 09:34 AM, Dave Page wrote:
Thoughts? Volunteers?
I swore to myself that I'd stay out of this bikeshed, but... we already have a
Redmine instance.
I know but I didn't want to dogfood in an installation that was
production. I am not going to put up vanilla redmine, I actually p
On 10/02/2015 09:41 AM, Andres Freund wrote:
Hi,
On 2015-10-02 09:28:02 -0700, Joshua D. Drake wrote:
I am proposing to setup a redmine instance on a VM. I am happy to do a lot
of the legwork and should be able to get most of it done before EU. This is
what I think I need from my fellows:
-1
On 10/02/2015 11:36 AM, Robert Haas wrote:
I don't know what this has to do with anything Andres said.
I am sorry if I wasn't clear.
Put succinctly, I am willing to put resources into testing Redmine for
our needs. I will need help to do so because I am not a
committer/hacker. Andres think
On 10/02/2015 12:52 PM, Robert Haas wrote:
OK. My reading of the thread is that the hackers who expressed an
opinion mostly preferred debbugs and the people less involved in the
project wanted something more like GitHub/GitLab. Some people also
argued for and against Bugzilla and JIRA. I didn
On 10/02/2015 01:26 PM, Alvaro Herrera wrote:
However, the contact surface between these two options wasn't really
well polished. Formatting would be lost very frequently: I could write
a nice email, and the customer would get a nice email, but if you looked
at it in the web, it was very ugly.
On 10/06/2015 10:57 AM, Josh Berkus wrote:
On 10/06/2015 10:17 AM, Bruce Momjian wrote:
This is kind of like CVS. We didn't upgrade so Subversion, becuase we
said "we already have a user-friendly interface to CVS, called Marc."
We only moved to git when it could provide us with solid advantag
On 10/06/2015 11:33 AM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
On 10/06/2015 10:57 AM, Josh Berkus wrote:
On 10/06/2015 10:17 AM, Bruce Momjian wrote:
Speaking of which ... this project is rich in skilled users who are
involved in the community but don't code. Bug triage is ex
On 10/06/2015 11:51 AM, Alvaro Herrera wrote:
Joshua D. Drake wrote:
[I have heated water with wood till boiling point, FWIW]
Hahahah I have no doubt.
It should be, "I once heated water with wood and it didn't boil. How can I
change my process so that it will?"
Oh, I a
On 10/13/2015 08:15 AM, Tom Lane wrote:
Andres Freund writes:
On 2015-10-13 16:21:54 +0200, �lvaro Hern�ndez Tortosa wrote:
(50 chars for the commit summary, 72 chars line wrapping)
-1 - imo 50 chars too often makes the commit summary too unspecific,
requiring to read much more.
I agree -
On 10/15/2015 02:16 PM, Josh Berkus wrote:
On 10/15/2015 01:10 PM, Tom Lane wrote:
I think this means that we should get rid of proc->globals and instead
manufacture a new globals dict locally in each call to PLy_exec_function
or PLy_exec_trigger. For SETOF functions it would be necessary to ke
On 10/19/2015 09:47 AM, Jeff Janes wrote:
On Mon, Oct 19, 2015 at 9:37 AM, Bruce Momjian mailto:br...@momjian.us>> wrote:
Sorry, I don't know how I managed to screw this up so much. pg_restore,
not pg_upgrade. I've never looked into pg_restore much until recently,
so my fingers just autocom
On 10/13/2015 11:41 AM, Bruce Momjian wrote:
FYI, I think we already have two limits for the first line summary of
commit messages. The limits are 64 for commit message subjects and 50
characters for gitweb summary pages --- anything longer is truncated.
My commit template shows me the limits
Hello,
The fact that pg_basebackup doesn't use replicaiton slots, is that a
technical limitation or just a, "we need a patch"?
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended"
On 10/26/2015 08:14 PM, Michael Paquier wrote:
On Tue, Oct 27, 2015 at 7:18 AM, José Luis Tallón wrote:
Given the rest of the thread any possibility whatsoever that it'd be
backpatched into 9.5 before release?
Guess it'd be a very welcome addition
This will be available in 9.6. 9.
On 11/04/2015 12:31 PM, Merlin Moncure wrote:
My issue isn't long statements, but broken client, that is broken in wrong
state - connect is still active, but no any statement will coming.
Right, 'Idle in transaction'. Agree that a setting directed purely at
that problem could set a much lower
On 11/04/2015 01:11 PM, Pavel Stehule wrote:
I am sorry, but I have a different experience from GoodData. The few
hours autovacuum is usual. So probably, there should be exception for
autovacuum, dump, ..
But autovacuum and dump are not idle in transaction or am I missing
something?
JD
--
On 11/04/2015 01:55 PM, Stephen Frost wrote:
* Joe Conway (m...@joeconway.com) wrote:
On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
I agree with Pavel. Having a transaction timeout just does not make any
sense. I can see absolutely no use for it. An idle-in-transaction
timeout, on the other
On 11/04/2015 02:15 PM, Stephen Frost wrote:
Yeah but anything holding a lock that long can be terminated via
statement_timeout can it not?
Well, no? statement_timeout is per-statement, while transaction_timeout
is, well, per transaction. If there's a process which is going and has
an open t
On 11/04/2015 02:53 PM, Stephen Frost wrote:
This implies that a statement used takes a long time. It may not. The
lock is held at the transaction level not the statement level, which is
why a transaction level timeout is actually more useful than a statement
level timeout.
What I'm most intere
Hello,
The call for papers for PgNext (the old PgWest/PgEast) is now open:
January 19th: Talk submission opens
April 15th: Talk submission closes
April 30th: Speaker notification
Submit: https://www.postgresqlconference.org/talk_types
Sincerely,
JD
--
Command Prompt, Inc. - http://www.comma
Hello,
It has been brought to my attention a few times over the last year that
I have been over the top in my presentation of myself and have in fact
alienated and offended many of the community. To be honest I am unaware
of everything I have done but I do take the opinion of those who have
Hey,
Just a reminder that the CFP for PgNext in Denver is still open. Let's
get those talks in folks!
https://www.postgresqlconference.org/
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Service
On 05/27/2013 04:58 PM, Craig Ringer wrote:
On 05/28/2013 12:41 AM, Simon Riggs wrote:
I'm happy with that.
I was also thinking about collecting changes not related just to disk
format, if any exist.
Any wire protocol or syntax changes?
I can't seem to find a "things we want to do in wire p
ion numbers:
Client: I have X problem with PostgreSQL
CMD: What version?
Client: 9
CMD: Which version of 9?
Client: 9.0.2
CMD: You should be running 10.0.5 or at least 9.0.13
The conversation does not change.
Further, we are not Firefox. We are not user software. We are developer
software.
On 05/28/2013 08:36 AM, Hannu Krosing wrote:
The conversation does not change.
Further, we are not Firefox. We are not user software. We are
developer software.
At least some of the real-world problems with PostgreSQL
comes from "We are developer software" mentality.
Yes, We are developer so
tter than reading the actual SQL.
Sincerely,
Joshua D. Drake
--
Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image tha
On 05/28/2013 03:36 PM, Bruce Momjian wrote:
The other option would be to do it on query execute but that doesn't
seem as efficient as it would have to be parsed each time. Although
it would still be better than reading the actual SQL.
Well, you could do SET TRANSACTION READ ONLY, and that wo
On 05/28/2013 04:05 PM, Bruce Momjian wrote:
On Tue, May 28, 2013 at 03:39:10PM -0700, Joshua D. Drake wrote:
On 05/28/2013 03:36 PM, Bruce Momjian wrote:
The other option would be to do it on query execute but that doesn't
seem as efficient as it would have to be parsed each
On 05/28/2013 07:55 PM, Bruce Momjian wrote:
Perhaps just documenting the behavior is all that is needed, but -U is
everywhere and I think that's a good thing.
[ moved to hacker ]
Wow, I never realized other tools used -U for user, instead of -u.
Should I change pg_upgrade to use -U for 9.4?
On 05/30/2013 12:01 AM, Heikki Linnakangas wrote:
We could make it mandatory to specify the unit in the value. Ie. throw
an error on "wal_sender_timeout = 50":
ERROR: unit required for option "wal_sender_timeout"
HINT: Valid units for this parameter are "ms", "s", "min", "h", and "d".
Then y
On 05/30/2013 12:55 AM, Magnus Hagander wrote:
I like this idea with one addition. We should have a default unit for each.
For wal_sender_timeout seconds makes sense, but for checkpoint_timeout
minutes makes sense (for example).
This sounds like a good way to make things even more confusing.
On 05/30/2013 01:14 AM, Heikki Linnakangas wrote:
On 30.05.2013 10:52, Joshua D. Drake wrote:
On 05/30/2013 12:01 AM, Heikki Linnakangas wrote:
We could make it mandatory to specify the unit in the value. Ie. throw
an error on "wal_sender_timeout = 50":
ERROR: unit required
On 06/04/2013 01:55 PM, Josh Berkus wrote:
That seems rather like a catch-22 Bruce. If they don't check with the
legal department, it's dangerous, but if they do check, it's dangerous?
Presumably if they checked with the legal department, it's cleared. We
should be wary of stuff contributed
On 06/05/2013 05:37 PM, Robert Haas wrote:
On Wed, Jun 5, 2013 at 3:24 PM, Fujii Masao wrote:
OTOH, if we use max_wal_size as a hard limit, we can avoid such PANIC
error and long down time. Of course, in this case, once max_wal_size is
reached, we cannot complete any query writing WAL until t
On 06/05/2013 05:37 PM, Robert Haas wrote:
- If it looks like we're going to exceed limit #3 before the
checkpoint completes, we start exerting back-pressure on writers by
making them wait every time they write WAL, probably in proportion to
the number of bytes written. We keep ratcheting up t
On 06/05/2013 06:23 PM, Daniel Farina wrote:
On Wed, Jun 5, 2013 at 6:00 PM, Joshua D. Drake wrote:
I didn't see that proposal, link? Because the idea of slowing down
wal-writing sounds insane.
It's not as insane as introducing an archiving gap, PANICing and
crashing, or running
On 6/5/2013 10:07 PM, Daniel Farina wrote:
If I told you there were some of us who would prefer to attenuate the
rate that things get written rather than cancel or delay archiving for
a long period of time, would that explain the framing of the problem?
I understand that based on what you sai
On 6/5/2013 10:54 PM, Peter Geoghegan wrote:
On Wed, Jun 5, 2013 at 10:27 PM, Joshua D. Drake wrote:
I just wonder if we are looking in the right place (outside of some obvious
badness like the PANIC running out of disk space).
So you don't think we should PANIC on running out of disk
On 6/5/2013 11:09 PM, Daniel Farina wrote:
Instead of "running out of disk space PANIC" we should just write to an
emergency location within PGDATA and log very loudly that the SA isn't
paying attention. Perhaps if that area starts to get to an unhappy place we
immediately bounce into read-only
On 6/5/2013 11:25 PM, Harold Giménez wrote:
Instead of "running out of disk space PANIC" we should just write
to an emergency location within PGDATA
This merely buys you some time, but with aggressive and sustained
write throughput you are left on the same spot. Practically speaking
On 6/5/2013 11:31 PM, Peter Geoghegan wrote:
On Wed, Jun 5, 2013 at 11:28 PM, Joshua D. Drake wrote:
I have zero doubt that in your case it is true and desirable. I just don't
know that it is a positive solution to the problem as a whole. Your case is
rather limited to your environment,
On 6/6/2013 1:11 AM, Heikki Linnakangas wrote:
(I'm sure you know this, but:) If you perform a checkpoint as fast and
short as possible, the sudden burst of writes and fsyncs will
overwhelm the I/O subsystem, and slow down queries. That's what we saw
before spread checkpoints: when a checkpo
On 06/06/2013 09:30 PM, Jeff Janes wrote:
Archiving
-
In some ways, this is the simplest case. Really, we just need a way to
know when the available WAL space has become 90% full, and abort
archiving at that stage. Once we stop attempting to archive, we can
cl
h password authentication. It
was because the valuntil on the user had been set till a date in the
past. Now technically if we just removed the word "password" from the
error it would be accurate but it seems it would be better to say,
"FATAL: the user "user" has expired".
On 06/07/2013 11:57 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
I had a customer pulling their hair out today because they couldn't
login to their system. The error was consistently:
2013-06-07 08:42:44 MST postgres 10.1.11.67 27440 FATAL: password
authentication failed
On 06/07/2013 12:31 PM, Tom Lane wrote:
"Joshua D. Drake" writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
Why? That seems rather silly.
The general policy on authentication failure repo
On 06/07/2013 01:41 PM, David Johnston wrote:
"Please check server log for specifics" is not a good message for something
sent to a client that in many normal situation would have no access to said
logs.
I don't agree. The user doesn't need access to the logs. If they get
that error they
On 06/07/2013 12:14 PM, Josh Berkus wrote:
Right now, what we're telling users is "You can have continuous backup
with Postgres, but you'd better hire and expensive consultant to set it
up for you, or use this external tool of dubious provenance which
there's no packages for, or you might accid
On 06/08/2013 07:36 AM, MauMau wrote:
1. If the machine or postgres crashes while archive_command is copying a
WAL file, later archive recovery fails.
This is because cp leaves a file of less than 16MB in archive area, and
postgres refuses to start when it finds such a small archive WAL file.
T
ack with some OBVIOUS not
OBTUSE error.
Obviously this could cause a ton of transactions to roll back but I
think keeping the database consistent and rolling back a transaction in
case of error is exactly what we are supposed to do.
Sincerely,
Joshua D. Drake
- Heikki
--
Sent via p
On 06/07/2013 12:31 PM, Tom Lane wrote:
"Joshua D. Drake" writes:
On 06/07/2013 11:57 AM, Tom Lane wrote:
I think it's intentional that we don't tell the *client* that level of
detail.
Why? That seems rather silly.
The general policy on authentication failure repo
On 06/08/2013 11:27 AM, Andres Freund wrote:
On 2013-06-08 11:15:40 -0700, Joshua D. Drake wrote:
To me, a more pragmatic approach makes sense. Obviously having some kind of
code that checks the space makes sense but I don't know that it needs to be
around any operation other than w
Hello,
In my quest to understand how all the logging etc works with
authentication I came across the area of crypt.c that checks for
valid_until but it seems like it has an extraneous check.
If I am wrong I apologize for the noise but wouldn't mind an explanation.
index f01d904..8d809b2 100
On 06/08/2013 08:47 PM, Stephen Frost wrote:
JD,
* Joshua D. Drake (j...@commandprompt.com) wrote:
In my quest to understand how all the logging etc works with
authentication I came across the area of crypt.c that checks for
valid_until but it seems like it has an extraneous check.
If I am
On 06/09/2013 09:28 AM, Tom Lane wrote:
Even aside from that, the proposed change seems like a bad idea because
it introduces an unnecessary call of GetCurrentTimestamp() in the common
case where there's no valuntil limit. On some platforms that call is
pretty slow.
And that would explain wh
On 06/10/2013 04:42 PM, Josh Berkus wrote:
Actually we describe what archive_command needs to fulfill, and tell them
to use something that accomplishes that. The example with cp is explicitly
given as an example, not a recommendation.
If we offer cp as an example, we *are* recommending it.
On 06/12/2013 08:49 AM, Robert Haas wrote:
Sure, remote archiving is great, and I'm glad you've been working on
it. In general, I think that's a cleaner approach, but there are
still enough people using archive_command that we can't throw them
under the bus.
Correct.
I guess archiving to
On 06/14/2013 10:11 AM, David Fetter wrote:
ok, thanks, I will wait.
Hi Joe,
Do you have some time in the weekend to help me submit the patch?
Thanks,
Liming
Liming,
Is your git skill good enough to create a patch vs. PostgreSQL's git
master? If so, send that and once it's hit the mailin
ERROR: index "foo_idx"
We should probably add the schema.
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
For my dreams of your image th
On 06/14/2013 10:47 AM, Peter Geoghegan wrote:
I think you'll need to better describe what you mean here.
postgres=# create schema foo;
CREATE SCHEMA
postgres=# create schema bar;
CREATE SCHEMA
postgres=# create table foo.foo(id serial);
NOTICE: CREATE TABLE will create implicit sequence "f
On 06/14/2013 11:01 AM, Peter Geoghegan wrote:
On Fri, Jun 14, 2013 at 10:54 AM, Joshua D. Drake
wrote:
Now, with the error previously shown, which one_idx needs to be reindexed?
Well, you didn't show an actual error message.
ERROR: index "foo_idx"
Is not an error mes
On 06/14/2013 11:16 AM, Josh Berkus wrote:
On 06/12/2013 02:03 PM, Joshua D. Drake wrote:
What concerns me is we seem to be trying to make this "easy". It isn't
supposed to be easy. This is hard stuff. Smart people built it and it
takes a smart person to run it. When did it bec
On 06/14/2013 06:56 PM, Robert Haas wrote:
On Fri, Jun 14, 2013 at 8:45 PM, Andres Freund wrote:
On 2013-06-14 17:35:02 -0700, Josh Berkus wrote:
No. I think as long as we only have pglz and one new algorithm (even if
that is lz4 instead of the current snappy) we should just always use the
On 06/14/2013 11:18 PM, Craig Ringer wrote:
On 06/15/2013 02:08 PM, Brendan Jurd wrote:
On 15 June 2013 14:43, Craig Ringer wrote:
The #1 question I see on Stack Overflow has to be confusion about
pg_hba.conf, mostly from people who have no idea it exists, don't understand
how to configure i
On 06/14/2013 11:44 PM, Brendan Jurd wrote:
If they see something called 'pg_hba.conf', they may very reasonably
assume that it is some internal/advanced stuff that they don't need to
worry about just yet, because what the heck is a 'pg_hba'? The 'pg'
Only the uneducated. Look, I am not tryi
Hello,
Instead of pushing extra info to the logs I decided that we could
without giving away extra details per policy. I wrote the error message
in a way that tells the most obvious problems, without admitting to any
of them. Please see attached:
diff --git a/src/backend/libpq/auth.c b/src/
On 06/19/2013 08:24 AM, Peter Eisentraut wrote:
I think it's intentional that we don't tell the *client* that level of
detail. I could see emitting a log message about it, but it's not clear
whether that will help an unsophisticated user.
Usually, when I log in somewhere and the password is
On 06/18/2013 02:25 AM, Markus Wanner wrote:
On 06/16/2013 06:02 PM, Joshua D. Drake wrote:
Instead of pushing extra info to the logs I decided that we could
without giving away extra details per policy. I wrote the error message
in a way that tells the most obvious problems, without
On 06/19/2013 01:18 PM, Markus Wanner wrote:
"Authentication failed or password has expired for user \"%s\""
Authentication failed covers any combination of a username/password
being wrong and obviously password expired covers the other.
Works for me. Considering the password to be the thing
On 06/21/2013 09:48 AM, Jim Nasby wrote:
We've got some recently decommissioned servers and Enova is willing to
donate 2 of them to the community.
There's nothing terribly spectacular about the servers except for
memory. We have one 512G server available and the other would be either
192G or 9
On 06/24/2013 08:40 AM, Maciej Gajewski wrote:
Maybe this policy should be mentioned on the Wiki, so newbies like
myself (who wouldn't even dare reviewing patches submitted be seasoned
hackers) are not surprised by seeing own name on a shame wall?
It is mentioned. Of course now I can't find it
On 06/24/2013 10:10 AM, Josh Berkus wrote:
On 06/24/2013 10:02 AM, Dimitri Fontaine wrote:
Josh Berkus writes:
patch. The vast majority chose not to respond to my email to them at
all. When private email fails, the next step is public email.
The only problem I have here is that I don't r
On 06/24/2013 10:22 AM, Josh Berkus wrote:
Mind you, we wouldn't be able to reward a few reviewers, because they
live in countries to which it's impossible to ship from abroad.
I have previously proposed that all of the reviewers of a given
PostgreSQL release be honored in the release notes as
On 06/24/2013 10:48 AM, Claudio Freire wrote:
Reviewer recognition should be on the same level as the submitter.
The problem with that is that that HUGELY depends on the patch and the
review. There are patches where reviewers do a good percentage of the
work and others where they mostly tell
On 06/24/2013 10:59 AM, Andres Freund wrote:
On 2013-06-24 10:50:42 -0700, Josh Berkus wrote:
The problem with that is that that HUGELY depends on the patch and the
review. There are patches where reviewers do a good percentage of the
work and others where they mostly tell that "compiles & r
On 06/24/2013 04:59 PM, Bruce Momjian wrote:
On Thu, Jun 20, 2013 at 12:45:48PM +0800, Craig Ringer wrote:
I see value in making the codebase compileable with g++... and down the
track I can see being able to use basic class features as quite useful
given Pg's fairly OO internal design. Inline
On 06/24/2013 05:37 PM, Bruce Momjian wrote:
On Mon, Jun 24, 2013 at 09:21:26PM -0300, Claudio Freire wrote:
On Mon, Jun 24, 2013 at 9:19 PM, Joshua D. Drake wrote:
I think the big question is whether you can _control_ what C++ features
are used, or whether you are perpetually instructing
On 06/24/2013 09:16 PM, Tom Lane wrote:
Bruce Momjian writes:
Right. I don't think there are any C features we want to avoid; are
there any?
We're avoiding C99-and-later features that are not in C89, such as //
for comments, as well as more useful things. It might be time to
reconsider whe
On 06/25/2013 10:17 AM, Josh Berkus wrote:
Hackers,
I'd like to take a straw poll here on how we should acknowledge
reviewers. Please answer the below with your thoughts, either on-list
or via private email.
How should reviewers get credited in the release notes?
a) not at all
b) in a singl
On 06/25/2013 11:26 AM, Andres Freund wrote:
On 2013-06-25 11:04:38 -0700, Joshua D. Drake wrote:
a) not at all
b) in a single block titled "Reviewers for this version" at the bottom.
c) on the patch they reviewed, for each patch
C. The idea that reviewers are somehow less than
On 06/29/2013 08:35 AM, Bruce Momjian wrote:
On Sat, Jun 29, 2013 at 11:33:54AM -0400, Andrew Dunstan wrote:
Nobody seemed interested. But I do think it's a good idea still.
Well, if no one replied, and you thought it was a good idea, then it was
a good idea. ;-)
I think it is a good id
.
Whatever solution we decide, we should not push this responsibility off
on pgadmin as pgadmin is not part of PostgreSQL but a third party tool.
The "standard" postgresql client is psql (for good or bad) and we should
support psql fully on all platforms.
Sincerely,
Josh
On 07/04/2013 06:05 AM, Andres Freund wrote:
Presumably the smaller segsize is better because we don't
completely stall the system by submitting up to 1GB of io at once. So,
if we were to do it in 32MB chunks and then do a final fsync()
afterwards we might get most of the benefits.
Yes, I try
On 7/5/2013 1:01 PM, Josh Berkus wrote:
If you are issuing a fresh connection for each sub-100ms query, you're
doing it wrong anyway ...
It's fairly common with certain kinds of apps, including Rails and PHP.
This is one of the reasons why we've discussed having a kind of
stripped-down version
201 - 300 of 2966 matches
Mail list logo
