On Fri, Feb 25, 2011 at 9:14 AM, Daniel Farina 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` up, replicat
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut 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 been doin
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane wrote:
> =?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= 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 mentioning.
>> The worst case is that
On Tue, Jan 25, 2011 at 5:46 PM, marcin mank 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
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-gn
On Tue, Jan 11, 2011 at 8:07 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
>>> Seems like either one of these is fairly problematic in that you have to
>>> have some monstrous kluge to get the backup_label file to appear with
>>> the right name i
On Sun, Dec 5, 2010 at 7:28 PM, Tom Lane 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 again to become
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
> 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
On Sat, Oct 30, 2010 at 6:21 PM, Tom Lane 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 anyone aware
On Tue, Sep 7, 2010 at 5:17 PM, Tom Lane 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 decoupling WAL applic
On Wed, Jul 14, 2010 at 5:13 PM, Robert Haas wrote:
> 2010/7/14 Tom Lane :
>> 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 to it.
>
> Still, I think we shou
> 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,
On Wed, Jun 9, 2010 at 12:35 AM, Tom Lane wrote:
> Simon Riggs 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 rely on
>>> the PD_ALL_VISIBLE p
On Wed, Apr 21, 2010 at 4:12 PM, Simon Riggs 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 is a g
On Thu, Feb 25, 2010 at 10:08 AM, Heikki Linnakangas
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 of the
standbys. That`s a nice des
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
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 sha
On Mon, Feb 15, 2010 at 11:02 AM, Andres Freund 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 part of the fil
On Mon, Feb 15, 2010 at 9:36 AM, Andres Freund 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 sensible to add a c
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 ma
On Thu, Dec 10, 2009 at 3:00 AM, Robert Haas 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 patch
from a remote machi
On Tue, Dec 8, 2009 at 4:10 AM, Robert Haas 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 wrong. I fixed th
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 1*255
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 levenshtein
On Mon, Nov 30, 2009 at 9:27 PM, Heikki Linnakangas
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 logged.
>
> Imagine this:
> 1.
On Sat, Nov 28, 2009 at 12:04 AM, Tom Lane 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 pretty off-topic
On Tue, Oct 20, 2009 at 1:21 AM, Tom Lane 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 "cached_probability".
> 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
per-t
> 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
> 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 t
planner works while 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
> 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 thi
> 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
On Sat, Aug 8, 2009 at 3:07 AM, Paul Matthews 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 think, though this do
> 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
> the
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:
http://www.postgresql.org
On Thu, Jul 9, 2009 at 5:38 AM, Noah Misch 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 examine O(2^N
> 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:
http://www.postgresql.org/ma
> 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 bur
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 f
> 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 small
7;blessing' from the Postgresql community?
Greetings
Marcin Mank
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
43 matches
Mail list logo
