On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina dan...@heroku.com wrote:
Right now, as it stands, the syncrep patch will be happy as soon as
the data has been fsynced to either B or A-prime; I don't think we can
guarantee at any point that A-prime can become the leader, and feed B.
- start A`
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote:
I guess the real question is what's Peter's concrete objection to the
double-dash method?
It just looks a bit silly and error prone. And other packaging systems
have
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= anssi.kaariai...@thl.fi writes:
This has the side effect that you can also have downgrade scripts. I
don't know if this is designed or just coincidental, so thought it
would be worth
Hello.
I did:
git clone git://git.postgresql.org/git/postgresql.git cd postgresql
./configure --prefix=/home/marcin/pg91 --enable-cassert
--enable-debug make check
which gave me the attached regression.diffs
marcin@skpsms:~/postgresql$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
On Tue, Jan 25, 2011 at 5:46 PM, marcin mank marcin.m...@gmail.com wrote:
Hello.
I did:
git clone git://git.postgresql.org/git/postgresql.git cd postgresql
./configure --prefix=/home/marcin/pg91 --enable-cassert
--enable-debug make check
which gave me the attached regression.diffs
uh
On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Jan 11, 2011 at 19:51, Tom Lane t...@sss.pgh.pa.us wrote:
Seems like either one of these is fairly problematic in that you have to
have some monstrous kluge to get the
On Sun, Dec 5, 2010 at 7:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
IIRC, in old discussions of this problem we first considered allowing
clients to pull down an explicit representation of their snapshot (which
actually is an existing feature now, txid_current_snapshot()) and then
upload that
I can only look at the locales that the operating system provides. We
could conceivably make some simplifications like stripping off the
.utf8, but then how far do we go and where do we stop? Locale names
on Windows look different too. But in general, how do you suppose we
should map an
Can (should ?) unlogged tables' contents survive graceful (non-crash) shutdown?
Greetings
Marcin Mańk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Oct 30, 2010 at 6:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
3. To hash, apply the element type's hash function to each array
element. Combine these values by rotating the accumulator left
one bit at each step and xor'ing in the next element's hash value.
Thoughts? In particular, is
On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We can *not* allow the slave to replay WAL ahead of what is known
committed to disk on the master. The only way to make that safe
is the compare-notes-and-ship-WAL-back approach that Robert mentioned.
If you feel that
On Wed, Jul 14, 2010 at 5:13 PM, Robert Haas robertmh...@gmail.com wrote:
2010/7/14 Tom Lane t...@sss.pgh.pa.us:
If the combination of columns is actually interesting, there might well
be an index in place, or the DBA might be willing to create it.
Indexes aren't free, though, nor even close
Having said that, I do think we urgently need some high-level design
discussion on how sync rep is actually going to handle this issue
(perhaps on a new thread). If we can't resolve this issue, sync rep
is going to be really slow; but there are no easy solutions to this
problem in sight, so
On Wed, Jun 9, 2010 at 12:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-06-08 at 18:03 -0400, Robert Haas wrote:
OK, yes, I see what you're getting at now. There are two possible
ways to do freeze the tuples and keep the xmin: we can either
On Wed, Apr 21, 2010 at 4:12 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-04-21 at 09:51 -0400, Robert Haas wrote:
Adding an assertion isn't going to do much because it's unlikely anybody
is going to be running for 2^31 transactions with asserts enabled.
I think the assert
Hello,
I was reading the SR docs, and have the following question:
Is there a fundamental reason why archive_command etc. is required in
streaming replication mode?
Can`t setting up the standby be more like:
pg_start_streaming_backup() on the master (this will be queuing up
files in pg_xlog)
copy
On Thu, Feb 25, 2010 at 10:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
the standby needs to
fall back to the archive if it falls behind so that the WAL files it
needs have already been recycled in the master.
Oh, so the master does not have to keep track of the state
On Mon, Feb 15, 2010 at 9:36 AM, Andres Freund and...@anarazel.de wrote:
On Monday 15 February 2010 08:13:32 Tom Lane wrote:
Actually, looking closer, some of the Windows machines started failing
after the *earlier* patch to add directory fsyncs.
And not only the windows machines. Seems
On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund and...@anarazel.de wrote:
Hi Marcin,
Sounds rather unlikely to me. Its likely handled at an upper layer (vfs in
linux' case) and only overloaded when an optimized implementation is
available.
Which os do you see implementing that only on a
Yes, the issue with initdb failing is unrelated (and I have no problem
about the fs being unsupported). But fsync still DOES fail on
directories from the mount.
But I would not be that sure that eg. NFS or something like that won`t
complain.
It does not.
What if someone mounts a NFS share
A certain prominent web framework has a nasty SQL injection bug when
PG is configured with SCS. This bug is not present without SCS
(details per email for interested PG hackers). I say, hold it off.
Greetings
Marcin Mańk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Thu, Dec 10, 2009 at 3:00 AM, Robert Haas robertmh...@gmail.com wrote:
Done. Yeah, my first commit!
Great! Also, thanks for getting this in 8.4.2. Otherwise I would have
to compile this on Windows myself, which is no fun.
About the tabs vs spaces problem - I`ve decided that copying the
The current behavior of levenshtein(text,text,int,int,int) is wrong. Consider:
leki_dev=# select levenshtein('','a',2,4,5);
levenshtein
-
1
(1 row)
leki_dev=# select levenshtein('a','',2,4,5);
levenshtein
-
1
(1 row)
leki_dev=# select
also there is integer overflow:
postgres=# select levenshtein('','',1,10,1);
levenshtein
-
-1179869184
(1 row)
should we reject arguments greater than,say, 1 ?
maximum input length is 255 currently, so the maximum numbers involved
would be about
On Tue, Dec 8, 2009 at 4:10 AM, Robert Haas robertmh...@gmail.com wrote:
The current behavior of levenshtein(text,text,int,int,int) is wrong.
Consider:
Is this the same problem as bug #5098?
Yes. Exact same change, plus the shortcut evaluation (for when one of
the inputs is empty) was also
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
Proposal
* We reserve enough space on a disk block for a CRC check. When a dirty
block is written to disk we calculate and annotate the CRC value, though
this is *not* WAL
On Sat, Nov 28, 2009 at 12:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
It's not so much so-many-paths as so-many-join-relations that's killing
it. I put some instrumentation into join_search_one_level to count the
number of joinrels it was creating, and got this before getting bored:
This is
On Tue, Oct 20, 2009 at 1:21 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If the parameter is defined as the chance that a page is in cache
there is very real physical meaning to it.
We have no such parameter...
What a simple person like me would think would work is:
- call the parameter
having such blantantly unrealistic
values for random_page_cost :)
What do You think?
Greetings
Marcin Mank
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I've been thinking about this a bit, too. I've been wondering if it
might make sense to have a random_page_cost and seq_page_cost
setting for each TABLESPACE, to compensate for the fact that different
media might be faster or slower, and a percent-cached setting for each
table over top of
I thought about making it per-table***space***, but realistically I
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
This proposal is just hints by the back door, ISTM. As Tom says, there is
a justification for having it on tablespaces but not on individual tables.
If the parameter is defined as the chance that a page is in cache
there is very real physical meaning to it. And this is per-table, not
The case that ENCRYPTED
protects against is database superusers finding out other users'
original passwords, which is a security issue to the extent that those
users have used the same/similar passwords for other systems.
I just want to note that md5 is not much of a protection against this
Exactly. The application is typically going to throw a concurrent
update type of error when this happens, and we don't want magic
background operations to cause that.
I`d give up the possibility of using CTIDs in the way You explained
for an auto-debloater without blinking an eye. Maybe we
On Sat, Aug 8, 2009 at 3:07 AM, Paul Matthewsp...@netspace.net.au wrote:
IEEE754 does not allow two number X and Y, such that X!=Y and (X-Y)==0.
And since IEEE754 has been around since the 70's or 80's I think we can
start relying on its existence and behavior by now.
You are correct, I
As far as the alpha releases, I am still worried about the use of the
word alpha. I am worried someone is going to look at 8.4alpha1 and
think that represents most of the features that will be in 8.5final, and
will think the Postgres project is losing momentum. I would much rather
they be
ALTER COLUMN SET DISTINCT
feels like adding a unique constraint.
ALTER COLUMN SET STATISTICS DISTINCT ?
ALTER COLUMN SET STATISTICS NDISTINCT ?
Greetings
Marcin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Jul 9, 2009 at 5:38 AM, Noah Mischn...@leadboat.com wrote:
z
Describing in those terms illuminates much. While the concepts do suggest 2^N
worst-case planning cost, my artificial test case showed a rigid 4^N pattern;
what could explain that?
Isn`t that just so that the planner has to
Use plain oids or regclass values, not a text column, if you are trying
to store table identities.
wouldn`t oids change on dump/reload?
Greetings
Marcin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hello, List.
There are cases when GEQO returns a very bad plan in some rare
executions of a query. To decrease likehood of this happening, I
propose:
When GEQO detects that what it found is in fact a miserable plan it
restarts the search. Simple math shows that if the probability of a
bad plan
It sounds like you're proposing to compare the time spent planning to
the estimated execution time. AFAICS, those things are unrelated, so
I'm not sure what you hope to figure out by comparing them.
The idea is: If we are to spend a LOT of resources executing the
query, we might as well burn
Perhaps we should listen to the people that have said they don't want
queries cancelled, even if the alternative is inconsistent answers.
I think an alternative to that would be if the wal backlog is too
big, let current queries finish and let incoming queries wait till the
backlog gets
Marcin Mank
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
43 matches
Mail list logo
