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 we could even die (or throw an exception in
> other language speak :
Hi,
When the master shuts down or crashes, there seems to be
the case where walreceiver exits without flushing WAL which
has already been written. This might lead startup process to
replay un-flushed WAL and break a Write-Ahead-Logging rule.
walreceiver.c
> /* Wait a while for data
On 13.01.2011 10:28, Fujii Masao wrote:
When the master shuts down or crashes, there seems to be
the case where walreceiver exits without flushing WAL which
has already been written. This might lead startup process to
replay un-flushed WAL and break a Write-Ahead-Logging rule.
Hmm, that can hap
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?!
It's probably a quite useless database to dump in the first place, but
that is no excuse to generate an invalid dump, it would be
On 13.01.2011 02:01, Kevin Grittner wrote:
Anssi Kääriäinen wrote:
So, count(*) queries are more than twice as slow compared to the
old serializable transaction isolation level.
I got this down from more than twice the run time to running 33%
longer through remembering the last relation for
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 like "$PGDATA/failover"
pg_ctl could do the whole thing, create the file and sen
w about to implement using materialized tuples to avoid unnecessary
(at least for functionality) changes. I would like to send this
virtual-tuple-optimization to next development cycle because it would
not effect the interface heavily. I'll post materialized-tuple
version of foreign_scan patch
Are multiple identical entires in pg_depend possible?
If so, how do they occur, and what is the purpose of representing
exactly the same dependency two times in pg_depend?
I expected the following query not to return any rows, but it did:
glue=# select count(*), * from pg_depend group by classid,
Tom Lane writes:
> That seems pretty silly/broken. You should only be touching *direct*
> dependencies of the extension, IMO. If there's something that's missed
> by that algorithm, the way to fix it is to add more direct dependencies
> at extension creation time; not to start a tree walk that i
On Thu, Jan 13, 2011 at 5:59 PM, Heikki Linnakangas
wrote:
> On 13.01.2011 10:28, Fujii Masao wrote:
>>
>> When the master shuts down or crashes, there seems to be
>> the case where walreceiver exits without flushing WAL which
>> has already been written. This might lead startup process to
>> repl
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
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
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
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 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 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
* 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 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
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
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
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
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
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
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
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
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
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
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:
> 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
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
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
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 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
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 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
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 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
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 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.
>
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 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)
>>>
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.
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
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-
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
"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
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
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
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 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 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
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
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
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
>
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
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
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: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
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
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 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
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: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 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
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
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
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
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 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
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 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 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 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
> 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 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.
>
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 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 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 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
> 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 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
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
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,
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
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
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, 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,
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: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
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 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
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
> 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 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
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
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 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
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
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: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 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,
1 - 100 of 111 matches
Mail list logo
