On 27 June 2011 03:31, Robert Haas wrote:
> On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed
> wrote:
>> Really? I would expect the reverse, namely that the not-nullness is
>> part of the PK constraint and dropping the PK *would* then start
>> allowing NULLs.
>
> Hmm, OK. I had assumed we were onl
On Fri, Jun 24, 2011 at 16:37, Alvaro Herrera
wrote:
> Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
>> While reviewing Peter Geoghegan's postmaster death patch, I noticed that
>> if you turn on silent_mode, the LINUX_OOM_ADJ code in fork_process()
>> runs when post
On Fri, Jun 17, 2011 at 8:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> Department of second thoughts: I think I see a problem.
>
> Um, yeah, so that doesn't really work any better than my idea.
>
> On further reflection, there's a problem at a higher level than this
> anyway. Even if we can g
On Mon, Jun 27, 2011 at 12:45:02AM +0200, Florian Pflug wrote:
> Updated patch attached. Do you think this is "Ready for Committer"?
Thanks. Yes; I have just marked it that way.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On Fri, Jun 17, 2011 at 6:22 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
>>> I believe that this is fundamentally unavoidable so long as we use
>>> SnapshotNow to read catalogs --- which is something we've talked about
>>> changing, but it will r
On 27.06.2011 10:23, Magnus Hagander wrote:
On Fri, Jun 24, 2011 at 16:37, Alvaro Herrera
wrote:
Excerpts from Heikki Linnakangas's message of vie jun 24 07:01:57 -0400 2011:
While reviewing Peter Geoghegan's postmaster death patch, I noticed that
if you turn on silent_mode, the LINUX_OOM_ADJ
Hi Heikki,
On Mon, 27 Jun 2011 at 12:10, Heikki Linnakangas wrote:
Max, you're the maintainer of the PostgreSQL SuSE RPMs, right?
my first name is Reinhard, but aside from that, you are right. ;)
Can you comment on the above?
I enabled it many years ago when (IIRC) it was needed in conjun
On Jun27, 2011, at 02:48 , Jeff Davis wrote:
> On Mon, 2011-06-27 at 00:56 +0200, Florian Pflug wrote:
>> Well, there actually *is* some precedence for that kind of top-down
>> (form a syntactic perspective) type inference. We *enforce* the cast
>> in
>> array[]::
>> and actually for a very simil
On Jun27, 2011, at 03:12 , Jeff Davis wrote:
> But I think you're right, it shouldn't be the responsibility of range
> types. Perhaps I should leave length() as some inlinable SQL functions
> like I mentioned, or perhaps I should remove them completely.
Does the current definition of length(range)
I've added information about testing on some real-life dataset to wiki page.
This dataset have a speciality: data is ordered inside it. In this case
tradeoff was inverse in comparison with expectations about "fast build"
algrorithm. Index built is longer but index quality is significantly better.
I
On 27.06.2011 13:45, Alexander Korotkov wrote:
I've added information about testing on some real-life dataset to wiki page.
This dataset have a speciality: data is ordered inside it. In this case
tradeoff was inverse in comparison with expectations about "fast build"
algrorithm. Index built is lo
On Fri, Jun 24, 2011 at 5:14 PM, Steve Singer wrote:
> A few things I noticed (that you might be aware of since you mentioned it
> needs cleanup)
>
> -The patch doesn't compile with non-ssl builds, the debug at the bottom of
> PQSendSome isn't in an #ifdef
>
> -I don't think your handling the ret
On Sat, Jun 25, 2011 at 6:24 AM, Jeff Davis wrote:
> On Fri, 2011-06-24 at 15:32 -0400, Robert Haas wrote:
>> On Sun, Jun 19, 2011 at 2:16 PM, Robert Haas wrote:
>> > New patch attached, with that one-line change.
>>
>> Jeff, are you planning to review this further? Do you think it's OK to
>> c
On 27.06.2011 13:45, Alexander Korotkov wrote:
I've added information about testing on some real-life dataset to wiki page.
This dataset have a speciality: data is ordered inside it. In this case
tradeoff was inverse in comparison with expectations about "fast build"
algrorithm. Index built is lo
On Mon, Jun 27, 2011 at 3:08 AM, Dean Rasheed wrote:
> On 27 June 2011 03:31, Robert Haas wrote:
>> On Sat, Jun 25, 2011 at 2:15 AM, Dean Rasheed
>> wrote:
>>> Really? I would expect the reverse, namely that the not-nullness is
>>> part of the PK constraint and dropping the PK *would* then star
On Fri, Jun 24, 2011 at 6:07 PM, Christian Ullrich wrote:
> When Magnus fixed and applied my SSPI-via-GSS patch in January, we forgot to
> fix to the documentation. Suggested patch attached; should I also put that
> four-liner into any CFs?
I have committed a slightly different wording change to
On Sat, Jun 25, 2011 at 8:26 PM, Greg Stark wrote:
> On Thu, Jun 23, 2011 at 4:42 PM, Robert Haas wrote:
>> ProcArrayLock looks like a tougher nut to crack - there's simply no
>> way, with the system we have right now, that you can take a snapshot
>> without locking the list of running processes.
On Mon, Jun 27, 2011 at 11:49 AM, Jonathan Corbet wrote:
> On Fri, 24 Jun 2011 13:42:04 -0400
> Robert Haas wrote:
>
>> As for annotating the commit messages, I think something like:
>>
>> Reporter: Sam Jones
>> Author: Beverly Smith
>> Author: Jim Davids
>> Reviewer: Fred Block
>> Reviewer: Paul
On Sat, Jun 25, 2011 at 9:01 PM, Greg Stark wrote:
> I think this commit was ill-advised:
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
>
> In a concurrent index build, the index is actually entered into the
> system catalogs in
On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
>> On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian wrote:
>
>> > You want the environment variable support removed?
>>
>> I don't. It's production usefulness is questio
On Fri, 24 Jun 2011 13:42:04 -0400
Robert Haas wrote:
> As for annotating the commit messages, I think something like:
>
> Reporter: Sam Jones
> Author: Beverly Smith
> Author: Jim Davids
> Reviewer: Fred Block
> Reviewer: Pauline Andrews
Can I just toss in one little note from the sidelines?
* Robert Haas wrote:
On Fri, Jun 24, 2011 at 6:07 PM, Christian Ullrich wrote:
When Magnus fixed and applied my SSPI-via-GSS patch in January, we forgot to
fix to the documentation. Suggested patch attached; should I also put that
four-liner into any CFs?
I have committed a slightly differe
On Mon, 2011-06-27 at 12:25 +0200, Florian Pflug wrote:
> Does the current definition of length(range), i.e.
> upper(range) - lower(range)
> deal correctly with open vs. closed ranges and unbounded ranges? I'm thinking
> that it probably doesn't - what would be the results of
> length('[0,1]'::
We have a couple of open items outstanding right now, but I'm
wondering if it's about time we should be thinking about a date for
beta3.
We tagged beta1 on April 27th, and beta2 on June 9th, so about six weeks apart.
But perhaps we shouldn't wait quite so long before putting out beta3?
--
Rober
On Mon, 2011-06-27 at 12:16 +0200, Florian Pflug wrote:
> I wouldn't take it that far. What I had in mind was to *only* support
> the case where the cast directly follows the function call, i.e. the case
> f(...)::type
OK, so instead of writing:
range(lower(range(1,2)),upper(range(1,2)))::int8ra
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
> Tom Lane wrote:
> > Darren Duncan writes:
> >> I believe that the best general solution here is for every ordered base
> >> type to
> >> just have a single total order, which is always used with that type in any
> >> generic order-sensit
On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas wrote:
> On Wed, Jun 22, 2011 at 12:51 PM, Alvaro Herrera
> wrote:
>> Excerpts from Robert Haas's message of mié jun 22 08:56:02 -0400 2011:
>>
>>> Another option might be to leave heap_openrv() and relation_openrv()
>>> alone and add a missing_ok argu
Robert Haas wrote:
> On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
> wrote:
> > Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
> >> On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian wrote:
> >
> >> > You want the environment variable support removed?
> >>
> >> I don't. ?It
On Mon, Jun 27, 2011 at 1:39 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
>> wrote:
>> > Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
>> >> On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian wrote:
>> >
>> >> > You want t
\Robert Haas wrote:
> On Mon, Jun 27, 2011 at 1:39 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Sun, Jun 26, 2011 at 10:33 PM, Alvaro Herrera
> >> wrote:
> >> > Excerpts from Robert Haas's message of vie jun 24 22:22:55 -0400 2011:
> >> >> On Fri, Jun 24, 2011 at 7:47 PM, Bruce Momjian
Hackers,
I'm curious about behavior such as this:
bric=# select generate_series('2011-05-31'::timestamp ,
'2012-04-01'::timestamp, '1 month');
generate_series
-
2011-05-31 00:00:00
2011-06-30 00:00:00
2011-07-30 00:00:00
2011-08-30 00:00:00
2011-09-30 00:00:00
201
On 6/27/11 9:45 AM, Robert Haas wrote:
> We have a couple of open items outstanding right now, but I'm
> wondering if it's about time we should be thinking about a date for
> beta3.
>
> We tagged beta1 on April 27th, and beta2 on June 9th, so about six weeks
> apart.
>
> But perhaps we shouldn't
On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian wrote:
> OK, fair enough. Should I apply my ports patch to Postgres 9.2?
I'm not sure which patch you are referring to.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
On Mon, Jun 27, 2011 at 1:51 PM, Josh Berkus wrote:
> On 6/27/11 9:45 AM, Robert Haas wrote:
>> We have a couple of open items outstanding right now, but I'm
>> wondering if it's about time we should be thinking about a date for
>> beta3.
>>
>> We tagged beta1 on April 27th, and beta2 on June 9th,
On 06/27/2011 10:49 AM, David E. Wheeler wrote:
Hackers,
I'm curious about behavior such as this:
bric=# select generate_series('2011-05-31'::timestamp ,
'2012-04-01'::timestamp, '1 month');
generate_series
-
2011-05-31 00:00:00
2011-06-30 00:00:00
2011-07-30 00:0
On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
> That's just how intervals that represent varying periods of time work. You
> would need to write your own. But a series of end-of-month dates is pretty
> easy:
> select generate_series('2011-06-01'::timestamp , '2012-04-01'::timestamp, '1
>
Robert Haas wrote:
> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian wrote:
> > OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
>
> I'm not sure which patch you are referring to.
This one which makes 50432 the default port.
--
Bruce Momjian http://momjian.us
Enterp
On Thu, Jun 23, 2011 at 9:22 AM, Robert Haas wrote:
> On Wed, Jun 22, 2011 at 10:23 PM, Robert Haas wrote:
>> Well, it seems I didn't put nearly enough thought into heap_update().
>> The fix for the immediate problem looks simple enough - all the code
>> has been refactored to use the new API, so
"David E. Wheeler" wrote:
> generate_series
> -
> 2011-05-31 00:00:00
> 2011-06-30 00:00:00
> 2011-07-31 00:00:00
> 2011-08-31 00:00:00
> 2011-09-30 00:00:00
> 2011-10-31 00:00:00
> 2011-11-30 00:00:00
> 2011-12-31 00:00:00
> 2012-01-31 00:00:00
> 2012-02-29 00:0
On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian wrote:
>> > OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
>>
>> I'm not sure which patch you are referring to.
>
> This one which makes 50432 the default
2011/6/27 Shigeru Hanada :
>> * It might be an option to extend attreloptions, instead of the new
>> attfdwoptions.
>> Although I didn't track the discussion when pg_foreign_table catalog
>> that provides
>> relation level fdw-options, was it impossible or unreasonable to extend
>> existing
>> des
On Jun 27, 2011, at 11:03 AM, Kevin Grittner wrote:
> It is precisely to support such fancy things that some products
> support a more abstract date type which allows 31 days in any month,
> and then normalizes to real dates as needed. The PostgreSQL
> developer community has generally not been r
All,
So we're supposedly 1/3 of the way through CF1. Here's the good news:
- Almost all patches have reviewers assigned.
- 9 patches have been committed
- 8 more are ready for a committer
- 9 have been returned
This means that 1/4 of the patches have been dealt with and another 1/8
should be de
Jeff Davis wrote:
On Sun, 2011-06-26 at 22:29 -0700, Darren Duncan wrote:
Tom Lane wrote:
Darren Duncan writes:
I believe that the best general solution here is for every ordered base type to
just have a single total order, which is always used with that type in any
generic order-sensitive o
Robert Haas wrote:
> On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian wrote:
> >> > OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
> >>
> >> I'm not sure which patch you are referring to.
> >
> > Thi
There are two outstanding patches for SSI which involve questions
about modularity. In particular, they involve calls to predicate
locking and conflict detection from executor source files rather
than AM source files (where most such calls exist).
(1) Dan submitted this patch:
http://archives
On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian wrote:
>> >> > OK, fair enough. ?Should I apply my ports patch to Postgres 9.2?
>> >>
>
Robert Haas wrote:
> On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
> >> > Robert Haas wrote:
> >> >> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian wrote:
> >> >> > OK, fair enough. ?Should I apply my ports
On Mon, Jun 27, 2011 at 6:34 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> The penalty function is called whenever a tuple is routed to the next level
> down, and the final tree has the same depth with and without the patch, so I
> would expect the number of penalty calls
On Mon, Jun 27, 2011 at 2:27 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian wrote:
>> > Robert Haas wrote:
>> >> On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
>> >> > Robert Haas wrote:
>> >> >> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momji
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian wrote:
> > > Robert Haas wrote:
> > >> On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
> > >> > Robert Haas wrote:
> > >> >> On Mon, Jun 27, 2011 at 1:49 PM, Bruce Momjian
> > >> >> wrote:
> > >>
On Mon, Jun 27, 2011 at 2:34 PM, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Robert Haas wrote:
>> > On Mon, Jun 27, 2011 at 2:19 PM, Bruce Momjian wrote:
>> > > Robert Haas wrote:
>> > >> On Mon, Jun 27, 2011 at 1:59 PM, Bruce Momjian wrote:
>> > >> > Robert Haas wrote:
>> > >> >> On Mon, Ju
On 06/27/2011 10:56 AM, David E. Wheeler wrote:
On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
That's just how intervals that represent varying periods of time work. You
would need to write your own. But a series of end-of-month dates is pretty easy:
select generate_series('2011-06-01'::t
On Jun 27, 2011, at 11:36 AM, Steve Crawford wrote:
> The query is marginally trickier. But the better calendaring apps give a
> variety of options when selecting "repeat": A user who selects June 30, 2011
> and wants a monthly repeat might want:
>
> 30th of every month - skip months without a
On Sat, Jun 25, 2011 at 6:29 PM, Jeff Davis wrote:
> Different ranges over the same subtype make sense when using different
> total orders for the subtype. This is most apparent with text collation,
> but makes sense (at least mathematically, if not practically) for any
> subtype.
>
> For instance
On Mon, Jun 27, 2011 at 01:28:30PM -0400, Robert Haas wrote:
> On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas wrote:
> > I agree with you. ?If we had a whole pile of options it might be worth
> > having heap_openrv() and heap_openrv_extended() so as not to
> > complicate the simple case, but since t
On Mon, Jun 27, 2011 at 1:38 PM, David E. Wheeler wrote:
>
> Yeah, which is why I said it was subject to interpretation. Of course
> there's no way to tell generate_series() which to use, which is what I
> figured.
>
generate_series() is doing exactly what it was designed to do, the
imprecision r
Yeah, which is why I said it was subject to interpretation. Of course there's
no way to tell generate_series() which to use, which is what I figured.
Fortunately PostgreSQL uses the same interpretation for '1 month' when
used in generate_series that it does everywhere else - to do otherwise
On Mon, Jun 27, 2011 at 1:49 PM, David E. Wheeler wrote:
> Hackers,
>
> I'm curious about behavior such as this:
>
> bric=# select generate_series('2011-05-31'::timestamp ,
> '2012-04-01'::timestamp, '1 month');
> generate_series
> -
> 2011-05-31 00:00:00
> 2011-06-30 00:0
On Mon, Jun 27, 2011 at 2:36 PM, Steve Crawford
wrote:
> On 06/27/2011 10:56 AM, David E. Wheeler wrote:
>>
>> On Jun 27, 2011, at 10:54 AM, Steve Crawford wrote:
>>
>>> That's just how intervals that represent varying periods of time work.
>>> You would need to write your own. But a series of end
On Wed, Jun 15, 2011 at 1:03 AM, Noah Misch wrote:
> [patch to avoid index rebuilds]
With respect to the documentation hunks, it seems to me that the first
hunk might be made clearer by leaving the paragraph of which it is a
part as-is, and adding another paragraph afterwards beginning with the
w
On Mon, Jun 27, 2011 at 2:59 PM, Noah Misch wrote:
> On Mon, Jun 27, 2011 at 01:28:30PM -0400, Robert Haas wrote:
>> On Wed, Jun 22, 2011 at 1:36 PM, Robert Haas wrote:
>> > I agree with you. ?If we had a whole pile of options it might be worth
>> > having heap_openrv() and heap_openrv_extended()
On Jun 27, 2011, at 12:36 PM, Christopher Browne wrote:
> I wrote something on this on pgsql-general about 5 years ago that
> still seems pretty relevant.
>
> http://archives.postgresql.org/pgsql-general/2006-02/msg00159.php
iwantsandy.com (now defunct) originally had a solution like this. Howev
The attached patch is rebased one towards the latest tree, using
relation_openrv_extended().
Although it is not a matter in this patch itself, I found a problem on
the upcoming patch
that consolidate routines associated with DropStmt.
Existing RemoveRelations() acquires a lock on the table owning
Hi guys,
I have added the '-n' option to pg_archivecleanup which performs a
dry-run and outputs the names of the files to be removed to stdout
(making possible to pass the list via pipe to another process). Please
find attached the small patch.
Thanks,
Gabriele
--
Gabriele Bartolini - 2
On mån, 2011-06-27 at 14:34 -0400, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Robert Haas wrote:
> > > It's easier to read the patches if you do separate changes in separate
> > > patches. Anyway, I'm a bit nervous about this hunk:
> > >
> > > + if (old_cluster.port == DEF_PG
Ive been holding off because its marked as Waiting on Author, am now
thinking thats a mistake. =)
It links to this patch:
http://archives.postgresql.org/message-id/20110215135131.gx4...@tamriel.snowman.net
Which is older than the latest patch in that thread posted by Robert:
http://archives.postg
On Fri, Jun 17, 2011 at 05:59:31AM -0700, David Fetter wrote:
> On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
> > > Here's an example of a non-trivial mapping.
> > >
> > > Database type:
> > > MySQL
> > > Foreign data type:
> > > datetime
> > > PostgreSQL data type:
>
On Mon, Jun 27, 2011 at 4:40 PM, Kohei KaiGai wrote:
> The attached patch is rebased one towards the latest tree, using
> relation_openrv_extended().
Committed.
> Although it is not a matter in this patch itself, I found a problem on
> the upcoming patch
> that consolidate routines associated wi
On 18 June 2011 09:49, Brendan Jurd wrote:
> Hi Fabien,
>
> I'm taking a look at this patch for the commitfest. On first reading
> of the patch, it looked pretty sensible to me, but I had some trouble
> applying it to HEAD:
>
> error: patch failed: doc/src/sgml/ref/create_cast.sgml:20
> error: do
On Mon, Jun 27, 2011 at 03:45:43PM -0400, Robert Haas wrote:
> On Wed, Jun 15, 2011 at 1:03 AM, Noah Misch wrote:
> > [patch to avoid index rebuilds]
>
> With respect to the documentation hunks, it seems to me that the first
> hunk might be made clearer by leaving the paragraph of which it is a
>
On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
> Couldn't we also do neither of these things? I mean, presumably
> '[1,10]'::int8range had better work.
I think that if we combine this idea with Florian's "PAIR" suggestion
here:
http://archives.postgresql.org/message-id/ad4fc75d-db99-48ed-9
Hi,
I've been tracing the data structure in the query plan process for a
while. But then I found the data structure manipulation is really so
confusing. Could some guy tell me where could I find any guide on how to
figure out the process and data structure usage? Is there any good resource
hel
HuangQi writes:
> Hi,
> I've been tracing the data structure in the query plan process for a
> while. But then I found the data structure manipulation is really so
> confusing.
> Could some guy tell me where could I find any guide on how to figure out the
> process and data structure usa
Hello!~
Now i encounter a function call problem in PostgreSQL's psql module!
The situation is as follow:
In ./src/bin/psql/common.c, I want to call the function
pqCatenateResultError().
Function pqCatenateResultError() is declared in
./src/interfaces/libpq
> Considering everything that has been discussed on this thread so far.
>
> Do you still think your patch is the best way to accomplish base backups
> from standby servers?
> If not what changes do you think should be made?
I reconsider the way to not use pg_stop_backup().
Process of online bas
On 27.06.2011 21:23, Kevin Grittner wrote:
There are two outstanding patches for SSI which involve questions
about modularity. In particular, they involve calls to predicate
locking and conflict detection from executor source files rather
than AM source files (where most such calls exist).
(1)
77 matches
Mail list logo
