On 23/01/14 14:45, Christian Kruse wrote:
> > Well, is it context or detail? Those fields have reasonably well
> > defined meanings IMO.
>
> I find the distinction somewhat blurry and think both would be
> appropriate. But since I wasn't sure I changed to detail.
>
> > If we need errcontext_plur
On 22 January 2014 13:09, Tatsuo Ishii wrote:
> > I, as a user would be happier if we also have to_regprocedure() and
> > to_regoperator(). The following query looks a valid use-case where one
> > needs to find if a particular function exists. Using to_regproc('sum')
> does
> > not make sense her
Hi,
> I think you have attached wrong patch.
Hurm. You are right, attached v3, not v4. Sorry.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/storage/lmgr/proc.c b/src/backend/stora
Peter,
On Thu, Jan 23, 2014 at 2:06 AM, Peter Eisentraut wrote:
>
> I'm tempted to think it should be mandatory to specify this option in
> plain mode when tablespaces are present. Otherwise, creating a base
> backup is liable to create random files all over the place. Obviously,
> there would b
On 23 January 2014 06:13, KaiGai Kohei wrote:
> A minor comment is below:
>
> ! /*
> !* Make sure that the query is marked correctly if the added
> qual
> !* has sublinks.
> !*/
> ! if (!parsetree->hasSubLinks)
> ! parsetree->ha
On 2014-01-22 18:19:25 -0600, Jim Nasby wrote:
> On 1/21/14, 6:46 PM, Andres Freund wrote:
> >On 2014-01-21 16:34:45 -0800, Peter Geoghegan wrote:
> >>>On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund
> >>>wrote:
> >I personally think this isn't worth complicating the code for.
> >>>
> >>>You'
Hi,
On 2014-01-22 13:00:44 -0500, Robert Haas wrote:
> Well, apparently, one is going to PANIC and reinitialize the system.
> I presume that upon reinitialization we'll decide that the slot is
> gone, and thus won't recreate it in shared memory.
Yea, and if it's half-gone we'll continue deletion.
(2014/01/23 10:28), Peter Geoghegan wrote:
On Wed, Jan 22, 2014 at 5:28 PM, KONDO Mitsumasa
wrote:
Oh, thanks to inform me. I think essential problem of my patch has bottle
neck in sqrt() function and other division caluculation.
Well, that's a pretty easy theory to test. Just stop calling th
On 23 January 2014 01:19, Jim Nasby wrote:
> On 1/21/14, 6:46 PM, Andres Freund wrote:
>>
>> On 2014-01-21 16:34:45 -0800, Peter Geoghegan wrote:
>>>
>>> >On Tue, Jan 21, 2014 at 3:43 PM, Andres Freund
>>> > wrote:
> >I personally think this isn't worth complicating the code for.
>>>
>>>
On 2014-01-15 02:11:11 -0300, Alvaro Herrera wrote:
> Then execute commands to your liking.
So, I am giving a quick look, given that I very likely will have to
write a consumer for it...
* deparse_utility_command returns payload via parameter, not return
value?
* functions beginning with an und
Shigeru Hanada wrote:
> Attached patch allows a foreign table to be a child of a table. It
> also allows foreign tables to have CHECK constraints.
Sorry for the delay. I started to look at this patch.
> Though this would be debatable, in current implementation, constraints
> defined on a foreign
We started this commit fest with 103 patches and got off to a flyer,
with 20 patches committed during the first week. Somehow we ended up
with 113 patches at the end of the first week, but let's please leave it
at that.
I'm tracking down patch authors who have not signed up for a review.
I'll als
Hi,
On 2014-01-15 02:00:51 -0500, Jaime Casanova wrote:
> On Mon, Nov 18, 2013 at 12:27 PM, Andres Freund
> wrote:
> > Hi,
> >
> > On 2013-11-15 22:38:05 -0500, Jaime Casanova wrote:
> >> sorry, i clearly misunderstood you. attached a rebased patch with
> >> those functions removed.
> >
> > * --
Isn't it necessary to have an interface to initialize LWLock structure being
allocated on a dynamic shared memory segment?
Even though LWLock structure is exposed at lwlock.h, we have no common
way to initialize it.
How about to have a following function?
void
InitLWLock(LWLock *lock)
{
SpinL
On 2014-01-23 23:03:40 +0900, Kohei KaiGai wrote:
> Isn't it necessary to have an interface to initialize LWLock structure being
> allocated on a dynamic shared memory segment?
> Even though LWLock structure is exposed at lwlock.h, we have no common
> way to initialize it.
There's LWLockInitialize
2014/1/23 Andres Freund :
> On 2014-01-23 23:03:40 +0900, Kohei KaiGai wrote:
>> Isn't it necessary to have an interface to initialize LWLock structure being
>> allocated on a dynamic shared memory segment?
>> Even though LWLock structure is exposed at lwlock.h, we have no common
>> way to initiali
On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
>>> So? Anything which can know the value of a GUC parameter can certainly
>>> know the selected port number.
>
>> 1. In case of registration of event source, either user
On 01/22/2014 11:33 PM, KONDO Mitsumasa wrote:
(2014/01/23 12:00), Andrew Dunstan wrote:
On 01/22/2014 08:28 PM, KONDO Mitsumasa wrote:
(2014/01/22 22:26), Robert Haas wrote:
On Wed, Jan 22, 2014 at 3:32 AM, KONDO Mitsumasa
wrote:
OK, Kondo, please demonstrate benchmarks that show we have <
On 01/23/2014 08:11 AM, Peter Eisentraut wrote:
We started this commit fest with 103 patches and got off to a flyer,
with 20 patches committed during the first week. Somehow we ended up
with 113 patches at the end of the first week, but let's please leave it
at that.
I'm tracking down patch au
On 2014-01-21 11:33:40 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-01-21 12:11:23 -0300, Alvaro Herrera wrote:
> >> How difficult would it be to have expand_fmt_string deal with positional
> >> modifiers? I don't think we need anything from it other than the %n$
> >> notation, so p
On Wed, Jan 22, 2014 at 12:42 PM, Andres Freund wrote:
> On 2014-01-22 12:40:34 -0500, Robert Haas wrote:
>> On Wed, Jan 22, 2014 at 12:11 PM, Tom Lane wrote:
>> > Andres Freund writes:
>> >> Shouldn't we introduce a typedef LWLock* LWLockid; or something to avoid
>> >> breaking external code us
Hi,
Is there a particular reason why the "direct" arguments of ordered-set
aggregates are not passed to the transition function too? It seems that
evaluating of some ordered-set aggregates would be much cheaper if we did
that.
For example, dense_rank() would then just need to count the number of
On 2014-01-23 11:14:05 -0500, Tom Lane wrote:
> OK, I'll take a look.
Thanks.
> > I am not too
> > happy about the runtime check as the test isn't all that meaningful, but
> > I couldn't think of anything better.
>
> Yeah, it's problematic for cross-compiles, but no more so than configure's
> ex
Andres Freund writes:
> So, here's a patch adding %z support to port/snprintf.c including a
> configure check to test whether we need to fall back.
OK, I'll take a look.
> I am not too
> happy about the runtime check as the test isn't all that meaningful, but
> I couldn't think of anything bette
On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
Attached version is rebased against last version of packed posting lists.
Thanks!
I think we're missing a trick with multi-key queries. We know that when
multiple scan keys are used, they are ANDed together, so we can do the
skip optimization
Florian Pflug writes:
> Is there a particular reason why the "direct" arguments of ordered-set
> aggregates are not passed to the transition function too?
Because they have to be evaluated only once.
I did consider evaluating them once at the start and saving the values,
but that's a bit problem
Andres Freund writes:
> I was wondering more about the nature of the runtime check than the fact
> that it's a runtime check at all... E.g. snprintf.c simply skips over
> unknown format characters and might not have been detected as faulty on
> 32bit platforms by that check. Which might be conside
On Jan23, 2014, at 17:20 , Tom Lane wrote:
> Florian Pflug writes:
>> Is there a particular reason why the "direct" arguments of ordered-set
>> aggregates are not passed to the transition function too?
>
> Because they have to be evaluated only once.
>
> I did consider evaluating them once at t
On Thu, Jan 23, 2014 at 7:05 AM, Andres Freund wrote:
> I don't think shared buffers fsyncs are the apt comparison. It's more
> something like UpdateControlFile(). Which PANICs.
>
> I really don't get why you fight PANICs in general that much. There are
> some nasty PANICs in postgres which can ha
On 2014-01-23 11:25:56 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I was wondering more about the nature of the runtime check than the fact
> > that it's a runtime check at all... E.g. snprintf.c simply skips over
> > unknown format characters and might not have been detected as faulty on
>
On 2014-01-23 11:50:57 -0500, Robert Haas wrote:
> On Thu, Jan 23, 2014 at 7:05 AM, Andres Freund wrote:
> > I don't think shared buffers fsyncs are the apt comparison. It's more
> > something like UpdateControlFile(). Which PANICs.
> >
> > I really don't get why you fight PANICs in general that m
On 01/13/2014 10:49 PM, Dilip kumar wrote:
>
> As per current behavior if user want to build in debug mode in
> windows, then he need to give debug in capital letters (DEBUG),
>
> I think many user will always make mistake in giving this option, in
> my opinion we can make it case insensitive.
>
>
On Wed, Jan 22, 2014 at 11:48 PM, Fujii Masao wrote:
> Hi,
>
> I reported in other thread that PQhost() has three problems.
>
> http://www.postgresql.org/message-id/cahgqgwe77akyabywde5+8bjldopthp7cnswao_syedjogyv...@mail.gmail.com
>
> (1) PQhost() can return Unix-domain s
On Wed, Dec 4, 2013 at 9:21 PM, MauMau wrote:
> Hello,
>
> I've found a bug that psql's \conninfo displays incorrect information on
> Windows. Please find attached the patch and commit this.
>
> [Problem]
> When I run "psql postgres" on Windows and execute \conninfo, it outputs the
> text below.
Andres Freund writes:
> snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
Actually, that coding isn't gonna work at all on platforms where size_t
isn't the same size as uint64. We could make it work by explicitly
casting the argument to whatever type we've decided to use as uint64
... but unless
On 2014-01-23 12:54:22 -0500, Tom Lane wrote:
> Andres Freund writes:
> > snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
>
> Actually, that coding isn't gonna work at all on platforms where size_t
> isn't the same size as uint64. We could make it work by explicitly
> casting the argument to w
Pavel Stehule escribió:
> I though about it too. But I didn't continue - reasons was named by Dean -
> and RemoveObjects are not difficult code - lot of code is mechanical - and
> it is not on critical path.
I have pushed it after some editorialization.
--
Álvaro Herrerahttp://w
Alvaro Herrera wrote:
> With apologies to our beloved commitfest-mace-wielding CFM, commitfest
> 2013-11 intentionally still contains a few open patches. I think that
> CF is largely being ignored by most people now that we have CF 2014-01
> in progress. If we don't want to do anything about thes
Andres Freund writes:
> On 2014-01-23 12:54:22 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> snprintf(buf64, 100, UINT64_FORMAT, ~(size_t)0);
>> Actually, that coding isn't gonna work at all on platforms where size_t
>> isn't the same size as uint64. We could make it work by explicitly
>>
Andrew Dunstan writes:
> I have committed this. It's in the commitfest as a bug fix, but I don't
> think it's strictly a bug. OTOH, it's pretty harmless. Do we want to
> backpatch it?
Given the lack of field complaints, I'd say it's not worth the trouble.
regards, tom lan
The rather ancient gcc on my HPUX box is complaining thusly about HEAD:
ginbtree.c: In function `ginPlaceToPage':
ginbtree.c:602: warning: control reaches end of non-void function
I would imagine this would happen on any compiler that doesn't recognize
the hint about elog(ERROR) not returning. C
Andres Freund escribió:
> * Why must we not schema qualify system types
> (c.f. expand_jsonval_typename)? It seems to be perfectly sensible to
> me to just use pg_catalog there.
So, the reason for doing things this way is to handle cases like
"varchar(10)" being turned into "character varying
On 01/22/2014 06:28 PM, Heikki Linnakangas wrote:
> Compress GIN posting lists, for smaller index size.
>
> GIN posting lists are now encoded using varbyte-encoding, which allows them
> to fit in much smaller space than the straight ItemPointer array format used
> before. The new encoding is used
On 12/06/2013 09:16 AM, MauMau wrote:
> Hello,
>
> According to this page,
>
> http://www.postgresql.org/docs/current/static/install-procedure.html
>
> client-only installation is possible on UNIX/Linux like this:
>
> gmake -C src/bin install
> gmake -C src/include install
> gmake -C src/interface
On 01/23/2014 09:18 PM, Stefan Kaltenbrunner wrote:
On 01/22/2014 06:28 PM, Heikki Linnakangas wrote:
Compress GIN posting lists, for smaller index size.
GIN posting lists are now encoded using varbyte-encoding, which allows them
to fit in much smaller space than the straight ItemPointer array
I wrote:
> I checked on my HPUX box and find that what it prints for "%zu" is
> "zu", confirming my thought that it'd just abandon processing of the
> %-sequence. (Interesting that it doesn't eat the "z" while doing
> so, though.)
Further testing on that box shows that its ancient gcc (2.95.3) do
On 01/23/2014 08:41 PM, Tom Lane wrote:
The rather ancient gcc on my HPUX box is complaining thusly about HEAD:
ginbtree.c: In function `ginPlaceToPage':
ginbtree.c:602: warning: control reaches end of non-void function
I would imagine this would happen on any compiler that doesn't recognize
th
Alvaro Herrera writes:
> So, the reason for doing things this way is to handle cases like
> "varchar(10)" being turned into "character varying"; and that name
> requires that the typename NOT be schema-qualified, otherwise it fails.
> But thinking about this again, I don't see a reason why this ca
Hello,
I have run into yet again another situation where there was an
assumption that autovacuum was keeping up and it wasn't. It was caused
by autovacuum quitting because another process requested a lock.
In turn we received a ton of bloat on pg_attribute which caused all
kinds of other is
Heikki Linnakangas writes:
> On 01/23/2014 09:18 PM, Stefan Kaltenbrunner wrote:
>> it seems that this commit made spoonbill an unhappy animal:
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2014-01-23%2000%3A00%3A04
> Hmm, all the Sparcs. Some kind of an alignment issue, perha
"Joshua D. Drake" writes:
> I have run into yet again another situation where there was an
> assumption that autovacuum was keeping up and it wasn't. It was caused
> by autovacuum quitting because another process requested a lock.
> In turn we received a ton of bloat on pg_attribute which cause
On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
>
> Hello,
>
> I have run into yet again another situation where there was an
> assumption that autovacuum was keeping up and it wasn't. It was caused
> by autovacuum quitting because another process requested a lock.
>
> In turn we received a ton o
On Thu, Jan 23, 2014 at 12:53 PM, Josh Berkus wrote:
> On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
>>
>> Hello,
>>
>> I have run into yet again another situation where there was an
>> assumption that autovacuum was keeping up and it wasn't. It was caused
>> by autovacuum quitting because anothe
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
regards, tom lane
I've seen this sort of problem where every db session was busily
creating temporary tables. I never got to the
Patch 0001:
+errmsg("could not find free replication slot"),
Suggest: all replication slots are in use
+ elog(ERROR, "cannot aquire a slot while another slot
has been acquired");
Suggest: this backend has already acquired a replication slot
Or demo
On 01/23/2014 10:37 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 01/23/2014 09:18 PM, Stefan Kaltenbrunner wrote:
it seems that this commit made spoonbill an unhappy animal:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2014-01-23%2000%3A00%3A04
Hmm, all the Sparcs. So
On Thu, Jan 23, 2014 at 9:23 AM, Amit Kapila wrote:
> On Thu, Jan 23, 2014 at 10:26 AM, Tom Lane wrote:
>> Amit Kapila writes:
>>> On Wed, Jan 22, 2014 at 9:03 PM, Tom Lane wrote:
So? Anything which can know the value of a GUC parameter can certainly
know the selected port number.
>>
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
> On 24/01/14 09:49, Tom Lane wrote:
>> 2. What have you got that is requesting exclusive lock on pg_attribute?
>> That seems like a pretty unfriendly behavior in itself. regards, tom lane
>
> I've seen this sort of problem where every db sessi
On 1/20/14 9:46 AM, Mel Gorman wrote:
They could potentially be used to evalate any IO scheduler changes.
For example -- deadline scheduler with these parameters has X
transactions/sec throughput with average latency of Y millieseconds
and a maximum fsync latency of Z seconds. Evaluate how well
On 01/23/2014 01:03 PM, Mark Kirkwood wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute? That seems like a pretty unfriendly behavior in itself.
regards, tom lane
I've seen this sort of problem where every db session was busily
c
Dne 23.1.2014 22:04 "Mark Kirkwood"
napsal(a):
>
> On 24/01/14 09:49, Tom Lane wrote:
>>
>> 2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards, tom lane
>
>
> I've seen this sort of problem where every db session
Mark Kirkwood writes:
> On 24/01/14 09:49, Tom Lane wrote:
>> 2. What have you got that is requesting exclusive lock on
>> pg_attribute? That seems like a pretty unfriendly behavior in itself.
> I've seen this sort of problem where every db session was busily
> creating temporary tables. I nev
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on pg_attribute?
That seems like a pretty unfriendly behavior in itself. regards, tom lane
I've seen this sort
From: "Amit Kapila"
How about below message:
event source "" is already registered.
OK, I added several lines for this. Please check the attached patch.
What I had in mind was to change it during initdb, we are already doing it
for some other parameter (unix_socket_directories), please re
On 1/23/14, 4:08 PM, Robert Haas wrote:
> Why wouldn't that be necessary with your approach, too? I mean, if
> there's a GUC that controls the event source name, then it can be
> changed between restarts, regardless of what you call it.
I don't know if it's practical, but the logical conclusion h
Peter Eisentraut writes:
> On 1/23/14, 4:08 PM, Robert Haas wrote:
>> Why wouldn't that be necessary with your approach, too? I mean, if
>> there's a GUC that controls the event source name, then it can be
>> changed between restarts, regardless of what you call it.
> I don't know if it's practi
Tom Lane escribió:
> Peter Eisentraut writes:
> > On 1/23/14, 4:08 PM, Robert Haas wrote:
> >> Why wouldn't that be necessary with your approach, too? I mean, if
> >> there's a GUC that controls the event source name, then it can be
> >> changed between restarts, regardless of what you call it.
>
On Thu, Nov 14, 2013 at 9:23 AM, Heikki Linnakangas
wrote:
> Ok, here's a new version of the patch to handle incomplete B-tree splits.
I finally got around to taking a look at this. Unlike with the as-yet
uncommitted "Race condition in b-tree page deletion" patch that Kevin
looked at, which there
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
On 24/01/14 09:49, Tom Lane wrote:
2. What have you got that is requesting exclusive lock on
pg_attribute?
That seems like a pretty unfriendly behavior in itself
> I wonder if it wouldn't be better to get rid of the subdirectories for
> the individual slots, and just have a file pg_replslot/$SLOTNAME, or
> not. I know there are later patches that need subdirectories for
> their own private data, but they could just create
> pg_replslot/$SLOTNAME.dir and pu
Alvaro Herrera writes:
> Tom Lane escribió:
>> That particular ID would be a horrid choice, because we don't try very
>> hard to ensure it's unique. In particular, a standby server on the same
>> machine as the master (not an uncommon case, at least for testing
>> purposes) would be a guaranteed
Heikki Linnakangas writes:
> On 01/23/2014 10:37 PM, Tom Lane wrote:
>> The problem appears to be due to the misaligned "plist" pointer
>> (0xc39efac1 here).
> Ah, thanks! Looks like I removed a SHORTALIGN from ginFormTuple that was
> in fact very much necessary.. Fixed now, let's see if that pa
On Thu, Jan 23, 2014 at 10:00 PM, Harold Giménez wrote:
> On Thu, Jan 23, 2014 at 12:53 PM, Josh Berkus wrote:
> > On 01/23/2014 12:34 PM, Joshua D. Drake wrote:
> >>
> >> Hello,
> >>
> >> I have run into yet again another situation where there was an
> >> assumption that autovacuum was keeping
I wrote:
> the idea that we might get many dozen such warnings on more-current
> compilers is scarier, as that might well interfere with people's
> ability to do development on, say, Windows. Could somebody check
> whether MSVC for instance complains about format strings using "z"?
> Or shall I ju
From: "Tom Lane"
I'm still not clear on why we can't just use the port number.
It will be possible to use port to set the default value of event_source GUC
when starting postmaster. But using port during event source registration
will involve much more.
To use port, we have to tell the loca
"MauMau" writes:
> From: "Tom Lane"
>> I'm still not clear on why we can't just use the port number.
> To use port, we have to tell the location of $PGDATA to regsvr32.exe.
[ scratches head... ] Exactly which of the other proposals *doesn't*
require that? Certainly anything that involves par
On 01/23/2014 02:17 PM, Magnus Hagander wrote:
> FWIW, I have a patch around somewhere that I never cleaned 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
On 01/23/2014 02:55 PM, Josh Berkus wrote:
> On 01/23/2014 02:17 PM, Magnus Hagander wrote:
>> FWIW, I have a patch around somewhere that I never cleaned up properly for
>> submissions that simply added a counter to pg_stat_user_tables indicating
>> how many times vacuum had aborted on that specifi
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
> On 24/01/14 10:16, Mark Kirkwood wrote:
>
>> On 24/01/14 10:09, Robert Haas wrote:
>>
>>> On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
>>> wrote:
>>>
On 24/01/14 09:49, Tom Lane wrote:
> 2. Wh
On 24/01/14 12:13, Jeff Janes wrote:
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
wrote:
On 24/01/14 09:49, Tom Lane wrot
Hi,
On 2014-01-23 16:04:10 -0500, Robert Haas wrote:
> Patch 0001:
>
> +errmsg("could not find free replication
> slot"),
>
> Suggest: all replication slots are in use
That sounds better indeed.
> + elog(ERROR, "cannot aquire a slot while another
On 2014-01-23 13:56:49 +0100, Simon Riggs wrote:
> IMHO we need to resolve the deadlock inherent in the
> disk-full/WALlock-up/checkpoint situation. My view is that can be
> solved in a similar way to the way the buffer pin deadlock was
> resolved for Hot Standby.
I don't think that approach works
On 2014-01-23 17:21:11 -0500, Tom Lane wrote:
> I wrote:
> > the idea that we might get many dozen such warnings on more-current
> > compilers is scarier, as that might well interfere with people's
> > ability to do development on, say, Windows. Could somebody check
> > whether MSVC for instance c
On 24/01/14 12:28, Mark Kirkwood wrote:
On 24/01/14 12:13, Jeff Janes wrote:
On Thu, Jan 23, 2014 at 1:41 PM, Mark Kirkwood <
mark.kirkw...@catalyst.net.nz> wrote:
On 24/01/14 10:16, Mark Kirkwood wrote:
On 24/01/14 10:09, Robert Haas wrote:
On Thu, Jan 23, 2014 at 4:03 PM, Mark Kirkwood
On 2014-01-24 12:49:57 +1300, Mark Kirkwood wrote:
> autovacuum_max_workers = 4
> autovacuum_naptime = 10s
> autovacuum_vacuum_scale_factor = 0.1
> autovacuum_analyze_scale_factor = 0.1
> autovacuum_vacuum_cost_delay = 0ms
>
> Stops excessive bloat - clearly autovacuum *is* able to vacuum pg_attri
On 2014-01-23 16:15:50 -0500, Tom Lane wrote:
> [ thinks... ] It's possible that what you saw is not the
> kick-out-autovacuum-entirely behavior, but the behavior added in commit
> bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it
> can't immediately get an exclusive buffer
Andres Freund writes:
> Do we have a real policy against indenting nested preprocessor
> statments? Just so I don't do those in future patches...
Indent 'em if you like, but pgindent will undo it. I ran the patch
through pgindent to see what it would do with those, and it left-justified
them, so
Andres Freund writes:
> On 2014-01-23 16:15:50 -0500, Tom Lane wrote:
>> [ thinks... ] It's possible that what you saw is not the
>> kick-out-autovacuum-entirely behavior, but the behavior added in commit
>> bbb6e559c, whereby vacuum (auto or regular) will skip over pages that it
>> can't immedia
On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
> I saw at most two pages skipped per vacuum, and
> usually none; so there's no way that a whole lot of tuples are going
> unvacuumed because of this. (I wonder though if we ought to add such
> counting as a permanent feature ...)
I generally think we
Andres Freund writes:
> On 2014-01-23 19:29:23 -0500, Tom Lane wrote:
>> I concur with the other reports that the main problem in this test case is
>> just that the default cost delay settings throttle autovacuum so hard that
>> it has no chance of keeping up. If I reduce autovacuum_vacuum_cost_d
On 01/24/2014 07:52 AM, Andres Freund wrote:
> On 2014-01-24 12:49:57 +1300, Mark Kirkwood wrote:
>> autovacuum_max_workers = 4
>> autovacuum_naptime = 10s
>> autovacuum_vacuum_scale_factor = 0.1
>> autovacuum_analyze_scale_factor = 0.1
>> autovacuum_vacuum_cost_delay = 0ms
>>
>> Stops excessive bl
On Thu, Jan 23, 2014 at 10:38 PM, Craig Ringer wrote:
>>>
>>> Stops excessive bloat - clearly autovacuum *is* able to vacuum pg_attribute
>>> in this case. Back to drawing board for a test case.
>>
>> Well, I think quite many people don't realize it might be necessary to
>> tune autovac on busy wo
On 23.1.2014 17:22, Heikki Linnakangas wrote:
> On 01/14/2014 05:35 PM, Alexander Korotkov wrote:
>> Attached version is rebased against last version of packed posting lists.
>
> Thanks!
>
> I think we're missing a trick with multi-key queries. We know that when
> multiple scan keys are used, the
On Wed, Jun 19, 2013 at 01:27:39PM -0700, Joshua D. Drake wrote:
>
> 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 passwo
On 01/24/2014 10:12 AM, Craig Ringer wrote:
> (Re-sending; I forgot to cc the list)
>
> On 01/20/2014 02:15 PM, Craig Ringer wrote:
>> On 01/20/2014 09:58 AM, Craig Ringer wrote:
>>> As it is I'm spending today reworking the RLS patch on top of the new
>>> approach to updatable security barrier vi
Claudio Freire escribió:
> If you ask me, I'd like autovac to know when not to run (or rather
> wait a bit, not forever), perhaps by checking load factors or some
> other tell-tale of an already-saturated I/O system.
We had a proposed design to tell autovac when not to run (or rather,
when to swi
Alvaro Herrera writes:
> Claudio Freire escribió:
>> If you ask me, I'd like autovac to know when not to run (or rather
>> wait a bit, not forever), perhaps by checking load factors or some
>> other tell-tale of an already-saturated I/O system.
> We had a proposed design to tell autovac when not
On 01/24/2014 11:32 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Claudio Freire escribió:
>>> If you ask me, I'd like autovac to know when not to run (or rather
>>> wait a bit, not forever), perhaps by checking load factors or some
>>> other tell-tale of an already-saturated I/O system.
>
>> W
On Mon, Jun 10, 2013 at 11:08:36AM +0200, marco atzeri wrote:
> Il 3/6/2013 11:46 PM, Andrew Dunstan ha scritto:
> >
> >Excellent. Will test it out soon.
> >
> >cheers
> >
> >andrew
> >
>
> Andrew,
> please find attached a full patch for cygwin relative to 9.3beta1 :
>
> - DLLTOLL/DLLWRAP are not
On Thu, 23 Jan 2014 13:19:37 +0200
Marti Raudsepp wrote:
> Resending to Tatsuo Ishii and Yugo Nagata, your email server was
> having problems yesterday:
Thanks for resending!
>
> This is the mail system at host sraigw2.sra.co.jp.
>
> : mail for srasce.sra.co.jp loops back to myself
> : mail f
1 - 100 of 114 matches
Mail list logo
