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.
> >>
> >> Attach
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.
--
Sim
On Wed, Dec 8, 2010 at 8:49 PM, Tom Lane wrote:
> Jeff Janes 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
>
>
Vlad Arkhipov 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 it. First I cre
Jeff Janes 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 designed so that BufFreel
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 inc
On Dec 8, 2010, at 2:07 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" 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 ti
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 follow
On Wed, Dec 8, 2010 at 12:15 PM, James Cloos wrote:
>> "JJ" == Jeff Janes 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 n
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 lat
"Kevin Grittner" 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 assign_transaction_rea
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 objections
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 ti
Tom Lane 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)
> {
>
Dimitri Fontaine 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 ALTER EXTENSION SET SC
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
didn't
"Kevin Grittner" 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 you can point me to the
"David E. Wheeler" 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
http://2ndQuadrant.f
Greg Smith 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 much everybody who
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.
Da
"David E. Wheeler" 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 : Expertise, Formation e
Tom Lane 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 mid-subtrans
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 imp
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 c
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 PLATF
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 uri_
On Dec 8, 2010, at 12:42 PM, Dimitri Fontaine wrote:
> Kineticode Billing 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
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 motivation
Kineticode Billing 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 EXTENSION command
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 the size of
On 08/12/10 21:18, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 v
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
> "JJ" == Jeff Janes 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 then writes o
"Kevin Grittner" writes:
> Florian Pflug 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 trigger you'd both document tha
On Dec 8, 2010, at 1:39 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" 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 call the co
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 long discovered
Tom Lane 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 this is too ug
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:
http://www.postgresql.org/mailpref/pgsql-hacke
Florian Pflug 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 correct
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 q
"Kevin Grittner" writes:
> Tom Lane 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 see how I can allow changes in the su
Robert Haas 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 search_path = @extschema@,
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 allowe
Tom Lane 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 weren't actually try
"Kevin Grittner" writes:
> Tom Lane 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 that only
> "LOCAL" changes are all
Tom Lane wrote:
> "Kevin Grittner" 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 stand some cleanup too.
I'll take a
On Wed, Dec 8, 2010 at 2:31 PM, Tom Lane wrote:
> Robert Haas 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/ms
Robert Haas 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 been posted to -hacke
On Wed, Dec 8, 2010 at 1:56 PM, Tom Lane wrote:
> Simon Riggs 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 =
On Wed, Dec 8, 2010 at 1:37 PM, Chris Browne wrote:
> t...@sss.pgh.pa.us (Tom Lane) writes:
>> "Kevin Grittner" writes:
>>> Robert Haas wrote:
Simon Riggs wrote:
> Note that DB2 uses the table modifier VOLATILE to indicate a
> table that has a widely fluctuating table size, for exa
"Kevin Grittner" 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 recollection is that we've
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 th
Simon Riggs 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 shouldn't change
t...@sss.pgh.pa.us (Tom Lane) writes:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
>>> Simon Riggs 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
On Wed, Dec 8, 2010 at 12:25 PM, Tom Lane wrote:
> Robert Haas 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
>> proper
"Kevin Grittner" 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 includes a new regression t
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
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 gi
Robert Haas writes:
> On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii 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
>> Postgr
Robert Haas 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 conclusion more and more
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 woul
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 pl
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 s
"Kevin Grittner" writes:
> Robert Haas wrote:
>> Simon Riggs 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 is
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii 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 optimizer and I would
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
Robert Haas wrote:
> Simon Riggs 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 is certainly a bit awkward
It wo
On Wed, Dec 8, 2010 at 4:19 AM, Dimitri Fontaine wrote:
> Robert Haas 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 t
On Wed, Dec 8, 2010 at 11:09 AM, Tom Lane wrote:
> Dmitriy Igrishin 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 :-)
>
> F
On Wed, Dec 8, 2010 at 10:19 AM, Simon Riggs wrote:
> On Tue, 2010-12-07 at 13:17 -0500, Tom Lane wrote:
>> Robert Haas 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 any
On Wed, Dec 8, 2010 at 9:52 AM, Marti Raudsepp 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.
--
Robert Ha
I wrote:
> Tom Lane 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, an
On Tue, Dec 7, 2010 at 2:06 PM, flyusa2010 fly 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 because it does
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:
O
Dmitriy Igrishin 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 belong on pgsql-hac
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 uri_unescape($_
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/
Po
On Tue, 2010-12-07 at 13:17 -0500, Tom Lane wrote:
> Robert Haas 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.
>
> Hm... I
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 Ri
Marti Raudsepp writes:
> On Tue, Dec 7, 2010 at 03:34, Tom Lane 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 de
On Wed, Dec 8, 2010 at 8:57 AM, Tatsuo Ishii 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:
> http://static.shoeisha.jp/cz/sta
On Tue, Dec 7, 2010 at 03:34, Tom Lane 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 options
are actu
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
Tim
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
> Dmitriy Igrishin writes:
> > Is it guaran
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 Andrew,
Finally convinced. Thanks!
2010/12/8 Andrew Dunstan
>
>
> 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 fut
Dmitriy Igrishin 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 (pgsql-hackers@postgresql.org)
To ma
Tom Lane 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 this
> seems lik
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
f
Magnus Hagander writes:
> On Wed, Dec 8, 2010 at 02:07, Tom Lane 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 hasn't got fdatasync), m
Tom Lane 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 mechanism entirely.
Robert Haas 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 Bints are
bad. It's
"David E. Wheeler" 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 directory con
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 crea
Hey Florian,
Thank you very much!
2010/12/8 Florian Pflug
> 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 advant
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 advantage of letting your code depend on this?
Within SQL, I suggest you writ
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
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 Wed, Dec 8, 2010 at 4:59 PM, Heikki Linnakangas
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 the event type
seems to be require
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
> On Tue, Dec 7, 2010 at 10:45 AM, Andrew Dunstan
> wrote:
> > On 12/07/2010 10:02 AM, Merlin Moncur
1 - 100 of 101 matches
Mail list logo
