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
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
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 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
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 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
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
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
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
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
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 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 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
> 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
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 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, 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 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 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
> 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, 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
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.
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
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
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
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
> 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
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
> 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
> 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
> 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
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
> 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
> 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
per-t
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".
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
> 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
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
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
> 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
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
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
