Hey Florian,
Thank you very much!
2010/12/8 Florian Pflug f...@phlo.org
On Dec8, 2010, at 11:35 , Dmitriy Igrishin wrote:
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed in future ?
What's the
Hi,
I found an interesting article which explains how to solve sudoku by
using SQL(unfortunately written in Japanese):
http://codezine.jp/article/detail/1629?p=2
In the article example sudoku is:
http://static.shoeisha.jp/cz/static/images/article/1629/problem4.gif
To solve the example you
David E. Wheeler da...@kineticode.com writes:
What about unaccent? Or lo (1 domain, 2 functions)?
Sure. Doesn't have to actually do anything.
Ok, so that's already in the patch :)
That's called a shared catalog. I don't see any benefit of having to
maintain that when we do already have a
Robert Haas robertmh...@gmail.com writes:
I think this so-called two-step approach is pretty ugly.
Well it does not need to be exposed to the user, thinking about it, as
proposed in the other thread. Other than that, you're argument here is
exactly the same as the ones saying that VACUUM or Hint
Tom Lane t...@sss.pgh.pa.us writes:
Er ... what good is that? A non-relocatable extension doesn't *need*
any such substitution, because it knows perfectly well what schema it's
putting its stuff into. Only the relocatable case has use for it. So
you might as well drop the substitution
Magnus Hagander mag...@hagander.net writes:
On Wed, Dec 8, 2010 at 02:07, Tom Lane t...@sss.pgh.pa.us wrote:
[ win32.h says ]
#define fsync(fd) _commit(fd)
What this means is that switching to a simple preference order
fdatasync, then fsync will result in choosing fsync on Windows (since
it
On 12/08/2010 05:35 AM, Dmitriy Igrishin wrote:
Hey hackers@,
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed in future ?
It is not guaranteed today, let alone in the future, that the array type
Tom Lane t...@sss.pgh.pa.us wrote:
I agree that letting it be changed back to read/write after that
is surprising and unnecessary. Perhaps locking down the setting
at the time of first grabbing a snapshot would be appropriate.
IIRC that's how it works for transaction isolation level, and
Dmitriy Igrishin dmit...@gmail.com writes:
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore
No. Read the code, or the documentation.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Hey Andrew,
Finally convinced. Thanks!
2010/12/8 Andrew Dunstan and...@dunslane.net
On 12/08/2010 05:35 AM, Dmitriy Igrishin wrote:
Hey hackers@,
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed
A very useful feature for unlogged tables would be the ability to
switch them back to normal tables -- this way you could do bulk
loading into an unlogged table and then turn it into a regular table
using just fsync(), bypassing all the WAL-logging overhead. It seems
this could even be implemented
Hey Tom,
Thanks you too.
I always read the documentation, but don't want (yes, don't want)
to read a lot of code to get the answer on simple question because
life is too short for it. I think that people should helps each other :-)
2010/12/8 Tom Lane t...@sss.pgh.pa.us
Dmitriy Igrishin
Hi there,
below is the problem, which I don't have when running in shell. The database is
in UTF-8 encoding.
CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$
use strict;
use URI::Escape;
return uri_unescape($_[0]);
$$ LANGUAGE plperlu;
CREATE FUNCTION
On Tue, Dec 7, 2010 at 03:34, Tom Lane t...@sss.pgh.pa.us wrote:
To my mind, O_DIRECT is not really the key issue here, it's whether to
prefer O_DSYNC or fdatasync.
Since different platforms implement these primitives differently, and
it's not always clear from the header file definitions which
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii is...@postgresql.org wrote:
Hi,
I found an interesting article which explains how to solve sudoku by
using SQL(unfortunately written in Japanese):
http://codezine.jp/article/detail/1629?p=2
In the article example sudoku is:
Marti Raudsepp ma...@juffo.org writes:
On Tue, Dec 7, 2010 at 03:34, Tom Lane t...@sss.pgh.pa.us wrote:
To my mind, O_DIRECT is not really the key issue here, it's whether to
prefer O_DSYNC or fdatasync.
Since different platforms implement these primitives differently, and
it's not always
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
Looking to commit in next few hours barring objections/suggestions, to
both HEAD and 9_0_STABLE, in time for next minor release.
--
Simon
On Tue, 2010-12-07 at 13:17 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I'm also going to go through and change all instances of the word
unlogged to volatile, per previous discussion. If this seems like
a bad idea to anyone, please object now rather than afterwards.
On Mon, 2010-12-06 at 23:26 -0300, Alvaro Herrera wrote:
Why would multiple bgwriter processes worry you?
Because it complicates the tracking of files requiring fsync.
As Greg says, the last attempt to do that was a lot of code.
--
Simon Riggs http://www.2ndQuadrant.com/books/
On 12/08/2010 10:13 AM, Oleg Bartunov wrote:
Hi there,
below is the problem, which I don't have when running in shell. The
database is in UTF-8 encoding.
CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$
use strict;
use URI::Escape;
return
Dmitriy Igrishin dmit...@gmail.com writes:
I always read the documentation, but don't want (yes, don't want)
to read a lot of code to get the answer on simple question because
life is too short for it. I think that people should helps each other :-)
Fine, but that sort of question doesn't
adding utf8::decode($_[0]) solves the problem:
knn=# CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$
use strict;
use URI::Escape;
utf8::decode($_[0]);
return uri_unescape($_[0]);
$$ LANGUAGE plperlu;
Oleg
On Wed, 8 Dec 2010, Andrew Dunstan wrote:
On Tue, Dec 7, 2010 at 2:06 PM, flyusa2010 fly flyusa2...@gmail.com wrote:
Hi, folks,
I trace the running postgres, and I found that there are some randoms writes
in xlog files!
To my impression, log file writing is always sequential, how come random
writes happen?
Thanks in advance!
Just
I wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
I agree that letting it be changed back to read/write after that
is surprising and unnecessary. Perhaps locking down the setting
at the time of first grabbing a snapshot would be appropriate.
IIRC that's how it works for transaction isolation
On Wed, Dec 8, 2010 at 9:52 AM, Marti Raudsepp ma...@juffo.org wrote:
Have you thought about switching unlogged tables back to logged? Are
there any significant obstacles?
I think it can be done, and I think it's useful, but I didn't want to
tackle it for version one, because it's not trivial.
On Wed, Dec 8, 2010 at 10:19 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-12-07 at 13:17 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I'm also going to go through and change all instances of the word
unlogged to volatile, per previous discussion. If this
On Wed, Dec 8, 2010 at 11:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dmitriy Igrishin dmit...@gmail.com writes:
I always read the documentation, but don't want (yes, don't want)
to read a lot of code to get the answer on simple question because
life is too short for it. I think that people
On Wed, Dec 8, 2010 at 4:19 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
I think this so-called two-step approach is pretty ugly.
Well it does not need to be exposed to the user, thinking about it, as
proposed in the other thread. Other than
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Note that DB2 uses the table modifier VOLATILE to indicate a
table that has a widely fluctuating table size, for example a
queue table.
the fact that DB2 uses that word to mean something entirely
different
Okay, I understand you hint, Tom and Robert. Sorry to trouble.
I've ask here because I thought that exactly only developer
will know the answer on my question: is it guaranteed ... ?.
Many thanks to Florian and Andrew for detailed explanations,
advice and etc without pointing me to the sources.
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii is...@postgresql.org wrote:
In the page first one takes infinite time by PostgreSQL 9.0.1. Next
one can be executed very quickly because the join order is explicitely
specified by cross join syntax. This seems to be a limitation of
PostgreSQL
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Note that DB2 uses the table modifier VOLATILE to indicate a
table that has a widely fluctuating table size, for example a
queue table.
the fact that DB2
On Tue, Dec 07, 2010 at 10:00:28AM -0500, Andrew Dunstan wrote:
On 12/07/2010 09:24 AM, Tim Bunce wrote:
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with our $_TD; local $_TD = shift;
Pre-extend stack for trigger
On Dec 8, 2010, at 8:13 AM, Oleg Bartunov wrote:
adding utf8::decode($_[0]) solves the problem:
knn=# CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS
$$
use strict;
use URI::Escape;
utf8::decode($_[0]);
return uri_unescape($_[0]); $$ LANGUAGE plperlu;
On Dec 8, 2010, at 9:14 AM, Tim Bunce wrote:
Do you have any more improvements in the pipeline?
I'd like to add $arrayref = decode_array_literal('{2,3}') and
maybe $hashref = decode_hstore_literal('x=1, y=2').
I don't know how much works would be involved in those though.
Those would be
Robert Haas robertmh...@gmail.com writes:
It's also worth noting that ALTER EXTENSION .. SET SCHEMA does NOT
guarantee a correct relocation, because someone might have done ALTER
FUNCTION .. SET search_path = @extschema@, and that's not going to get
properly fixed up. I'm coming to the
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii is...@postgresql.org wrote:
In the page first one takes infinite time by PostgreSQL 9.0.1. Next
one can be executed very quickly because the join order is explicitely
specified by cross join syntax. This
I wrote:
There is something funny going on there; it's not just that the planner
is slower with a large flat search space. It is slower, but only maybe
5x or so. What I'm seeing is that it actually finds a much worse plan
(very much larger estimated cost as well as actual runtime) when given
On 08/12/10 18:45, Tom Lane wrote:
The real fix in my mind is to replace GEQO search with something
smarter. I wonder what happened to the SA patch that was reported
on at PGCon.
I got distracted with other things :( I'll try to plan the two queries
with SA and see what the results are. If
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Attached.
Accomplished more through mimicry (based on setting transaction
isolation level) than profound understanding of the code involved;
but it passes all regression tests on both `make check` and `make
installcheck-world`. This
On Wed, Dec 8, 2010 at 12:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
It's also worth noting that ALTER EXTENSION .. SET SCHEMA does NOT
guarantee a correct relocation, because someone might have done ALTER
FUNCTION .. SET search_path = @extschema@, and
t...@sss.pgh.pa.us (Tom Lane) writes:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Note that DB2 uses the table modifier VOLATILE to indicate a
table that has a widely fluctuating table size, for example a
Simon Riggs si...@2ndquadrant.com writes:
Optimize commit_siblings in two ways to improve group commit.
First, avoid scanning the whole ProcArray once we know there
are at least commit_siblings active; second, skip the check
altogether if commit_siblings = 0.
Greg Smith
I wonder whether we
Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. This patch disallows the case of creating a read-only
subtransaction of a read-write parent. That's a step backwards.
I'm not sure how we could enforce that the property not change
after the first query of a subxact, but maybe we don't care that
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I noticed that the standard seems (if I'm reading it correctly) to
allow subtransactions to switch to more restrictive settings for
both transaction isolation and read only status than the enclosing
transaction, but not looser.
Yeah. My
On Wed, Dec 8, 2010 at 1:37 PM, Chris Browne cbbro...@acm.org wrote:
t...@sss.pgh.pa.us (Tom Lane) writes:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Note that DB2 uses the table modifier VOLATILE to
On Wed, Dec 8, 2010 at 1:56 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
Optimize commit_siblings in two ways to improve group commit.
First, avoid scanning the whole ProcArray once we know there
are at least commit_siblings active; second, skip the check
Robert Haas robertmh...@gmail.com writes:
Not that I see anything to disagree with in this patch, but what
happened to posting patches in advance of committing them? Or did I
just miss that part?
http://archives.postgresql.org/pgsql-performance/2010-12/msg00073.php
Possibly it should have
On Wed, Dec 8, 2010 at 2:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Not that I see anything to disagree with in this patch, but what
happened to posting patches in advance of committing them? Or did I
just miss that part?
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
One thing to watch for is allowing subxact exit to restore the
previous read-write state.
OK.
BTW it looks like assign_XactIsoLevel emits a rather useless debug
message in that case, so that code could
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Also, that code is set so that it will throw an error even if
you're assigning the currently active setting, which maybe is
overly strict? Not sure.
The standard is tricky to read, but my reading of it is
Tom Lane t...@sss.pgh.pa.us wrote:
If the standard says that you're allowed to apply a redundant
setting, I think we'd better accept that.
OK
So the implementation I had in mind would allow SET TRANSACTION
operations to occur later in a subxact, as long as they were
redundant and
On Dec8, 2010, at 20:39 , Kevin Grittner wrote:
The standard is tricky to read, but my reading of it is that only
LOCAL changes are allowed after the transaction is underway (which
I *think* effectively means a subtransaction), and those can't make
the setting less strict -- you're allowed to
Robert Haas robertmh...@gmail.com writes:
Exposing it to the user is what I think is ugly.
Ok, and the current idea fixes that! :)
It's also worth noting that ALTER EXTENSION .. SET SCHEMA does NOT
guarantee a correct relocation, because someone might have done ALTER
FUNCTION .. SET
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
So the implementation I had in mind would allow SET TRANSACTION
operations to occur later in a subxact, as long as they were
redundant and weren't actually trying to change the active value.
It's easy to
On 08/12/10 19:02, Jan Urbański wrote:
On 08/12/10 18:45, Tom Lane wrote:
The real fix in my mind is to replace GEQO search with something
smarter. I wonder what happened to the SA patch that was reported
on at PGCon.
I got distracted with other things :( I'll try to plan the two queries
Florian Pflug f...@phlo.org wrote:
Hm, I think being able to assert that the isolation level really
is SERIALIZABLE by simply doing SET TRANSACTION ISOLATION LEVEL
SERIALIZABLE would be a great feature for SSI.
Say you've written a trigger which enforces some complex
constraint, but is
On Dec 8, 2010, at 10:37 AM, Chris Browne wrote:
Other possibilities include TRANSIENT, EPHEMERAL, TRANSIENT, TENUOUS.
EVANESCENT.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri's last reply to me
http://archives.postgresql.org/message-id/87r5ds1v4q@hi-media-techno.com
suggests that what he has in mind is to define a relocatable extension
as one that can be relocated ;-), ie it does not contain any such
gotchas. Maybe
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
I'm pleasantly surprised that the SA code as it stands today, setting
the equlibrium factor to 8 and temperature reduction factor to 0.4, the
query takes 1799.662 ms in total.
Cool.
With the default values it runs
forever, but I
On Dec 8, 2010, at 1:39 AM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
What about unaccent? Or lo (1 domain, 2 functions)?
Sure. Doesn't have to actually do anything.
Ok, so that's already in the patch :)
No, it's not. There are no unit tests at all. You can
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Florian Pflug f...@phlo.org wrote:
Say you've written a trigger which enforces some complex
constraint, but is correct only for SERIALIZABLE transactions. By
simply sticking a SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
at the top of the
JJ == Jeff Janes jeff.ja...@gmail.com writes:
JJ Anyway, the writes are logically sequentially, but not physically.
JJ If I remember correctly, it always writes out full blocks, even if
JJ the last part of the block has not yet been filled with new data.
JJ When the remainder gets filled, it
On Dec 8, 2010, at 12:18 PM, Dimitri Fontaine wrote:
It's certainly true that a large fraction of contrib modules should be
relocatable in that sense, because they just contain C functions that
aren't going to care.
As they all currently are using the SET search_path TO public; trick, I
On 08/12/10 21:18, Tom Lane wrote:
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
I'm pleasantly surprised that the SA code as it stands today, setting
the equlibrium factor to 8 and temperature reduction factor to 0.4, the
query takes 1799.662 ms in total.
Cool.
With the
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 08/12/10 21:18, Tom Lane wrote:
Hmmm ... runs forever is a bit scary.
With SA you start with a temperature that's linearily dependant on the
size of the query, and back off exponentially. Each step means work tha
also depends on
Kineticode Billing da...@kineticode.com writes:
No, it's not. There are no unit tests at all. You can call the contrib
modules and their tests acceptance tests, but that's not the same
thing.
Ok, I need some more guidance here. All contrib extension (there are 38
of them) are using the CREATE
Tom Lane wrote:
http://archives.postgresql.org/pgsql-performance/2010-12/msg00073.php
Possibly it should have been posted to -hackers instead, but surely you
read -performance?
Trying to figure out what exactly commit_delay and commit_siblings did
under the hood was actually the
On Dec 8, 2010, at 12:42 PM, Dimitri Fontaine wrote:
Kineticode Billing da...@kineticode.com writes:
No, it's not. There are no unit tests at all. You can call the contrib
modules and their tests acceptance tests, but that's not the same
thing.
Ok, I need some more guidance here. All
On Wed, 8 Dec 2010, David E. Wheeler wrote:
On Dec 8, 2010, at 8:13 AM, Oleg Bartunov wrote:
adding utf8::decode($_[0]) solves the problem:
knn=# CREATE OR REPLACE FUNCTION url_decode(Vkw varchar) RETURNS varchar AS $$
use strict;
use URI::Escape;
utf8::decode($_[0]);
return
Given my concerns around exactly what is going on in the Windows code,
I'm now afraid to mess with an all-platforms change to fdatasync as the
preferred default; if we do that it should probably just be in HEAD not
the back branches. So I've come around to the idea that Marti's
proposal of a
On Wed, Dec 08, 2010 at 01:23:59PM +0200, Marko Tiikkaja wrote:
On 2010-12-08 10:19 AM +0200, David Fetter wrote:
On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
So this patch was marked Ready for Committer, but a) no committer
has picked it up yet and b) Marko has made changes
On tis, 2010-12-07 at 23:56 +0100, Jan Urbański wrote:
Peter suggested having a mail/patch per feature and the way I intend
to do that is instead of having a dozen branches, have one and after
I'm done rebase it interactively to produce incremental patches that
apply to master, each one
Tom Lane t...@sss.pgh.pa.us wrote:
What I suggested was to not allow read-only - read-write state
transitions except (1) before first snapshot in the main xact
and (2) at subxact exit (the OVERRIDE case). That seems to
accomplish the goal. Now it will also allow dropping down to
read-only
David E. Wheeler da...@kineticode.com writes:
I don't see why. Most of them are dead simple and could easily be
Makefile variables.
And how does the information flows from the Makefile to the production
server, already?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL :
On Dec 8, 2010, at 1:53 PM, Dimitri Fontaine wrote:
I don't see why. Most of them are dead simple and could easily be
Makefile variables.
And how does the information flows from the Makefile to the production
server, already?
`make` generates the file if it doesn't already exist.
David
Greg Smith g...@2ndquadrant.com writes:
I then posted the patch and added it to the January CF. Unbeknownst to
me until today, Simon had the same multi-year this itches and I can't
make it stop feel toward these parameters, and that's how it jumped the
standard process.
I think pretty
David E. Wheeler da...@kineticode.com writes:
And how does the information flows from the Makefile to the production
server, already?
`make` generates the file if it doesn't already exist.
Again, will retry when possible, but it has been a time sink once already.
--
Dimitri Fontaine
Kevin Grittner kevin.gritt...@wicourts.gov writes:
except that I'm not sure whether I addressed the assign_XactIsoLevel
issue you mentioned, since you mentioned a debug message and I only
see things that look like errors to me. If I did miss something,
I'll be happy to take another look if
Tom Lane wrote:
I'm not entirely convinced that zero commit_siblings is a better
default than small positive values, but it's certainly plausible.
Not being allowed to set it to zero was certainly a limitation worth
abolishing though; that has been the case before now, for those who
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Well it does not seem to be complex to code. It's about having a new
property in the control file, relocatable, boolean. This property is
required and controls the behavior of the CREATE EXTENSION ... WITH
SCHEMA command. When true we use the
Tom Lane t...@sss.pgh.pa.us wrote:
GUC_complaint_elevel() can return DEBUGn, and in fact will do so in
the PGC_S_OVERRIDE case. I'm thinking that the code ought to look
more like
/* source == PGC_S_OVERRIDE means do it anyway, eg at xact abort
*/
if (source != PGC_S_OVERRIDE)
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
Looking to commit in next few hours barring objections/suggestions, to
both HEAD and 9_0_STABLE, in
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
Looking to commit in next few hours barring
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Done. Version 3 attached.
My final tweaks didn't make it into that diff. Attached is 3a as a
patch over the version 3 patch.
-Kevin
*** a/src/backend/commands/variable.c
--- b/src/backend/commands/variable.c
***
*** 564,570
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to implement that.
This doesn't look right to me. btree_xlog_delete_get_latestRemovedXid()
function calculates the
On Wed, Dec 8, 2010 at 12:15 PM, James Cloos cl...@jhcloos.com wrote:
JJ == Jeff Janes jeff.ja...@gmail.com writes:
JJ Anyway, the writes are logically sequentially, but not physically.
JJ If I remember correctly, it always writes out full blocks, even if
JJ the last part of the block has not
We've recently fixed the Linux O_DIRECT mess, as well as several nasty
crash and potential-data-loss issues. The core committee has agreed
that it would be a good idea to get these fixes into the field before
people disappear for the holiday season. Since time for that grows
short, we will
On Dec 8, 2010, at 2:07 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
And how does the information flows from the Makefile to the production
server, already?
`make` generates the file if it doesn't already exist.
Again, will retry when possible, but it has
I think that the BufFreelistLock can be a contention bottleneck on a
system with a lot of CPUs that do a lot of shared-buffer allocations
which can fulfilled by the OS buffer cache. That is, read-mostly
queries where the working data set fits in RAM, but not in
shared_buffers. (You can always
Jeff Janes jeff.ja...@gmail.com writes:
I think that the BufFreelistLock can be a contention bottleneck on a
system with a lot of CPUs that do a lot of shared-buffer allocations
which can fulfilled by the OS buffer cache.
Really? buffer/README says
The buffer
management policy is
Vlad Arkhipov arhi...@dc.baikal.ru writes:
08.12.2010 22:46, Tom Lane writes:
Are you by any chance restoring from an 8.3 or older pg_dump file made
on Windows? If so, it's a known issue.
No, I tried Linux only.
OK, then it's not the missing-data-offsets issue.
I think you can reproduce
On Wed, Dec 8, 2010 at 8:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeff Janes jeff.ja...@gmail.com writes:
I think that the BufFreelistLock can be a contention bottleneck on a
system with a lot of CPUs that do a lot of shared-buffer allocations
which can fulfilled by the OS buffer cache.
On Thu, 2010-12-09 at 00:39 +0100, Heikki Linnakangas wrote:
vacuum_defer_cleanup_age should take effect in
the master, not during recovery.
Hmmm, more to the point, it does take effect on the master and so there
is no need for this at all. What were you thinking? What was I? Doh.
--
On Thu, 2010-12-09 at 00:16 +0100, Heikki Linnakangas wrote:
On 09.12.2010 00:10, Heikki Linnakangas wrote:
On 08.12.2010 16:00, Simon Riggs wrote:
Heikki pointed out to me that the btree delete record processing does
not respect vacuum_defer_cleanup_age. It should.
Attached patch to
On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
Marko Tiikkaja wrote:
This is almost exactly the patch from 2010-02 without
CommandCounterIncrement()s. It's still a bit rough around the
edges and needs some more comments, but I'm posting it here
anyway.
This patch passes all
Hey Merlin,
Do you mean that due to binary transfer it is possible
to determine the type of data transfered to the backend
and therefore there is no need to pass OIDs ?
2010/12/7 Merlin Moncure mmonc...@gmail.com
On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan and...@dunslane.net
wrote:
On
On Wed, Dec 8, 2010 at 4:59 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
For 9.1, we should think of a better way to do this, perhaps using SIGUSR1
to wake up. Maybe we won't even need the trigger file anymore.
If we use SIGUSR1, the mechanism to allow the users to specify
Hey hackers@,
Is it guaranteed that name of array types in pg_type system
catalog will always be prefixed by underscore or this convention
can be changed in future ?
Thanks.
--
// Dmitriy.
On 2010-12-08 10:19 AM +0200, David Fetter wrote:
On Sun, Dec 05, 2010 at 01:33:39PM -0500, Greg Smith wrote:
So this patch was marked Ready for Committer, but a) no committer
has picked it up yet and b) Marko has made changes here that nobody
else has tested out yet that I've seen on the last.
1 - 100 of 101 matches
Mail list logo
