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
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
On 13.01.2011 02:01, Kevin Grittner wrote:
Anssi Kääriäinenanssi.kaariai...@thl.fi 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
On 13.01.2011 04:29, Itagaki Takahiro wrote:
On Thu, Jan 13, 2011 at 00:14, Fujii Masaomasao.fu...@gmail.com 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,
.
Regards,
--
Shigeru Hanada
20110113-copy_context.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jan 13, 2011 at 5:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Thu, Jan 13, 2011 at 2:13 AM, Tatsuo Ishii is...@postgresql.org 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:
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andreas Karlsson andr...@proxel.se 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
On Wed, Jan 12, 2011 at 8:54 PM, Bruce Momjian br...@momjian.us 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
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
On Wed, Jan 12, 2011 at 11:52 PM, Fujii Masao masao.fu...@gmail.com 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
* 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
On Thu, Jan 13, 2011 at 5:00 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.01.2011 04:29, Itagaki Takahiro wrote:
On Thu, Jan 13, 2011 at 00:14, Fujii Masaomasao.fu...@gmail.com wrote:
pg_ctl failover ? At the moment, the location of the trigger file is
Tom Lane t...@sss.pgh.pa.us writes:
David E. Wheeler da...@kineticode.com 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
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
On Thu, Jan 13, 2011 at 7:00 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Thu, Jan 13, 2011 at 9:01 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
David Fetter da...@fetter.org 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
On Wed, Jan 12, 2011 at 03:03, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net 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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On 13.01.2011 14:34, Fujii Masao wrote:
On Thu, Jan 13, 2011 at 9:01 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
2011/1/13 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com 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
On Thu, Jan 13, 2011 at 01:06, Martijn van Oosterhout klep...@svana.org 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
Robert Haas wrote:
On Wed, Jan 12, 2011 at 8:54 PM, Bruce Momjian br...@momjian.us 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
On Thu, Jan 13, 2011 at 10:41:28AM -0500, Tom Lane wrote:
David Fetter da...@fetter.org 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jan 12, 2011 at 03:03, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net wrote:
No, do this at top
if (walsnd-state == state)
return;
Keep
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 robertmh...@gmail.com wrote:
On Thu, Jan 13, 2011 at 11:08 AM, Magnus Hagander mag...@hagander.net wrote:
On Wed, Jan 12, 2011 at 03:03, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander mag...@hagander.net
David Fetter da...@fetter.org 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
Tom Lane t...@sss.pgh.pa.us 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
Joel Jacobson j...@gluefinance.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Jan 12, 2011 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane t...@sss.pgh.pa.us 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
2011/1/13 Tom Lane t...@sss.pgh.pa.us:
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
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 init
2011/1/13 David Fetter da...@fetter.org:
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
On Wed, Jan 12, 2011 at 10:39, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jan 10, 2011 at 11:09 PM, Magnus Hagander mag...@hagander.net 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.
On Thu, Jan 13, 2011 at 12:45:07PM -0600, Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
David Fetter da...@fetter.org 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
On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jan 13, 2011 at 2:04 PM, Joel Jacobson j...@gluefinance.com wrote:
2011/1/13 Tom Lane t...@sss.pgh.pa.us:
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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 2:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Frankly I'd prefer to get rid of PostmasterIsAlive, not extend its use.
It sucks because you don't get a signal on
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, imagine that
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us 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
On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas robertmh...@gmail.com 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
On Thu, Jan 13, 2011 at 3:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 2:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I wonder whether we could have some sort of latch-like counter that
would count the number of active backends and
On Thu, Jan 13, 2011 at 2:19 PM, Ross J. Reedstrom reeds...@rice.edu 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
On Jan13, 2011, at 21:01 , Aidan Van Dyk wrote:
On Thu, Jan 13, 2011 at 2:53 PM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
--
Robert Haas robertmh...@gmail.com 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
On Thu, Jan 13, 2011 at 21:37, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Aidan Van Dyk ai...@highrise.ca 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
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 robertmh...@gmail.com wrote:
I'm not convinced. I was thinking that we could simply treat it
like SIGQUIT, if it's available. I doubt
On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
On Tue, Jan 11, 2011 at 9:17 PM, Robert Haas robertmh...@gmail.com 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
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 da...@fetter.org 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
On Thu, Jan 6, 2011 at 11:37 PM, Greg Smith g...@2ndquadrant.com 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
On Thu, Jan 13, 2011 at 23:19, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 6, 2011 at 11:37 PM, Greg Smith g...@2ndquadrant.com 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
On Thu, Jan 13, 2011 at 5:29 PM, Magnus Hagander mag...@hagander.net 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
On Jan13, 2011, at 21:42 , Tom Lane wrote:
Aidan Van Dyk ai...@highrise.ca 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
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 need a
On Thu, Jan 13, 2011 at 6:02 PM, Josh Berkus j...@agliodbs.com 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
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,
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, or
that
Robert Haas robertmh...@gmail.com 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
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
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 is...@postgresql.org 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
Tatsuo Ishii is...@postgresql.org 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
On Thu, Jan 13, 2011 at 2:06 AM, Martijn van Oosterhout
klep...@svana.org 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
Anssi Kääriäinenanssi.kaariai...@thl.fi 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),
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 would
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 5:29 PM, Magnus Hagander mag...@hagander.net 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
Tatsuo Ishii is...@postgresql.org 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*
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us 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
On Jan14, 2011, at 01:32 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us 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
Florian Pflug f...@phlo.org 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
On Thu, Jan 13, 2011 at 7:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Killing active sessions when it's not absolutely necessary is not an
asset.
That's a highly arguable point and I
On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org 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
On Thu, Jan 13, 2011 at 8:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Jan 13, 2011 at 8:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
So maybe there should be a GUC for this?
No need (and rather inflexible
Robert Haas wrote:
On Tue, Jan 4, 2011 at 4:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 4, 2011 at 4:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
* Existing GIN indexes are upwards compatible so far as on-disk storage
goes, but they will of
1 - 100 of 111 matches
Mail list logo
