up properly for
submissions that simply added a counter to pg_stat_user_tables indicating
how many times vacuum had aborted on that specific table. If that's enough
info (it was for my case) to cover this case, I can try to dig it out
again and clean it up...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Jan 21, 2014 at 5:18 PM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
> > Isn't CAP_BACKUP pretty much the REPLICATION privilege?
>
> Not unless we change it to allow read-access to all tables to allow for
> pg_dump to work...
>
That
(CAP_BACKUP would be
> great too -- essentially "read only but read everything")
>
Isn't CAP_BACKUP pretty much the REPLICATION privilege?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sat, Jan 18, 2014 at 3:59 PM, Andrew Dunstan wrote:
>
> On 01/16/2014 08:01 AM, Magnus Hagander wrote:
>
>>
>> On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane > t...@sss.pgh.pa.us>> wrote:
>>
>> Magnus Hagander mailto:mag...@hagander.net>>
>
On Fri, Jan 17, 2014 at 4:53 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > Applied, thanks!
>
> Minor bikeshedding: the messages would read better, to my eye, as
>
> "user=%s database=%s SSL enabled (protocol=%s, cipher=%s)"
>
> Putting "enabled&quo
t seems perfe4ctly sane, so I have committed it. I'll look into the
> other issue.
>
Thanks.
I could've sworn I committed it that way, but I see now that it's sitting
unstaged in my working directory...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, Jan 17, 2014 at 2:07 PM, Thom Brown wrote:
> On 17 January 2014 13:01, Magnus Hagander wrote:
> > Is there any real use-case for not setting wal_buffers to -1 these days?
> >
> > Or should we just remove it and use the -1 behaviour at all times?
> >
> >
re not
ready to remove it, then does that just mean that we need to fix it so we
can?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
sage exists only once.
> >
> > New version is attached. I could add braces before and after the
> > ereport()-calls too, but then I need two more #ifdefs to catch the
> > closing braces.
>
> Thank you. Looks good now. I added it to next commitfest:
>
> https://commitfest.postgresql.org/action/patch_view?id=1324
>
>
Applied, thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
here. Let me know if that
understanding was incorrect, and it would actually help as a backpatch.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Wed, Jan 15, 2014 at 6:57 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > One thing I noticed - in MSVC, the config parameter "krb5" (equivalent of
> > the removed --with-krb5) enabled *both* krb5 and gssapi, and there is no
> > separate config parameter f
gt; wal_rate_limit_delay = Xms
>
Seems like a really bad name if we are only slowing down some commands -
that seems to indicate we're slowing down all of them. I think it should be
something that indicates that it only affects the maintenance commands.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Jan 14, 2014 2:44 PM, "Andres Freund" wrote:
>
> On 2014-01-14 14:42:36 +0100, Magnus Hagander wrote:
> > On Tue, Jan 14, 2014 at 2:41 PM, Andres Freund wrote:
> >
> > > On 2014-01-14 14:40:46 +0100, Magnus Hagander wrote:
> > > > On
On Tue, Jan 14, 2014 at 2:41 PM, Andres Freund wrote:
> On 2014-01-14 14:40:46 +0100, Magnus Hagander wrote:
> > On Tue, Jan 14, 2014 at 2:18 PM, Andres Freund >wrote:
> >
> > > On 2014-01-14 14:12:46 +0100, Magnus Hagander wrote:
> > > > Either way - if
uld balance with the
> amount of WAL necessary to keep and limit the whole amount on disk.
>
It wouldn't be worse performance wise than a full backup. That one also has
to read all the blocks after all... You're decreasing network traffic and
client storage, with the same I/O on the server side. Seems worthwhile.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Jan 14, 2014 at 2:18 PM, Andres Freund wrote:
> On 2014-01-14 14:12:46 +0100, Magnus Hagander wrote:
> > Either way - if we can do this in a safe way, it sounds like a good idea.
> > It would be sort of like rsync, except relying on the fact that we can
> look
> &
to compare the actual files, right?
As a next step, I would imagine that pg_basebackup could be extended
> to take incremental backups as well. Having another tool able to
> rebuild backups based on a full backup with incremental information
> would be nice as well.
>
I would say those are requirements, not just next step and "nice as well" :)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sat, Jan 11, 2014 at 9:45 PM, Peter Eisentraut wrote:
> On Thu, 2013-10-24 at 20:37 +0200, Magnus Hagander wrote:
> > On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut
> > wrote:
> > > On 10/18/12, 7:20 AM, Magnus Hagander wrote:
> > >> 1. krb5 authen
ink I used the system tables because they were
> easier to access. I can't remember if we used the symlinks for some
> things and pg_tablespace for other things in pre-9.2.
>
If you mean PostgreSQL internally then no, we didn't use pg_tablespace for
anything ever. We only used the symlinks. Which is why it was so easy to
remove.
If you were using it for something inside pg_upgrade I don't know, but the
backend didn't.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Sat, Jan 11, 2014 at 7:05 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sat, Jan 11, 2014 at 5:00 PM, Tom Lane wrote:
> >> I'm not sure I believe this. I don't see any PGDLLEXPORT symbols in any
> >> of the standard contrib modules; how is it
On Fri, Jan 10, 2014 at 3:56 AM, Mika Eloranta wrote:
> On Thu, Jan 9, 2014, at 20:05, Magnus Hagander wrote:
> > On Thu, Nov 14, 2013 at 10:27 AM, Mika Eloranta wrote:
> >> On 13 Nov 2013, at 20:51, Mika Eloranta wrote:
> >>
> >>
> >>
> > Pr
ion.
>
> I'm not sure I believe this. I don't see any PGDLLEXPORT symbols in any
> of the standard contrib modules; how is it that they work?
>
They are built through our perl toolkit, which enables exporting of *all*
symbols, regardless of flags in the code.
--
Magn
I think it's better to let pg_basebackup work at the lower level, and then
leave it to higher level tools to be able to do the mapping to names.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
sense to instead store the last number printed, and
only print it if the percentage has changed? AIUI with this patch we still
print the same thing on top of itself if it takes >1 second to get 1%
further.
(Except for verbose mode - but if you're asking for verbose mode, you are
*asking* t
quot;, because you do know that.
It's not the name of the tablespace. but I think it's still more
usefriendly than using the oid.
This feature might be missing because of some other limitation I fail
> to see, if so let me know. Please be gentle, this is my first pat
t; >> function calls like the older stats views.
> >
> > Ok, good idea.
>
> Not sure I see why it needs to be an SRF. It only returns one row.
>
Good point, it could/should be a general function returning a composite
type.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Jan 7, 2014 at 5:43 PM, Andres Freund wrote:
> On 2014-01-07 17:40:07 +0100, Magnus Hagander wrote:
> > On Tue, Dec 24, 2013 at 1:24 PM, Andres Freund >wrote:
> >
> > > On 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> > > > On Dec 19, 2013
On Tue, Dec 24, 2013 at 1:24 PM, Andres Freund wrote:
> On 2013-12-23 18:28:51 +0100, Magnus Hagander wrote:
> > On Dec 19, 2013 12:06 AM, "Andres Freund"
> wrote:
> > >
> > > Hi Magnus,
> > >
> > > It looks to me like the path to do_pg_s
On Thu, Jan 2, 2014 at 2:06 PM, Dimitri Fontaine wrote:
> Magnus Hagander writes:
> > We can't get away with just comparing the relative part of the pathname.
> > Because it will fail if there is another path with exactly the same
> length,
> > containing the t
On Sat, Jan 4, 2014 at 2:01 PM, Gabriele Bartolini <
gabriele.bartol...@2ndquadrant.it> wrote:
> Il 04/01/14 13:25, Magnus Hagander ha scritto:
> > With those two, I think it would make much sense to have a view like
> > this.
>
> Ok, I will prepare version 2 with thos
0" when it's just sent
one file? ISTM that pgstat_recv_archiver should just do ++ on the value?
Oh, and you need to change the format id number of the stats file.
There's a quick review you for ;) I think it's definitely worthwhile with
those things fixed (and a proper review, that was just a quick one-over)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
and then skip it based on that instead. Or store and pass
the value of getcwd() perhaps.
Or am I thinking wrong now instead? :)
I've attached a slightly updated patch - I changed around a bit of logic
order and updated some comments during my review. And added error-checking.
--
Magnus Hagander
On Dec 19, 2013 12:06 AM, "Andres Freund" wrote:
>
> Hi Magnus,
>
> It looks to me like the path to do_pg_start_backup() outside of a
> transaction context comes from your initial commit of the base backup
> facility.
> The problem is that you're not allowed to do anything leading to a
> syscache/
;
> 2) HIGH:MEDIUM:+3DES:!aNULL - no suite changes from current one,
>except 3DES is ordered last.
>
> +3DES reorders already picked 3DES suites to the end. As my
> impression is that no clients ever have actually used 3DES,
> it's fine to use !3DES there. It&#x
emove
the default value. What happens if the error that needs to be logged is the
one saying that it couldn't exec postgres to find out the value in the
config file? AFAICT it's going to try to register an eventsource with
whatever random garbage happens to be in the variable.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
gresql.org/cgi-bin/show_stage_log.pl?nm=frogmouth&dt=2013-12-08%2007%3A30%3A01&stg=make-contrib
that
there are compiler warnings being generated in pgss. But from a quick look
that looks like something pre-existing and not caused by the latest patch.
--
Magnus Hagander
Me: http://www
IFY_SYSTEM return the current timestamp on the master, and refuse to
start if the time difference is too great. Yes, that doesn't catch the case
when the machines are in perfect sync when they start up and drift *later*,
but it will catch the most common cases I bet. But I think that's goo
On Wed, Dec 4, 2013 at 8:43 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
> >> I assume what would happen is the slave would PANIC upon seeing a WAL
> >> record code it didn't recognize.
>
> > I wo
greSQL community wanted to be there.
>
I think that's an excellent idea. If one of our developers could find the
time to attend that, I think that could be very productive. While I'm not
on the funds team, I'd definitely vote for funding such participation out
of community fund
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane wrote:
> >> Maybe we should just bite the bullet and change the WAL format for
> >> heap_freeze (inventing an all-new record type, not repurp
.
>
>
If you're looking for more of those, here's another +1 for not including
it. (And of course also for Peters comment about that we need to figure out
if something is actually missing for building this higher level tool that
can provide this information and more)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
pre-requisite to get it done. But sure - I'm
all for trying a kickstarter. Did anybody ever try that for an actual
postgres feature? Didn't JD and/or cmd and/or pgus at some point try
something like that?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > On Tue, Dec 3, 2013 at 7:11 PM, Tom Lane wrote:
> >> Maybe we should just bite the bullet and change the WAL format for
> >> heap_freeze (inventing an all-new record type, not repurp
stems require as well, so that's not
an unreasonable requirement at all.
I assume we'd then get rid of the old record type completely in 9.4, right?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Fri, Nov 29, 2013 at 4:06 AM, Peter Eisentraut wrote:
> On Mon, 2013-11-25 at 16:32 +0100, Magnus Hagander wrote:
> > Thanks for the reminder - done (installed the DEB from sid, version
> > 1.78.1).
>
> > This will somehow show up in the snapshot builds, correct?
On Mon, Nov 25, 2013 at 4:40 PM, Tom Lane wrote:
> Magnus Hagander writes:
> > This will somehow show up in the snapshot builds, correct? So we (you?
> :P)
> > can verify after the next snapshots that it's correct?
>
> I thought the devel docs at
> http://www.
On Mon, Nov 25, 2013 at 4:27 PM, Peter Eisentraut wrote:
> On 10/3/13, 7:58 AM, Magnus Hagander wrote:
> >> Did we get around to doing this?
> > Nope.
> >
> > Given my schedule between now and the release wrap, I won't have a
> > chance to do it if I wa
n).
The point is - regardless of which version you chose, reviewers and
committers are going to have to deal with a local installation in many
cases anyway. So we might be better off just documenting that in a more
clear way.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
ao wrote:
> >> >> >> > On Sat, Nov 16, 2013 at 2:27 PM, Haribabu kommi
> >> >> >> > wrote:
> >> >> >> > > on 15 November 2013 17:26 Magnus Hagander wrote:
> >> >> >> > >
> >> >&
. Specifying that would be redundant in the first place,
but people ca do that, but it would also be very easy to do it by mistake,
and you'd end up with something that's really bad, including a recursive
symlink.
I also think it would probably be worthwhile to support this in tar format
as well, but I guess that's a separate patch really. There's really no
reason we should't support wal streaming into a separate tar file. But -
separate issue.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
t I do agree with the
requirement to have a GUC to be able to remove it - even though I don't
like the idea of more GUCs. But making it a compile time option would make
it the same as not having one...
//Magnus
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
e? In fact, we already have some in
script/common.c - but it's only used by the tools that are in script/.
//Magnus
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
the developer docs a while ago.
> In addition, why isn't INSTALL stored in git?
>
Because it's built from SGML, to have the same contents as the html/pdf
docs. We don't typically store derived files in git - only some exceptions
like configure.
--
Magnus Hagander
ng in that case, but on
second thought I think that's just wrong - it will send out warning
messages in cases that are absolutely normal.
I'm not going to bother with a backend side patch, since this is
mostly harmless (it sends a single packet of an extra 25 bytes in
wha
On Thu, Nov 7, 2013 at 7:08 PM, Joshua D. Drake wrote:
>
> On 11/07/2013 10:00 AM, Josh Berkus wrote:
>>
>>
>> On 11/07/2013 08:26 AM, Tom Lane wrote:
>>>
>>> Magnus Hagander writes:
>>>>
>>>> On Thu, Nov 7, 2013 at 5:02 PM, Josh
e pg_dump and instead use
> PITR?
For backups, absolutely.
That is, assuming you mean "pg_basebackup -x", and not full
archive_command/full pitr setup.
That's still a separate argument, of course.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-lin
pe-mode, which would break.
Though I have to say I like the idea in general :)
Maybe we could consider changing the default format if -f is specified
to write it directly to a file. OTOH, hat might just make it
confusing
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.red
ery case worth it. Even in the archive recovery mode, being
able to do pause_at_recovery_target is extremely useful. And as you
say in (c) above, many users don't realize that until it's too late.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Oct 24, 2013 at 8:35 PM, Peter Eisentraut wrote:
> On 10/18/12, 7:20 AM, Magnus Hagander wrote:
>> 1. krb5 authentication. We've had gssapi since 8.3 (which means in all
>> supported versions). krb5 has been deprecated, also since 8.3. Time to
>> remove it?
is really adding much in the way of clarity.
+1. If changing at all, then maybe just "autovacuum_mem"? It's not
like there's a different parameter to control a different kind of
memory in autovac, is there?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://w
he "only" come from? And we don't really use the term
"prefers over" anywhere else there. And -1 doesn't actually disable
it. I suggest following the pattern of the other parameters that work
the same way, which would then just be:
#autovacuum_work_mem = -1 # amount of mem
On Tue, Oct 15, 2013 at 7:32 PM, Andres Freund wrote:
> On 2013-10-15 19:29:50 +0200, Magnus Hagander wrote:
>> On Tue, Oct 15, 2013 at 7:26 PM, Andres Freund
>> wrote:
>> > On 2013-10-15 10:19:06 -0700, Josh Berkus wrote:
>> >> On 10/15/2013 05:52 AM, Ma
On Tue, Oct 15, 2013 at 7:26 PM, Andres Freund wrote:
> On 2013-10-15 10:19:06 -0700, Josh Berkus wrote:
>> On 10/15/2013 05:52 AM, Magnus Hagander wrote:
>> > But the argument about being friendly for new users should definitely
>> > have us change wal_level and ma
pg companies as well, have agreements with MS that lets
you get access to their "real" support. I know I used to have it at my
last job, and used it a number of times during the initial porting
work. The people backing that one are generally pretty good)
--
Magnus Hagander
Me: http://w
d it, because they
didn't know what it was.
But the argument about being friendly for new users should definitely
have us change wal_level and max_wal_senders.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing
e might be an "official workaround" for
it, or in fact, there might already exist a fix for it..
We're *probably* going to have to end up deploying a workaround, but
it would be a good idea to check first if they have a suggestion for
how...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Oct 11, 2013 10:23 PM, "Josh Berkus" wrote:
>
> On 10/11/2013 01:11 PM, Bruce Momjian wrote:
> > In summary, I think we need to:
> >
> > * decide on new defaults for work_mem and maintenance_work_mem
> > * add an initdb flag to allow users/packagers to set shared_bufffers?
> > * add an autov
On Oct 12, 2013 2:13 AM, "MauMau" wrote:
>
> From: "Bruce Momjian"
>>
>> On Thu, Oct 10, 2013 at 11:01:52PM +0900, MauMau wrote:
>>>
>>> Although this is not directly related to memory, could you set
>>> max_prepared_transactions = max_connections at initdb time? People
>>> must feel frustrated
un through a recompile every time something is touched.
I think in the context of this problem, reimplementing that from
python to C is the easiest part. Actually figuring out what the tool
should *do* and how it should do it is the hard part.
--
Magnus Hagander
Me: http://www.hagander.net/
Wo
d a
>> plpgsql function called pg_tune().
>
> That's another way to do it, for sure. It does require the ability to
> log in to the database. I imagine that could be less convenient in
> some scripting environments.
I think that would also make it much harder to automate fo
; One nice thing about a tool is that you can see your auto-tuned defaults
>> right away, while doing this in the backend, you have to start the
>> server to see the defaults. I am not even sure how I could allow users
>> to preview their defaults for different available_mem set
he platform
specific interfaces to it can go in the packaging.
(And yes, in a lot of cases "we" are also the packagers, but the point
being that this code is already 100% platform specific, making the
problem easier)
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.
s (preferably with a comment).
That way if the user *later* comes in and say changes shared_buffers,
we don't dynamically resize the work_mem into a value that might cause
his machine to die from swapping which would definitely violate the
principle of least surprise..
--
Magnus Hagander
remember to
re-tune maintenance_wokr_mem when they change the number of autovacuum
workers.
I would, however, vote for an autovacuum_work_mem rather than a
vacuum_work_mem. Analog to the autovacuum_vacuum_cost_* parameters
that override the "foreground" parameters.
(Though you can give a custom
On Oct 8, 2013 6:27 PM, "Robert Haas" wrote:
>
> On Mon, Oct 7, 2013 at 7:51 AM, Andrew Dunstan
> wrote:
> > Given that we have not supported releases older than 8.3 for quite a
while,
> > do we need to keep this in extend.sgml any longer?
>
> +1 for removing that (but only in master, not the bac
hooks, but those would be very hard to
override when you *do* need to modify the files (which you might
within a release).
What we could also do is just have the make all target, or the
configure script, (or something else a developer runs often) chmod the
file. It's not bulletproof in any
On Tue, Oct 1, 2013 at 11:37 PM, Alvaro Herrera
wrote:
> Magnus Hagander wrote:
>> On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane wrote:
>> > Peter Eisentraut writes:
>> >> On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote:
>> >>> Given that, I
On Oct 3, 2013 2:47 AM, "Michael Paquier" wrote:
>
> On Wed, Oct 2, 2013 at 11:31 PM, Magnus Hagander
wrote:
> > Right now, if you use
> >
> > pg_basebackup -Ft -D -
> >
> > you get a tarfile, written to stdout, for redirection.
> >
&
fix, but I'd say it
fixes some seriously annoying behavior.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ip it to an ERROR. But if we do
flip it to an ERROR, we should have a way to disable that error if, as
Alvaro puts it, we end up breaking too many things.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
tarting to use that is going to make it even harder to break
out from our openssl dependency, which people do complain about at
least semi-regularly.
I wonder how much work it would be to build something on top of lower
level primitives that are provided in them all. For example,
https://github.com/
On Tue, Sep 10, 2013 at 3:53 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-09-10 12:31:22 +0200, Magnus Hagander wrote:
>>> On Tue, Sep 10, 2013 at 5:29 AM, Tom Lane wrote:
>>>> I've been thinking of late that it might be time to retire libpq's
q clients such as JDBC have an issue
> with this.
It's probably worth polling for that. I believe the jdbc driver at
least has code for it, but I don't know if it's a requirement at this
point.
If it is, that might be a "10.0 release" feature, in how it would
brea
default so the EXPLAIN
> regression tests would pass unchanged.
That's not really autotuning though. ISTM that making the *default* 4
x shared_buffers might make perfect sense, but do we really need to
hijack the value of "-1" for that? That might be useful for some time
whe
On Sep 3, 2013 6:23 PM, "Josh Berkus" wrote:
>
> Peter,
>
>
> > I wonder, is anyone really running in production with full_page_writes
> > off?
>
> We're doing so with clients on Joyent (ZFS). And also for "ephemeral"
> postgres instances -- ones where we've also turned off fsync.
>
> It's also q
On Thu, Aug 22, 2013 at 8:13 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On Fri, 2013-07-12 at 12:30 +0200, Magnus Hagander wrote:
>>> Given that, I'm fine with just bumping the version on borka to that
>>> version. Any objections?
>
>> This was n
On Tue, Jul 23, 2013 at 11:53 AM, Albe Laurenz wrote:
> Magnus Hagander wrote:
>> In that case, doesn't this patch break Windows? We no longer do the
>> anonymous bind on Windows, since it's now in the #ifdef HAVE_LIBLDAP.
>>
>> Don't we need to keep
On Thu, Aug 15, 2013 at 5:26 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Magnus Hagander writes:
>> > psql is missing tab completion for \dx (or more usfully, for \dx+).
>> > Attached patch fixes this.
>>
>> > Do we consider th
psql is missing tab completion for \dx (or more usfully, for \dx+).
Attached patch fixes this.
Do we consider this a bugfix and backpatch (at least to 9.3? even
though the problem goes back further), or head only?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill
On Aug 15, 2013 3:44 AM, "Tom Lane" wrote:
>
> Josh Berkus writes:
> >> Before 9.3, it would delete one specific file from a potentially shared
> >> directory. In 9.3 it deletes the entire contents of a potentially
shared
> >> directory. That is a massive expansion in the surface area for
> >>
them as signed 32-bit integers. It's
>> obviously a corner case, but it would be prudent to be correct about
>> this. It should be easy to fix in those grammar files.
>
> Here is a patch to fix this.
Looks fine to me, and looks like the correct thing to do.
--
Magnus
On Mon, Aug 12, 2013 at 8:14 PM, Andrew Dunstan wrote:
>
> On 08/12/2013 01:40 PM, Magnus Hagander wrote:
>>>>
>>>> I also like the concept of #2, but I think we need to think about it a
>>>> bit more. One of the things I like about barman backups
ng off the tarfiles, and we don't really have a program
dealing with the restore of those at all - you're just supposed to do
it manually.
A trivial tool that worked off the directory of tarfiles and allowed
remapping of the tablespace locations (by updating the
symlinks/junctions restored
ur account during that period, it would not work for the cf
app (but it would work for the wiki and some other sites).
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
nality, and they're basically
> unusable for dynamically started background workers. Probably better
> not to get people to used to using them.
+1. Much better to take that pain now, before we have made a production release.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://w
On Thu, Jul 11, 2013 at 8:34 PM, Peter Eisentraut wrote:
> On 7/11/13 5:55 AM, Magnus Hagander wrote:
>> If it's safe to switch on the old ones as well, it sounds doable. If
>> we need different toolchains, that's going to be a serious pain. Have
>> you verified t
On Thu, Jul 11, 2013 at 3:43 PM, Greg Stark wrote:
> On Wed, Jul 10, 2013 at 9:36 AM, Magnus Hagander wrote:
>> We already run this, that's what we did to make it survive at all. The
>> problem is there are so many thousands of different URLs you can get
>> to on tha
lchains, that's going to be a serious pain. Have
you verified that it's fine with the old ones as well, or are you jsut
assuming?
Second, when you say "the latest debian package", you mean grab the
one from sid? I didn't see anything in backports, but maybe I'm
missing
imilar would do quite nicely.
We already run this, that's what we did to make it survive at all. The
problem is there are so many thousands of different URLs you can get
to on that site, and google indexes them all by default.
It's before we had this that the side regularly died.
-
ICT, there aren't any for cgit, but maybe
I'm searching for the wrong thing..
If they do all those things, and people do like those interfaces, then
sure, we can do that.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hack
901 - 1000 of 4991 matches
Mail list logo
