2011/1/17 Itagaki Takahiro :
> On Mon, Jan 17, 2011 at 16:13, Pavel Stehule wrote:
If we always generate same toasted byte sequences from the same raw
values, we don't need to detoast at all to compare the contents.
Is it possible or not?
>>>
>>> For bytea, it seems it would be poss
On mån, 2011-01-17 at 07:35 +0100, Magnus Hagander wrote:
> For text, I think locales may make that impossible. Aren't there
> locale rules where two different characters can "behave the same" when
> comparing them? I know in Swedish at least w and v behave the same
> when sorting (but not when com
On Mon, Jan 17, 2011 at 16:13, Pavel Stehule wrote:
>>> If we always generate same toasted byte sequences from the same raw
>>> values, we don't need to detoast at all to compare the contents.
>>> Is it possible or not?
>>
>> For bytea, it seems it would be possible.
>>
>> For text, I think locale
While I haven't tried this patch, I tried to break the version 11 of the
patch (some of the work was against earlier versions). In total I have
used a full work day just trying to break things, but haven't been able
to find anything after version 8. I can verify that the partial index
issue is
On Sun, Jan 16, 2011 at 06:20, Marko Tiikkaja
wrote:
> Here's the latest version of the patch. It now uses the API proposed by
> Simon, but still lacks documentation changes, which I'm going to send
> tomorrow.
Here is a short review for Transaction scoped advisory locks:
https://commitfest.post
2011/1/17 Magnus Hagander :
> On Mon, Jan 17, 2011 at 06:51, Itagaki Takahiro
> wrote:
>> On Mon, Jan 17, 2011 at 04:05, Andy Colson wrote:
>>> This is a review of:
>>> https://commitfest.postgresql.org/action/patch_view?id=468
>>>
>>> Purpose:
>>>
>>> Equal and not-equal _may_ be quickl
On Mon, Jan 17, 2011 at 03:06, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote:
>> Currently, replication connections *always* logs something like:
>> LOG: replication connection authorized: user=mha host=[local]
>>
>> There's no way to turn that off.
>>
>> I can't fi
On Mon, Jan 17, 2011 at 03:32, Tatsuo Ishii wrote:
>>> Good point. I have been always wondering why we can't use exiting WAL
>>> transporting infrastructure for sending/receiving WAL archive
>>> segments in streaming replication.
>>> If my memory serves, Fujii has already proposed such an idea but
On Mon, Jan 17, 2011 at 02:53, Fujii Masao wrote:
> On Sun, Jan 16, 2011 at 11:52 PM, Magnus Hagander wrote:
>> So I'm back to my original question which is, how much work would this
>> be? I don't know my way around that part so I can't estimate, and
>> what's there so far is certainly a lot bet
On Mon, Jan 17, 2011 at 07:44, Heikki Linnakangas
wrote:
> On 16.01.2011 22:55, Josh Berkus wrote:
>>
>>> In 9.0, we specifically require using "replication" as database name
>>> to start a replication session. In 9.1 we will have the REPLICATION
>>> attribute to a role - should we change it so th
On 16.01.2011 22:55, Josh Berkus wrote:
In 9.0, we specifically require using "replication" as database name
to start a replication session. In 9.1 we will have the REPLICATION
attribute to a role - should we change it so that "all" in database
includes replication connections? It certainly goe
On Jan 14, 2011, at 11:37 PM, David E. Wheeler wrote:
>> Hard to comment on any of this without a concrete example (including
>> data) to look at. Given the bugs we've recently found in the picksplit
>> algorithms for other contrib modules, I wouldn't be too surprised if the
>> sucky GiST perform
On Mon, Jan 17, 2011 at 05:22, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 10:40 PM, Josh Kupershmidt wrote:
>> On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas wrote:
>>> On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander
>>> wrote:
> I do not like the use of parentheses in the usage descripti
On Mon, Jan 17, 2011 at 06:51, Itagaki Takahiro
wrote:
> On Mon, Jan 17, 2011 at 04:05, Andy Colson wrote:
>> This is a review of:
>> https://commitfest.postgresql.org/action/patch_view?id=468
>>
>> Purpose:
>>
>> Equal and not-equal _may_ be quickly determined if their lengths are
>> di
(2011/01/17 14:51), Itagaki Takahiro wrote:
> On Mon, Jan 17, 2011 at 04:05, Andy Colson wrote:
>> This is a review of:
>> https://commitfest.postgresql.org/action/patch_view?id=468
>>
>> Purpose:
>>
>> Equal and not-equal _may_ be quickly determined if their lengths are
>> different. T
On Mon, Jan 17, 2011 at 04:05, Andy Colson wrote:
> This is a review of:
> https://commitfest.postgresql.org/action/patch_view?id=468
>
> Purpose:
>
> Equal and not-equal _may_ be quickly determined if their lengths are
> different. This _may_ be a huge speed up if we don't have to deto
On 17/01/11 17:27, Robert Haas wrote:
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura wrote:
Dear hackers :) Could you look at this thread from General.
---
I say the backend if you have one "row type" output result treats it as the
full output result, it's really bad if you use STRUCT types (in your
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura wrote:
> Dear hackers :) Could you look at this thread from General.
> ---
> I say the backend if you have one "row type" output result treats it as the
> full output result, it's really bad if you use STRUCT types (in your example
> you see few columns, b
On Sun, Jan 16, 2011 at 10:40 PM, Josh Kupershmidt wrote:
> On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas wrote:
>> On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote:
I do not like the use of parentheses in the usage description "list
(procedural) languages". Why not have it simply
On Sun, Jan 16, 2011 at 9:32 AM, Tom Lane wrote:
> Josh Berkus writes:
>> I think we can be more specific on that last sentence; is there even any
>> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
>
> IIRC there's a forced fsync at WAL segment switch, so no.
However oth
On 01/16/2011 07:14 PM, Alex Hunsaker wrote:
On Sat, Jan 15, 2011 at 14:20, Andy Colson wrote:
This is a review of "plperl encoding issues"
https://commitfest.postgresql.org/action/patch_view?id=452
Thanks for taking the time to review!
[...]
The Patch:
==
Applies clean to git h
On Sat, Jan 15, 2011 at 2:34 PM, Josh Berkus wrote:
> On 1/14/11 10:51 PM, Greg Smith wrote:
>>
>> ! Since the data is written out to disk at every transaction
>> commit,
>> ! the setting many only need to be be large enough to hold the
>> amount
>> ! of WAL data generated
On Sun, Jan 16, 2011 at 8:52 PM, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote:
>>> I do not like the use of parentheses in the usage description "list
>>> (procedural) languages". Why not have it simply as "list procedural
>>> languages"?
>>
>> Because it lists non-
On Sun, Jan 16, 2011 at 10:13 PM, Greg Smith wrote:
> I have finished a first run of benchmarking the current 9.1 code at various
> sizes. See http://www.2ndquadrant.us/pgbench-results/index.htm for many
> details. The interesting stuff is in Test Set 3, near the bottom. That's
> the first one
On Sat, Jan 15, 2011 at 8:26 PM, Andreas Karlsson wrote:
> Hi Josh,
>
> Here is my review of this patch for the commitfest.
>
> Review of https://commitfest.postgresql.org/action/patch_view?id=439
Thanks a lot for the review!
> Contents and Purpose
>
>
> This patch adds the
I have finished a first run of benchmarking the current 9.1 code at
various sizes. See http://www.2ndquadrant.us/pgbench-results/index.htm
for many details. The interesting stuff is in Test Set 3, near the
bottom. That's the first one that includes buffer_backend_fsync data.
This iall on ex
On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas wrote:
> On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
> wrote:
>> Magnus Hagander writes:
>>> Is "walreceiver" something that "the average DBA" is going to realize
>>> what it is? Perhaps go for something like "replication slave"?
>>
>> I think
On Mon, Jan 17, 2011 at 11:32 AM, Tatsuo Ishii wrote:
>>> Good point. I have been always wondering why we can't use exiting WAL
>>> transporting infrastructure for sending/receiving WAL archive
>>> segments in streaming replication.
>>> If my memory serves, Fujii has already proposed such an idea
>> Good point. I have been always wondering why we can't use exiting WAL
>> transporting infrastructure for sending/receiving WAL archive
>> segments in streaming replication.
>> If my memory serves, Fujii has already proposed such an idea but was
>> rejected for some reason I don't understand.
>
2011/1/13 Pavel Golub :
> Hello, Pgsql-hackers.
>
> I'm getting such warnings:
>
> pg_dump.c: In function 'dumpSequence':
> pg_dump.c:11449:2: warning: unknown conversion type character 'l' in format
> pg_dump.c:11449:2: warning: too many arguments for format
> pg_dump.c:11450:2: warning: unknown c
On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
wrote:
> Magnus Hagander writes:
>> Is "walreceiver" something that "the average DBA" is going to realize
>> what it is? Perhaps go for something like "replication slave"?
>
> I think walreceiver is very good here, and the user is already
> confro
On Sat, Jan 15, 2011 at 8:33 PM, Tatsuo Ishii wrote:
>> When do the standby launch its walreceiver? It would be extra-nice for
>> the base backup tool to optionally continue streaming WALs until the
>> standby starts doing it itself, so that wal_keep_segments is really
>> deprecated. No idea how
On Sun, Jan 16, 2011 at 9:19 AM, Magnus Hagander wrote:
> Currently, replication connections *always* logs something like:
> LOG: replication connection authorized: user=mha host=[local]
>
> There's no way to turn that off.
>
> I can't find the reasoning behind this - why is this one not
> contro
On Sun, Jan 16, 2011 at 11:52 PM, Magnus Hagander wrote:
> So I'm back to my original question which is, how much work would this
> be? I don't know my way around that part so I can't estimate, and
> what's there so far is certainly a lot better than nothing, but if
> it's not a huge amount of wor
On Sun, Jan 16, 2011 at 7:04 AM, Magnus Hagander wrote:
>> I do not like the use of parentheses in the usage description "list
>> (procedural) languages". Why not have it simply as "list procedural
>> languages"?
>
> Because it lists non-procedural langauges as well? (I didn't check it,
> that's j
On Sun, Jan 16, 2011 at 8:36 PM, Simon Riggs wrote:
> I agree with you, but if we want it *this* release, on top of all the
> other features we have queued, then I suggest we compromise. If you hold
> out for more feature, you may get less.
>
> Statement timeout = 2 * (100ms + autovacuum_vacuum_co
On Sun, Jan 16, 2011 at 5:34 PM, Steve Singer wrote:
> I'm marking this as returned with feedback pending your answer on the
> possible memory leak above but I think the patch is very close to being
> ready.
Please use "Waiting on Author" if the patch is to be considered
further for this CommitFe
On Sun, Jan 16, 2011 at 8:41 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
\>> I think you may be confused about what the patch does - currently,
>> pages with hint bit changes are considered dirty, period.
>> Therefore, they are written whenever any other dirty page would be
>> written: by the
On Sun, Jan 16, 2011 at 7:32 PM, Jeff Janes wrote:
> But since you already wrote a patch to do the whole thing, I figured
> I'd time it.
Thanks!
> I arranged to test an instrumented version of your patch under large
> shared_buffers of 4GB, conditions that would maximize the opportunity
> for it
Robert Haas wrote:
> I think you may be confused about what the patch does - currently,
> pages with hint bit changes are considered dirty, period.
> Therefore, they are written whenever any other dirty page would be
> written: by the background writer cleaning scan, at checkpoints,
> and when a
On Sun, 2011-01-16 at 12:50 -0800, Josh Berkus wrote:
> On 1/16/11 11:19 AM, Simon Riggs wrote:
> > I would prefer it if we had a settable lock timeout, as suggested many
> > moons ago. When that was discussed before it was said there was no
> > difference between a statement timeout and a lock tim
On Sun, Jan 16, 2011 at 7:34 AM, Josh Berkus wrote:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
> Certainly there have been no test results to show any.
If the workload generates 16MB or mor
On Sat, Jan 15, 2011 at 14:20, Andy Colson wrote:
>
> This is a review of "plperl encoding issues"
>
> https://commitfest.postgresql.org/action/patch_view?id=452
Thanks for taking the time to review!
[...]
>
> The Patch:
> ==
> Applies clean to git head as of January 15 2011. PG built
On Sun, 2011-01-16 at 16:30 -0800, Ron Mayer wrote:
> Tom Lane wrote:
> > Simon Riggs writes:
> >> It's a major undertaking trying to write software that runs against
> >> PostgreSQL for more than one release. We should be making that easier,
> >> not harder.
> >
> > None of the proposals would m
On Sun, Jan 16, 2011 at 1:52 AM, Greg Smith wrote:
> Fujii Masao wrote:
>>
>> +int XLOGbuffersMin = 8;
>>
>> XLOGbuffersMin is a fixed value. I think that defining it as a macro
>> rather than a variable seems better.
>>
>> + if (XLOGbuffers > 2048)
>> +
Tom Lane wrote:
> Simon Riggs writes:
>> It's a major undertaking trying to write software that runs against
>> PostgreSQL for more than one release. We should be making that easier,
>> not harder.
>
> None of the proposals would make it impossible to write a LOCK statement
> that works on all av
On Tue, Jan 11, 2011 at 5:27 PM, Robert Haas wrote:
> On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith wrote:
>> One of the ideas Simon and I had been considering at one point was adding
>> some better de-duplication logic to the fsync absorb code, which I'm
>> reminded by the pattern here might be he
On Sun, Jan 16, 2011 at 6:58 PM, Jeff Janes wrote:
> None of the issues I raise above are severe. Does that mean I should
> change the status to "ready for committer"?
Sounds right to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via p
This is a review for the patch sent as
https://commitfest.postgresql.org/action/patch_view?id=456
== Submission ==
The patch applied cleanly atop of plpython refactor patches. The
format is git diff (though refactor patches is format-patch). I did
patch -p1.
It includes adequate amount of test. I
On Mon, Jan 10, 2011 at 8:27 AM, Kevin Grittner
wrote:
> Attached is a rebased roll-up of the 3 and 3a patches from last month.
>
> -Kevin
Hi Kevin,
A review:
The main motivation for the patch is to allow future optimization of
read-only transactions, by preventing them from changing back to re
2011/1/16 Noah Misch :
> On Sun, Jan 16, 2011 at 10:07:13PM +0100, Pavel Stehule wrote:
>> I think, so we can have a function or macro that compare a varlena
>> sizes. Some like
>>
>> Datum texteq(..)
>> {
>> if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
>> PG_RETURN
On Sun, Jan 16, 2011 at 5:37 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> a quick-and-dirty attempt to limit the amount of I/O caused by hint
>> bits. I'm still very interested in knowing what people think about
>> that.
>
> I found the elimination of the response-time spike promising. I
>
On Sun, Jan 16, 2011 at 10:07:13PM +0100, Pavel Stehule wrote:
> I think, so we can have a function or macro that compare a varlena
> sizes. Some like
>
> Datum texteq(..)
> {
> if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
> PG_RETURN_FALSE();
>
> ... actual
On Sun, Jan 16, 2011 at 00:34, Josh Berkus wrote:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
> Certainly there have been no test results to show any.
I don't know if it's applicable to real
Robert Haas wrote:
> a quick-and-dirty attempt to limit the amount of I/O caused by hint
> bits. I'm still very interested in knowing what people think about
> that.
I found the elimination of the response-time spike promising. I
don't think I've seen enough data yet to feel comfortable endor
I've taken a look at this version of the patch.
Submission Review
This version of the patch applies cleanly to master. It matches your git
repo and includes test + docs.
Usability Review
---
The command syntax now matches what was discussed during the last cf.
T
On Sun, Jan 16, 2011 at 01:05:11PM -0600, Andy Colson wrote:
> This is a review of:
> https://commitfest.postgresql.org/action/patch_view?id=468
Thanks!
> I created myself a more real world test, with a table with indexes and id's
> and a large toasted field.
> This will make about 600 records
On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
> I am sending a updated version with little bit more comments. But I am
> sure, so somebody with good English have to edit my comments.
> Minimally I hope, so your questions will be answered.
Thanks. I edited the comments and white s
On Sun, Jan 16, 2011 at 12:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch wrote:
>>> Do you value test coverage so little?
>
>> If you're asking whether I think real-world usability is more
>> important than test coverage, then yes.
>
> Quite honestl
On Sat, Jan 15, 2011 at 6:28 PM, Josh Berkus wrote:
>> If the problem is that all the freezing happens at once, then ISTM the
>> solution is to add a random factor. Say, when a tuple just passes the
>> lower threshold it has a 1% chance of being frozen. The chance grows
>> until it is 100% as it r
On Sun, Jan 16, 2011 at 2:30 PM, Andy Colson wrote:
> I reviewed a couple patched, and I added my review to the commitfest page.
>
> If I find a problem, its obvious I should mark the patch as "returned with
> feedback".
Only if it's got sufficiently serious flaws that getting it committed
during
On Sun, Jan 16, 2011 at 12:07:44PM -0500, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch wrote:
> >> Do you value test coverage so little?
>
> > If you're asking whether I think real-world usability is more
> > important than test coverage, then yes.
>
>
Em 16-01-2011 16:30, Andy Colson escreveu:
I reviewed a couple patched, and I added my review to the commitfest page.
If I find a problem, its obvious I should mark the patch as "returned
with feedback".
But what if I'm happy with it? I'm not a hacker so cannot do C code
review, should I leave
Hello
I looked on this patch too.
It's good idea.
I think, so we can have a function or macro that compare a varlena
sizes. Some like
Datum texteq(..)
{
if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
PG_RETURN_FALSE();
... actual code ..
}
Regards
Pavel St
Tom Lane writes:
> Another possibility is to disallow just the single case
> LOCK tablename NOWAIT
> ie, you can write NOWAIT if you include *either* the object type
> or the IN...MODE clause. This is not too hard as far as the grammar
> is concerned, but I'm not exactly sure how to documen
>> I suggest instead either "superuser" or "replication" permissions.
>
> That's another idea.
Oh, wait. I take that back ... we're trying to encourage users NOT to
use the "replication" user as a login, yes?
--
-- Josh Berkus
On Sun, Jan 16, 2011 at 21:51, Josh Berkus wrote:
>
>> I suggest pg_stat_replication do just like pg_stat_activity, which is
>> return NULL in most fields if the user isn't
>> (superuser||same_user_as_that_session).
>
> What session would that be, exactly?
The user doing the query to pg_stat_repl
> In 9.0, we specifically require using "replication" as database name
> to start a replication session. In 9.1 we will have the REPLICATION
> attribute to a role - should we change it so that "all" in database
> includes replication connections? It certainly goes in the "principle
> of least surp
Magnus Hagander writes:
> Is "walreceiver" something that "the average DBA" is going to realize
> what it is? Perhaps go for something like "replication slave"?
I think walreceiver is very good here, and the user is already
confronted to such phrasing.
http://www.postgresql.org/docs/9.0/inter
> I suggest pg_stat_replication do just like pg_stat_activity, which is
> return NULL in most fields if the user isn't
> (superuser||same_user_as_that_session).
What session would that be, exactly?
I suggest instead either "superuser" or "replication" permissions.
--
On 1/16/11 11:19 AM, Simon Riggs wrote:
> I would prefer it if we had a settable lock timeout, as suggested many
> moons ago. When that was discussed before it was said there was no
> difference between a statement timeout and a lock timeout, but I think
> there clearly is, this case being just one
On 1/15/11 4:30 PM, Bruce Momjian wrote:
> Josh Berkus wrote:
>> Last I remember, we were going to add this as an option. But I don't
>> see a patch in the queue. Am I missing it? Was I supposed to write it?
>
> I don't know, but let me add that I am confused how this would look to
> users. In
>> Select typoutput::oid from pg_type limit 1;
> Also, you *can* go back the other way. It's very common to write
>
> Select * from pg_proc where oid = 'boolout'::regproc
>
> rather than looking up the OID first.
> see "Object Identifier Types" in the manual.
Many thanks
I reviewed a couple patched, and I added my review to the commitfest page.
If I find a problem, its obvious I should mark the patch as "returned with
feedback".
But what if I'm happy with it? I'm not a hacker so cannot do C code review, should I
leave it alone? Mark it as "ready for committ
Andreas Karlsson writes:
> On Sat, 2011-01-15 at 10:36 -0500, Tom Lane wrote:
>> But I can read the handwriting on the wall: if I want this done right,
>> I'm going to have to do it myself.
> Do I understand you correctly if I interpret what you would like to see
> is the same format used now in
On Sun, 2011-01-16 at 13:08 -0500, Greg Smith wrote:
> Simon Riggs wrote:
> > I'm fairly confused by this thread.
> >
>
> That's becuase you think it has something to do with cancellation, which
> it doesn't. The original report here noted a real problem but got the
> theorized cause wrong.
Magnus Hagander writes:
> However, it's not quite that simple. "just adding a fork()" doesn't
> work on all our platforms, and you need to deal with feedback and such
> between them as well.
I'd think client-side, we have an existing implementation with the
parallel pg_restore option. Don't know
This is a review of:
https://commitfest.postgresql.org/action/patch_view?id=468
Purpose:
Equal and not-equal _may_ be quickly determined if their lengths are different.
This _may_ be a huge speed up if we dont have to detoat.
The Patch:
==
I was able to read and understand t
Greg Smith writes:
> Tom Lane wrote:
>> No, I don't believe we should be messing with the semantics of
>> try_relation_open. It is what it is.
> With only four pretty simple callers to the thing, and two of them
> needing the alternate behavior, it seemed a reasonable place to modify
> to me.
Tom Lane wrote:
No, I don't believe we should be messing with the semantics of
try_relation_open. It is what it is.
With only four pretty simple callers to the thing, and two of them
needing the alternate behavior, it seemed a reasonable place to modify
to me. I thought the "nowait" bool
On Sun, Jan 16, 2011 at 19:21, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>> If you're doing a regular base backup, that's *not* for replication,
>> you might want them in files.
>
> +1
>
> So, is that pg_restore -l idea feasible with your current tar format? I
> guess that would translat
Magnus Hagander writes:
> If you're doing a regular base backup, that's *not* for replication,
> you might want them in files.
+1
So, is that pg_restore -l idea feasible with your current tar format? I
guess that would translate to pg_basebackup -l |.tar.
Regards,
--
Dimitri Fontaine
http://2
Greg Smith writes:
> Simon Riggs wrote:
>> I'm fairly confused by this thread.
> That's becuase you think it has something to do with cancellation, which
> it doesn't. The original report here noted a real problem but got the
> theorized cause wrong.
I think that cancellations are also a pote
On Sun, Jan 16, 2011 at 18:45, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>>> What if you start a concurrent process that begins streaming the WAL
>>> segments just before you start the backup, and you stop it after having
>>> stopped the backup. I would think that then, the local receive
Simon Riggs wrote:
I'm fairly confused by this thread.
That's becuase you think it has something to do with cancellation, which
it doesn't. The original report here noted a real problem but got the
theorized cause wrong. It turns out the code that acquires a lock when
autovacuum decides
Simon Riggs writes:
> I'm fairly confused by this thread.
> We *do* emit a message when we cancel an autovacuum task. We went to a
> lot of trouble to do that. The message is DEBUG2, and says
> "sending cancel to blocking autovacuum pid =".
That doesn't necessarily match one-to-one with actual c
On Sun, Jan 16, 2011 at 19:03, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sun, Jan 16, 2011 at 18:59, Tom Lane wrote:
>>> Just stick with the OID. There's no reason that I can see to have
>>> "friendly" names for these tarfiles --- in most cases, the DBA will
>>> never even deal with them,
Magnus Hagander writes:
> On Sun, Jan 16, 2011 at 18:59, Tom Lane wrote:
>> Just stick with the OID. There's no reason that I can see to have
>> "friendly" names for these tarfiles --- in most cases, the DBA will
>> never even deal with them, no?
> No, this is the output mode where the DBA choo
On Sun, Jan 16, 2011 at 18:59, Tom Lane wrote:
> Magnus Hagander writes:
>> Well, we'd try to name the file for that "-/foo/bar.tar", which I
>> guess would break badly, yes.
>
>> I guess we could normalize the tablespace name into [a-zA-Z0-9] or so,
>> which would still be useful for the majorit
Magnus Hagander writes:
> Well, we'd try to name the file for that "-/foo/bar.tar", which I
> guess would break badly, yes.
> I guess we could normalize the tablespace name into [a-zA-Z0-9] or so,
> which would still be useful for the majority of cases, I think?
Just stick with the OID. There's
Magnus Hagander writes:
> On Sun, Jan 16, 2011 at 18:18, Tom Lane wrote:
>> No. Don't even think of going there --- we got rid of user-accessible
>> names in the filesystem years ago and we're not going back. Consider
>> CREATE TABLESPACE "/foo/bar" LOCATION '/foo/bar';
>
> Well, we'd tr
Hello
2011/1/15 Noah Misch :
> Hello Pavel,
>
> I'm reviewing this patch for CommitFest 2011-01.
>
Thank you very much,
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so your questions will be
Magnus Hagander writes:
>> What if you start a concurrent process that begins streaming the WAL
>> segments just before you start the backup, and you stop it after having
>> stopped the backup. I would think that then, the local received files
>> would be complete. We would only need a program a
On 01/15/2011 07:41 PM, Andrew Dunstan wrote:
On 01/15/2011 12:29 PM, Andrew Dunstan wrote:
I've been waiting for the latest FDW patches as patiently as I can,
and I've been reviewing them this morning, in particular the file_fdw
patch and how it interacts with the newly exposed COPY API.
Josh Berkus writes:
> I think we can be more specific on that last sentence; is there even any
> *theoretical* benefit to settings above 16MB, the size of a WAL segment?
IIRC there's a forced fsync at WAL segment switch, so no.
regards, tom lane
--
Sent via pgsql-hacker
Robert Haas writes:
> Do we wish to officially document LOCK without TABLE as a good idea to
> start avoiding, in case we decide to do something about that in the
> future?
I'm still not for fixing the ambiguity that way. TABLE is an optional
noise word in other contexts, notably GRANT/REVOKE wh
On Sun, Jan 16, 2011 at 18:18, Tom Lane wrote:
> Magnus Hagander writes:
>>> + * The file will be named base.tar[.gz] if it's for the main data directory
>>> + * or .tar[.gz] if it's for another tablespace.
>>>
>>> Well we have UNIQUE, btree (spcname), so maybe we can use that here?
>
>> We could
On Sun, 2011-01-16 at 11:47 -0500, Tom Lane wrote:
> Greg Smith writes:
> > try_relation_open calls LockRelationOid, which blocks. There is also a
> > ConditionalLockRelationOid, which does the same basic thing except it
> > exits immediately, with a false return code, if it can't acquire the
Magnus Hagander writes:
>> + * The file will be named base.tar[.gz] if it's for the main data directory
>> + * or .tar[.gz] if it's for another tablespace.
>>
>> Well we have UNIQUE, btree (spcname), so maybe we can use that here?
> We could, but that would make it more likely to run into encodi
On Sun, Jan 16, 2011 at 17:29, Tom Lane wrote:
> Magnus Hagander writes:
>> Since we now show the application name in pg_stat_replication, I think
>> it would make sense to have the walreceiver set
>> fallback_application_name on the connection string, like so:
>
> Seems reasonable, but "postgres
1 - 100 of 117 matches
Mail list logo
