On Fri, Jan 14, 2011 at 4:13 AM, Magnus Hagander wrote:
>> While walsender is sending a base backup, WalSndWakeup should
>> not send the signal to that walsender?
>
> True, it's not necessary. How bad does it actually hurt things though?
> Given that the walsender running the backup isn't actually
On Fri, Jan 14, 2011 at 14:20, Shigeru HANADA wrote:
> After copying statisticsof pgbench_xxx tables into csv_xxx tables,
> planner generates same plans as for local tables, but costs of
> ForeignScan nodes are little lower than them of SeqScan nodes.
> Forced Nested Loop uses Materialize node as
On Fri, 14 Jan 2011 13:03:27 +0900
Itagaki Takahiro wrote:
> Good catch. I merged your fix into the attached patch.
Thanks, I'll rebase my patches.
> BTW, why didn't planner choose a materialized plan for the inner loop?
> FDW scans are typically slower than heap scans or TupleTableslot scans,
I tried to pick up this patch to review.
It seems to me fine, enough simple and works as explained in the
implementation level, apart from reasonability of this feature.
(Tom was not 100% agree with this feature 1.5month ago.)
I'm not certain whether the current regression test should be
updated,
Alvaro Herrera writes:
> Excerpts from Joel Jacobson's message of jue ene 13 06:31:06 -0300 2011:
>> The example from Tom Lane below results in a database which is not
>> possible to correctly dump using pg_dump.
> I wouldn't care too much about that particular case -- you can't query
> any of th
On Thu, Jan 13, 2011 at 10:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> I whipped up the attached patch tonight.
>
> This appears to remove the BM_JUST_DIRTIED logic. Please explain why
> that's not completely broken. Even if it isn't completely broken,
> it would seem better to do something
Excerpts from Bruce Momjian's message of jue ene 13 00:05:53 -0300 2011:
> Srini Raghavan wrote:
> > Thank you very much for reviewing, appreciate the feedback.? As pointed out
> > by
> > you, it is always best to test it out with the latest version, so, I tested
> > the
> > same approach with
Excerpts from Joel Jacobson's message of jue ene 13 06:31:06 -0300 2011:
> The example from Tom Lane below results in a database which is not
> possible to correctly dump using pg_dump.
I wouldn't care too much about that particular case -- you can't query
any of the views either.
--
Álvaro Herr
Robert Haas writes:
> I whipped up the attached patch tonight.
This appears to remove the BM_JUST_DIRTIED logic. Please explain why
that's not completely broken. Even if it isn't completely broken,
it would seem better to do something like that as a separate patch.
rega
Bruce Momjian writes:
> What does pg_upgrade need to do about this for 9.1?
Nothing. An existing GIN index can still do all the same queries it
could do before.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
I whipped up the attached patch tonight. It's pretty quick and dirty,
so it's possible I've missed something, but the intent is to suppress
writing of hint bits by buffers allocating backends, and by
checkpoints, and write them only from the background writer cleaning
scan. It therefore should (a
Robert Haas wrote:
> On Tue, Jan 4, 2011 at 4:49 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane wrote:
> >>> * Existing GIN indexes are upwards compatible so far as on-disk storage
> >>> goes, but they will of course be missing entries for empty, null,
On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane wrote:
>>> Florian Pflug writes:
So maybe there should be a GUC for this?
>
>>> No need (and rather inflexible anyway). If you don't want an orphaned
>>> backend to continue
Robert Haas writes:
> On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane wrote:
>> Florian Pflug writes:
>>> So maybe there should be a GUC for this?
>> No need (and rather inflexible anyway). If you don't want an orphaned
>> backend to continue, you send it SIGTERM.
> It is not easy to make this work
On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane wrote:
> Florian Pflug writes:
>> I don't believe there's one right answer to that.
>
> Right. Force-kill presumes there is only one right answer.
>
>> Assume postgres is driving a website, and the postmaster crashes shortly
>> after a pg_dump run starte
On Thu, Jan 13, 2011 at 7:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
>>> Killing active sessions when it's not absolutely necessary is not an
>>> asset.
>
>> That's a highly arguable point and I certainly don't agree with it.
>
> Your example
Florian Pflug writes:
> I don't believe there's one right answer to that.
Right. Force-kill presumes there is only one right answer.
> Assume postgres is driving a website, and the postmaster crashes shortly
> after a pg_dump run started. You probably won't want your website to be
> offline whi
On Jan14, 2011, at 01:32 , Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
>>> Killing active sessions when it's not absolutely necessary is not an
>>> asset.
>
>> That's a highly arguable point and I certainly don't agree with it.
>
> Your examples app
Robert Haas writes:
> On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
>> Killing active sessions when it's not absolutely necessary is not an
>> asset.
> That's a highly arguable point and I certainly don't agree with it.
Your examples appear to rely on the assumption that background processes
> Tatsuo Ishii writes:
>>> Please add this to the currently open CommitFest:
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>
>> Done. Comments are welcome. Unless there's objection, I will commit it
>> this weekend.
>
> If you're expecting anyone to actually *review* it durin
Robert Haas writes:
> On Thu, Jan 13, 2011 at 5:29 PM, Magnus Hagander wrote:
>> +1, I like the idea. Would it still be there to override if necessary?
> Depends what people want to do. We could make the default "0kB", and
> define that to mean "auto-tune", or we could remove the parameter
> al
On Jan 13, 2011, at 4:15 PM, Stephen J. Butler wrote:
> Suppose one of these compatibility objects is passed into legacy code
> as $_[0]. The problem is that 'ref $_[0]' will return 'Pg::ArrayArg'
> instead of what it used to, '' (empty string). Other than that, I
> think it performs as people wou
Anssi Kääriäinen wrote:
> I think I found a problem. This is using SSI v8. The table
> definition:
>
> create table test_t (id integer, val1 text, val2 integer);
> create index test_idx on test_t(id) where val2 = 1;
> insert into test_t (select generate_series(0, 1), 'a', 2);
> insert in
On Thu, Jan 13, 2011 at 2:06 AM, Martijn van Oosterhout
wrote:
> I played with this a little and it is fairly easy to make a variable
> such that $a is the string representation and $a[0] the first value of
> the array. The problem is that you can't pass such a variable into a
> subroutine.
I pla
Tatsuo Ishii writes:
>> Please add this to the currently open CommitFest:
>> https://commitfest.postgresql.org/action/commitfest_view/open
> Done. Comments are welcome. Unless there's objection, I will commit it
> this weekend.
If you're expecting anyone to actually *review* it during the CF,
th
> On Thu, Jan 13, 2011 at 2:13 AM, Tatsuo Ishii wrote:
>> Ok. Here is the patch for this. I use 40P02, instead of 40004.
>
> Please add this to the currently open CommitFest:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
Done. Comments are welcome. Unless there's objection,
On Thu, Jan 13, 2011 at 03:29:13PM -0800, Jeff Davis wrote:
> On Thu, 2011-01-13 at 11:14 -0800, David Fetter wrote:
> > I get that we can't prevent all pilot error, but I was hoping we
> > could bullet-proof this a little more, especially in light of a
> > certain extremely popular server OS's OOM
On Thu, 2011-01-13 at 11:14 -0800, David Fetter wrote:
> I get that we can't prevent all pilot error, but I was hoping we could
> bullet-proof this a little more, especially in light of a certain
> extremely popular server OS's OOM killer's default behavior.
That's a good point. I'm not sure how m
Robert Haas wrote:
> Would anyone like to argue vigorously for or against the above
> proposal?
Greg's numbers look reasonable to me, and there's nobody I'd trust
more to come up with reasonable numbers for this. One less tunable
is a good thing, especially since this designed to scale from
s
Robert,
>> Unfortunately, we might still need a manual parameter for override
>> because of the interaction between wal_buffers and
>> synchronous_commit=off, since it sets the max size of the unflushed data
>> buffer. Discuss?
>
> Do we have any evidence there's actually a problem in that case,
https://github.com/gluefinance/pov/blob/master/doc/example_database.sql
Please feel free to put any of this on the PostgreSQL wiki like
suggested by David Fetter.
This is an example of some functionality provided and used by pov
(PostgreSQL Object version control system).
Most of, if not all, thi
On Thu, Jan 13, 2011 at 6:02 PM, Josh Berkus wrote:
>
>> Depends what people want to do. We could make the default "0kB", and
>> define that to mean "auto-tune", or we could remove the parameter
>> altogether. I think I was envisioning the latter, but if people are
>> hesitant to do that we coul
> Depends what people want to do. We could make the default "0kB", and
> define that to mean "auto-tune", or we could remove the parameter
> altogether. I think I was envisioning the latter, but if people are
> hesitant to do that we could do the former instead.
Unfortunately, we might still ne
On Jan13, 2011, at 21:42 , Tom Lane wrote:
> Aidan Van Dyk writes:
>> If postmaster has a few fds to spare, what about having it open a pipe
>> to every child it spawns. It never has to read/write to it, but
>> postmaster closing will signal the client's fd. The client just has
>> to pop the fd
On Thu, Jan 13, 2011 at 5:29 PM, Magnus Hagander wrote:
> +1, I like the idea. Would it still be there to override if necessary?
Depends what people want to do. We could make the default "0kB", and
define that to mean "auto-tune", or we could remove the parameter
altogether. I think I was envis
On Thu, Jan 13, 2011 at 23:19, Robert Haas wrote:
> On Thu, Jan 6, 2011 at 11:37 PM, Greg Smith wrote:
>> If it defaulted to 3% of shared_buffers, min 64K & max 16MB for the auto
>> setting, it would for the most part become an autotuned parameter. That
>> would make it 0.75 to 1MB at the standa
On Thu, Jan 6, 2011 at 11:37 PM, Greg Smith wrote:
> If it defaulted to 3% of shared_buffers, min 64K & max 16MB for the auto
> setting, it would for the most part become an autotuned parameter. That
> would make it 0.75 to 1MB at the standard anemic Linux default kernel
> parameters. Maybe more
On Thu, Jan 13, 2011 at 02:21:44PM -0500, Tom Lane wrote:
> David Fetter writes:
> > I get that we can't prevent all pilot error, but I was hoping we
> > could bullet-proof this a little more, especially in light of a
> > certain extremely popular server OS's OOM killer's default
> > behavior.
>
> So far I have 6 people who have volunteered to be round-robin
> reviewers, and 7 people who are listed as reviewers on the CF site
> already. That leaves 45 patches without a reviewer, plus whatever
> comes in in the next day or so. This is not going to work unless a
> lot more people pitch in
On Tue, Jan 11, 2011 at 9:17 PM, Robert Haas wrote:
> [ abject plea for reviewers ]
So far I have 6 people who have volunteered to be round-robin
reviewers, and 7 people who are listed as reviewers on the CF site
already. That leaves 45 patches without a reviewer, plus whatever
comes in in the n
On 13.01.2011 22:57, Josh Berkus wrote:
On 1/13/11 12:11 PM, Robert Haas wrote:
That's going to depend on the situation. If the database fits in
memory, then it's just going to work. If it fits on disk, it's less
obvious whether it'll be good or bad, but an arbitrary limitation here
doesn't se
On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> I strongly believe you're in the minority on that one, for the same
>> reasons that I don't think most people would agree with your notion of
>> what should be the default shutdown mode. A database that can't
>> accept new
On Thu, Jan 13, 2011 at 09:18:06PM +0100, Florian Pflug wrote:
> On Jan13, 2011, at 21:01 , Aidan Van Dyk wrote:
> > On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas wrote:
> >> I'm not convinced. I was thinking that we could simply treat it
> >> like SIGQUIT, if it's available. I doubt there's a re
On 1/13/11 12:11 PM, Robert Haas wrote:
> That's going to depend on the situation. If the database fits in
> memory, then it's just going to work. If it fits on disk, it's less
> obvious whether it'll be good or bad, but an arbitrary limitation here
> doesn't serve us well.
FWIW, if we had this
Aidan Van Dyk writes:
> If postmaster has a few fds to spare, what about having it open a pipe
> to every child it spawns. It never has to read/write to it, but
> postmaster closing will signal the client's fd. The client just has
> to pop the fd into whatever nrmal poll/select event handlign it
On Thu, Jan 13, 2011 at 21:37, Tom Lane wrote:
> Robert Haas writes:
>> I strongly believe you're in the minority on that one, for the same
>> reasons that I don't think most people would agree with your notion of
>> what should be the default shutdown mode. A database that can't
>> accept new c
Robert Haas writes:
> I strongly believe you're in the minority on that one, for the same
> reasons that I don't think most people would agree with your notion of
> what should be the default shutdown mode. A database that can't
> accept new connections is a liability, not an asset.
Killing acti
Robert Haas wrote:
> A database that can't accept new connections is a liability, not
> an asset.
+1
I have so far been unable to imagine a use case for the production
databases I use where I would prefer to see backends continue after
postmaster failure.
-Kevin
--
Sent via pgsql-hackers
On Jan13, 2011, at 21:01 , Aidan Van Dyk wrote:
> On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas wrote:
>> I'm not convinced. I was thinking that we could simply treat it like
>> SIGQUIT, if it's available. I doubt there's a real use case for
>> continuing to run queries after the postmaster and a
On Thu, Jan 13, 2011 at 2:19 PM, Ross J. Reedstrom wrote:
> On Tue, Jan 11, 2011 at 11:06:18AM -0800, Josh Berkus wrote:
>>
>> > It makes it very convenient to set up standbys, without having to worry
>> > that you'll conflict e.g with a nightly backup. I don't imagine people
>> > will use streami
On Thu, Jan 13, 2011 at 3:01 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane wrote:
>>> I wonder whether we could have some sort of latch-like counter that
>>> would count the number of active backends and deliver signals when the
>>> count went to zero. H
On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas wrote:
> I'm not convinced. I was thinking that we could simply treat it like
> SIGQUIT, if it's available. I doubt there's a real use case for
> continuing to run queries after the postmaster and all the background
> processes are dead. Expedited de
Robert Haas writes:
> On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane wrote:
>> I wonder whether we could have some sort of latch-like counter that
>> would count the number of active backends and deliver signals when the
>> count went to zero. However, if the goal is to defend against random
>> appli
On Tue, Jan 11, 2011 at 11:06:18AM -0800, Josh Berkus wrote:
>
> > It makes it very convenient to set up standbys, without having to worry
> > that you'll conflict e.g with a nightly backup. I don't imagine people
> > will use streaming base backups for very large databases anyway.
>
> Also, imag
On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane wrote:
>>> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
>>> It sucks because you don't get a signal on parent death. With the
>>> arrival of the latch c
Robert Haas writes:
> On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane wrote:
>> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
>> It sucks because you don't get a signal on parent death. With the
>> arrival of the latch code, having to check for PostmasterIsAlive
>> frequently
On Thu, Jan 13, 2011 at 2:04 PM, Joel Jacobson wrote:
> 2011/1/13 Tom Lane :
>> Yes, probably. It's certainly possible to have the same linkage occur
>> with different deptypes. We don't try hard to avoid dups because they
>> don't matter.
>
> "with different deptypes", yes, but in this case the
On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane wrote:
> Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
> It sucks because you don't get a signal on parent death. With the
> arrival of the latch code, having to check for PostmasterIsAlive
> frequently is the only reason for an
David Fetter writes:
> I get that we can't prevent all pilot error, but I was hoping we could
> bullet-proof this a little more, especially in light of a certain
> extremely popular server OS's OOM killer's default behavior.
> Yes, I get that that behavior is crazy, and stupid, and that people
>
Florian Pflug writes:
> Couldn't normal backends call PostmasterIsAlive and exit if not, just
> like the startup process, the stats collector, autovacuum, bgwriter,
> walwriter, walreceiver, walsender and the wal archiver already do?
> I assumed they do, but now that I grepped the code it seems t
On Thu, Jan 13, 2011 at 12:45:07PM -0600, Kevin Grittner wrote:
> Tom Lane wrote:
>
> > I can't see automating it though. We already have a perfectly
> > good solution to the automated shutdown problem.
>
> Oh, I totally agree with that. I somehow thought we'd gotten off
> into how someone c
On Wed, Jan 12, 2011 at 10:39, Fujii Masao wrote:
> On Mon, Jan 10, 2011 at 11:09 PM, Magnus Hagander wrote:
>> I've committed the backend side of this, without that. Still working
>> on the client, and on cleaning up Heikki's patch for grammar/parser
>> support.
>
> Great work!
>
> I have some c
2011/1/13 David Fetter :
> Please put a self-contained example on the snippets page, and please
> also to check that it actually runs before doing so. You'd mangled
> some aliases in the query you sent, which leads me to believe you
> hadn't actually tried running it.
I actually hadn't really sol
On Jan13, 2011, at 19:00 , Tom Lane wrote:
> At least on Unix I don't believe there is any other solution. You
> could try looking at ps output but there's a fundamental race condition,
> ie the postmaster could spawn another child just before you kill it,
> whereupon the child is reassigned to in
2011/1/13 Tom Lane :
> Yes, probably. It's certainly possible to have the same linkage occur
> with different deptypes. We don't try hard to avoid dups because they
> don't matter.
"with different deptypes", yes, but in this case there were two
linkages of the same deptype.
Just seems a bit str
Tom Lane wrote:
> I can't see automating it though. We already have a perfectly
> good solution to the automated shutdown problem.
Oh, I totally agree with that. I somehow thought we'd gotten off
into how someone could recover after shooting their foot.
-Kevin
--
Sent via pgsql-hackers m
"Kevin Grittner" writes:
> Tom Lane wrote:
>> At least on Unix I don't believe there is any other solution. You
>> could try looking at ps output but there's a fundamental race
>> condition, ie the postmaster could spawn another child just before
>> you kill it, whereupon the child is reassigned
Robert Haas writes:
> On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane wrote:
>> IMO, what this patch needs is to not output the types unless they are
>> actually different from the default (which can be inferred from the AM
>> type and the function arguments). That would fix my concern about it
>> emit
Joel Jacobson writes:
> Are multiple identical entires in pg_depend possible?
Yes, probably. It's certainly possible to have the same linkage occur
with different deptypes. We don't try hard to avoid dups because they
don't matter.
regards, tom lane
--
Sent via pgsql-
Tom Lane wrote:
> At least on Unix I don't believe there is any other solution. You
> could try looking at ps output but there's a fundamental race
> condition, ie the postmaster could spawn another child just before
> you kill it, whereupon the child is reassigned to init and there's
> no long
David Fetter writes:
> On Thu, Jan 13, 2011 at 10:41:28AM -0500, Tom Lane wrote:
>> It's just that you're then looking at having to manually clean up the
>> child processes and then restart the postmaster; a process that is not
>> only tedious but does offer the possibility of screwing yourself.
On Thu, Jan 13, 2011 at 18:43, Robert Haas wrote:
> On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander wrote:
>> On Wed, Jan 12, 2011 at 03:03, Robert Haas wrote:
>>> On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander
>>> wrote:
> No, do this at top
>
> if (walsnd->state == state)
>>>
On Wed, Jan 12, 2011 at 09:09:31PM +0100, Joel Jacobson wrote:
> (sorry for top posting,
No worries.
> iPhone + drunk)
A dangerous combination indeed. I hear water, NSAIDs and time can
help with the hangover ;)
> pg_depend_before is a select * from pg_depend before creating the
> test db model
On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander wrote:
> On Wed, Jan 12, 2011 at 03:03, Robert Haas wrote:
>> On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander wrote:
No, do this at top
if (walsnd->state == state)
return;
Keep spinlocks when actually setting it.
>
Tom Lane wrote:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of lun dic 27 13:54:56 -0300 2010:
> >> [ lightbulb ] ... although we could improve that quite a bit if we
> >> processed each .h file separately instead of insisting on smashing
> >> everything into one compilation. Le
On Thu, Jan 13, 2011 at 10:41:28AM -0500, Tom Lane wrote:
> David Fetter writes:
> > I've noticed over the years that we give people dire warnings never to
> > send a KILL signal to the postmaster, but I'm unsure as to what are
> > potential consequences of this, as in just exactly how this can re
Robert Haas wrote:
> On Wed, Jan 12, 2011 at 8:54 PM, Bruce Momjian wrote:
> > I am also attaching a few more of Leslie's changes that I think are
> > useful. ?The first clarifies a confusion Leslie had about the fact that
> > "return" is referencing the return value of the function and not the
>
On Thu, Jan 13, 2011 at 01:06, Martijn van Oosterhout wrote:
> On Thu, Jan 13, 2011 at 12:06:33AM -0700, Alex Hunsaker wrote:
>> > I had supposed that it would be possible to do the string conversion
>> > lazily, ie, only if the string value was actually demanded.
>>
>> Yep, In-fact if we wanted w
2011/1/13 Tom Lane :
> Hitoshi Harada writes:
>> I found a crash case (assertion failure) when runing psql -f
>> utf8_encoded_script.sql against client_encoding = shift_jis in
>> postgresql.conf. Though encoding mismatch is obviously user's fault, a
>> crash doesn't explain anything to him.
>
> I'
On 13.01.2011 14:34, Fujii Masao wrote:
On Thu, Jan 13, 2011 at 9:01 PM, Heikki Linnakangas
wrote:
Attached patch fixes libpqrcv_receive() so that it calls PQconsumeInput()
before concluding that there's no data available. The excessive fsyncing can
lead to very bad performance, so this needs
Heikki Linnakangas wrote:
> On 13.01.2011 16:51, Kevin Grittner wrote:
>> But we acquired a relation lock up front, when we determined that
>> this would be a heap scan, so we could short-circuit this whole
>> thing if within the heapgettup_pagemode function we could
>> determine that this was a
On Wed, Jan 12, 2011 at 03:03, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander wrote:
>>> No, do this at top
>>>
>>> if (walsnd->state == state)
>>> return;
>>>
>>> Keep spinlocks when actually setting it.
>
> I think this is safe...
>
>> Aha. Thanks for the pointers, pfa a
David Fetter writes:
> I've noticed over the years that we give people dire warnings never to
> send a KILL signal to the postmaster, but I'm unsure as to what are
> potential consequences of this, as in just exactly how this can result
> in problems. Is there some reference I can look to for exp
Heikki Linnakangas wrote:
> That sounds simple enough. Add a boolean field to HeapScanDesc,
> "rs_relpredicatelocked", and set it when you acquire the relation
> lock.
I'll take a look at doing that. Thanks!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 13.01.2011 16:51, Kevin Grittner wrote:
Right. As each tuple is read we need to ensure that there is a
predicate lock to cover it. Since finer-grained locks can be
combined into coarser-grained locks we need to start with the fine
grained and move toward checking the coarser grains, to avoid
Heikki Linnakangas wrote:
> where exactly is the extra overhead coming from?
Keep in mind that this is a sort of worst case scenario. The data
is fully cached in shared memory and we're doing a sequential pass
just counting the rows. In an earlier benchmark (which I should
re-do after all th
Heikki Linnakangas wrote:
> Pardon my ignorance, but where exactly is the extra overhead
> coming from? Searching for a predicate lock?
Right. As each tuple is read we need to ensure that there is a
predicate lock to cover it. Since finer-grained locks can be
combined into coarser-grained lo
Folks,
I've noticed over the years that we give people dire warnings never to
send a KILL signal to the postmaster, but I'm unsure as to what are
potential consequences of this, as in just exactly how this can result
in problems. Is there some reference I can look to for explanations
of the mecha
Thanks to the new pg_stat_xact_user_functions and
pg_stat_xact_user_tables views in 9.1, it will be possible to
automatically "sample" which functions uses which functions/tables to
generate a nice directional graph of the dependency tree, based on
recent real-life activity, excluding any unused re
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 conversion type character 'l' in format
On Thu, Jan 13, 2011 at 9:01 PM, Heikki Linnakangas
wrote:
> While testing Fujii-san's patch to flush any already-written WAL on error in
> walreceiver, I added a debugging elog to XLogWalRcvFlush() to print out how
> far it has written and flushed.
>
> I saw an unexpected pattern while the standb
On Thu, Jan 13, 2011 at 7:00 PM, Heikki Linnakangas
wrote:
> +1 for "promote". People unfamiliar with the replication stuff might not
> immediately understand that it's related to replication, but they wouldn't
> have any use for the option anyway. It should be clear to anyone who needs
> it.
I d
While testing Fujii-san's patch to flush any already-written WAL on
error in walreceiver, I added a debugging elog to XLogWalRcvFlush() to
print out how far it has written and flushed.
I saw an unexpected pattern while the standby catches up with the master:
LOG: streaming replication success
Tom Lane writes:
> "David E. Wheeler" writes:
>> On Jan 12, 2011, at 4:35 PM, Tom Lane wrote:
>>> No, what we need is a decent extension package manager ;-)
>
>> Yeah. Maybe you can do that this weekend? Or, I dunno, while you sleep
>> tonight?
>
> Supposedly it's in the queue for the upcoming
On Thu, Jan 13, 2011 at 5:00 AM, Heikki Linnakangas
wrote:
> On 13.01.2011 04:29, Itagaki Takahiro wrote:
>>
>> On Thu, Jan 13, 2011 at 00:14, Fujii Masao wrote:
pg_ctl failover ? At the moment, the location of the trigger file is
configurable, but if we accept a constant location
* Joel Jacobson wrote:
The example from Tom Lane below results in a database which is not
possible to correctly dump using pg_dump.
The view v1 strangely becomes a table in the dump output?!
This is no bug, it's a feature (tm).
pg_dump is clever enough to detect the circular dependency and b
On Wed, Jan 12, 2011 at 11:52 PM, Fujii Masao wrote:
> So I'm thinking to make ProcessConfigFile() parse not only postgresql.conf
> but also recovery.conf rather than move all the recovery parameters to
> postgresql.conf.
>
> Comments?
+1.
Actually moving the settings can be done later in about
On 2011-01-13 11:31 AM +0200, Joel Jacobson wrote:
The example from Tom Lane below results in a database which is not
possible to correctly dump using pg_dump.
The view v1 strangely becomes a table in the dump output?!
CREATE RULE "_RETURN" AS ON SELECT TO v1 DO INSTEAD SELECT v2.f1, v2.f2 FR
On Wed, Jan 12, 2011 at 8:54 PM, Bruce Momjian wrote:
> I am also attaching a few more of Leslie's changes that I think are
> useful. The first clarifies a confusion Leslie had about the fact that
> "return" is referencing the return value of the function and not the
> value returned in the point
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> Here is a very simple change of the patch to make the output look more
>> like the syntax of ALTER OPERATOR FAMILY to improve consistency.
>
> IMO, what this patch needs is to not output the types unless they are
> act
1 - 100 of 111 matches
Mail list logo
