* Dann Corbit wrote:
The PostgreSQL installer for Windows 64 appears to be broken for Microsoft
Windows Server 2012 Standard.
Even after uninstalling, removing the entire postgresql directory structure,
and running the installer as administrator, I get this error:
"fixing permissions on exis
CREATE MATERIALIZED VIEW statement ends up being CREATE TABLE AS statement
underneath with table type matview. In that case, why don't I see special
treatment only for materialized view and not CTAS in general, which allows
column names to specified like the case in the bug reported.
On Fri, Nov
On Fri, Nov 1, 2013 at 12:20 AM, Tom Lane wrote:
> Amit Kapila writes:
>> On Thu, Oct 31, 2013 at 2:41 AM, Gurjeet Singh wrote:
>>> Just a small patch; hopefully useful.
>
>> This is valid saving as we are filling array ListenSocket[] in
>> StreamServerPort() serially, so during ClosePostmasterP
On Thu, Oct 31, 2013 at 7:48 PM, Heikki Linnakangas
wrote:
> On 31.10.2013 16:43, Robert Haas wrote:
>> There should be no cases where the main shared memory
>> segment gets cleaned up and the dynamic shared memory segments do not.
>
> 1. initdb -D data1
> 2. initdb -D data2
> 3. postgres -D data1
Amit Kapila writes:
> On Thu, Oct 31, 2013 at 2:41 AM, Gurjeet Singh wrote:
>> Just a small patch; hopefully useful.
> This is valid saving as we are filling array ListenSocket[] in
> StreamServerPort() serially, so during ClosePostmasterPorts() once if
> it encountered PGINVALID_SOCKET, it is v
On Thu, Oct 31, 2013 at 2:41 AM, Gurjeet Singh wrote:
> Just a small patch; hopefully useful.
This is valid saving as we are filling array ListenSocket[] in
StreamServerPort() serially, so during ClosePostmasterPorts() once if
it encountered PGINVALID_SOCKET, it is valid to break the loop.
Althou
I wrote:
> So what I'm thinking we should do is internally translate SET TIMEZONE
> with an interval value into a POSIX-style zone name in the above format,
> and then just flush HasCTZSet/CTimeZone and all the special case logic
> around them.
Attached is a set of proposed patches for this.
> 1.
The PostgreSQL installer for Windows 64 appears to be broken for Microsoft
Windows Server 2012 Standard.
Even after uninstalling, removing the entire postgresql directory structure,
and running the installer as administrator, I get this error:
"fixing permissions on existing directory C:/Progra
On Thu, Oct 31, 2013 at 10:22 PM, Kevin Grittner wrote:
> "t.katsumata1...@gmail.com" wrote:
> If there are no objections I'll apply this within a few days.
I am not sure that adding a boolean flag introducing a concept related
to matview inside checkRuleResultList is the best approach to solve
t
On 31.10.2013 16:43, Robert Haas wrote:
Let me say this again: the dynamic shared memory code *does* clean up
after itself. If you kill -9 the postmaster and all of its children,
you'll orphan the main shared memory segment and any dynamic shared
memory segments that exist. There is nothing we
"t.katsumata1...@gmail.com" wrote:
> I'm testing the Materialized View.
> When I've tried to create materialized view with specified
> column_name, I got an ERROR.
>
> example:
> - Creating original table
> CREATE TABLE t ( i int );
>
> - Creating materialized view with column_name
> CREATE MATER
In postgres 9.2 I have a function that is relatively expensive. When I
write a query such as:
select expensive_function(o.id),o.* from offeirng o where valid='Y' order
by name limit 1;
the query runs slow and appears to be running the function on each ID,
which in this case should be totally unn
On 10/31/2013 03:46 PM, Antonin Houska wrote:
> Can the change be as simple as this or do I neglect anything?
Well, the example of outer join is wrong. Instead I think query
SELECT *
FROMtab1 a
LEFT JOIN
tab1 b
ON b.i = ANY (
SELECT tab2.k
Joe Love wrote:
> In postgres 9.2 I have a function that is relatively expensive.
What did you specify in the COST clause on the CREATE FUNCTION
statement?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hacke
In postgres 9.2 I have a function that is relatively expensive. When I
write a query such as:
select expensive_function(o.id),o.* from offeirng o where valid='Y' order
by name limit 1;
the query runs slow and appears to be running the function on each ID,
which in this case should be totally unn
Bruce Momjian wrote:
> On Wed, Oct 16, 2013 at 11:49:13AM -0700, Kevin Grittner wrote:
>> Bruce Momjian wrote:
>>
>>> I am seeing this compiler warning in git head:
>>>
>>> rowtypes.c: In function 'record_image_cmp':
>>> rowtypes.c:1433: warning: 'cmpresult' may be used
>>> uninitial
The post was made before I subscribed to the mailing list, so posting my
review separately. The link to the original patch mail is
http://www.postgresql.org/message-id/CAB8KJ=jS-Um4TGwenS5wLUfJK6K4rNOm_V6GRUj+tcKekL2=g...@mail.gmail.com
> Hi,
>
> This patch implements the following TODO item:
>
>
On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin wrote:
> I think using /dev/urandom directly would be surprising. At least it would
> have probably have taken me a while to figure out what was depleting the
> entropy pool here.
Perhaps so; a bigger problem IMHO is that it's not portable. I think
On Thu, Oct 31, 2013 at 2:54 PM, Tom Lane wrote:
> I wrote:
>> Actually, it strikes me there might be another way to do this, which is to
>> get rid of HasCTZSet/CTimeZone entirely in favor of consing up some pseudo
>> pg_tz structure that represents the desired semantics when we want a
>> "brute
On Thu, Oct 31, 2013 at 2:44 PM, Garick Hamlin wrote:
> On Thu, Oct 31, 2013 at 01:59:04PM -0400, Robert Haas wrote:
>> On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin wrote:
>> > On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
>> >> From: "Robert Haas"
>> >>> ISTM that the biggest proble
I wrote:
> Actually, it strikes me there might be another way to do this, which is to
> get rid of HasCTZSet/CTimeZone entirely in favor of consing up some pseudo
> pg_tz structure that represents the desired semantics when we want a
> "brute force" setting.
After some study of the pgtz code, it t
On Thu, Oct 31, 2013 at 01:59:04PM -0400, Robert Haas wrote:
> On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin wrote:
> > On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
> >> From: "Robert Haas"
> >>> ISTM that the biggest problem is that we don't have a random number
> >>> generator which
On Thu, Oct 31, 2013 at 9:16 AM, Mitsumasa KONDO
wrote:
> I'l like to add fallocate() system call to improve sequential read/write
> peformance. fallocate() system call is different from posix_fallocate() that
> is zero-fille algorithm to reserve continues disk space. fallocate() is
> almost less
On Thu, Oct 31, 2013 at 1:02 PM, Garick Hamlin wrote:
> On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
>> From: "Robert Haas"
>>> ISTM that the biggest problem is that we don't have a random number
>>> generator which generates enough bits of randomness to implement
>>> uuid_generate_v3.
On Thu, Oct 31, 2013 at 6:36 AM, Mitsumasa KONDO
wrote:
> Hi,
>
> I create pgbench patch that adding accurate option in benchmark, and submit
> it in CF3.
> It is simple option to get more accurate benchmark result and to avoid miss
> benchmark result in pgbench.
>
> Logic of this option is under
Alvaro Herrera writes:
> ... So, perhaps, instead of having the code
> check session_timezone explicitely, have the caller pass it down.
> This consideration probably shouldn't drive a backpatchable fix,
> however.
Well, it's impossible to do that in a back-patchable way, I'm afraid,
because wou
I wrote:
> Kyotaro HORIGUCHI writes:
>> Unique indexes can sort the tuples in corresponding tables
>> prefectly. So this query might can use index.
BTW, how much of any of this is correct if the "unique" index contains
multiple NULL values? We might need to restrict the optimization(s)
to cases
Tom Lane wrote:
> I think that we should change this function to follow the API convention
> used by timestamp2tm(), namely that one passes a NULL pointer if one
> would like session_timezone/HasCTZSet/CTimeZone to control the result.
> A non-null pointer should mean to use that zone specification
On Thu, Oct 31, 2013 at 09:54:14PM +0900, MauMau wrote:
> From: "Robert Haas"
>> ISTM that the biggest problem is that we don't have a random number
>> generator which generates enough bits of randomness to implement
>> uuid_generate_v3. I think relatively few people would cry if we
>> didn't sup
DetermineTimeZoneOffset thinks that if the passed pg_tz parameter is
equal to session_timezone, it should pay attention to HasCTZSet/CTimeZone
and allow those to override the pg_tz. The folly of this is revealed by
bug #8572, wherein timestamptz input that explicitly specifies a timezone
name is t
So far, a suquery of ANY sublink located in WHERE/ON clause can't
reference vars exactly one level up, as long as pull-up into the join
tree is expected. Now that we have LATERAL subqueries (there seem to be
no specifics of SEMI JOIN when it comes to parameterization etc), I
think this restriction
On Thu, Oct 31, 2013 at 10:59 AM, Tom Lane wrote:
> However, if the index is unique, wouldn't
> scanning the index produce data that actually satisfies the longer sort
> key? It doesn't matter what the values of c,d are if there are no
> duplicates in the a,b columns. So maybe as a separate pat
SP-GiST has a bug during creation:
% create table ranges as select int4range( (random()*5)::int,
(random()*5)::int+5) as range
from generate_series(1,100) x;
% create index ranges_range_spgist_idx on ranges using spgist(range);
ERROR: unexpected spgdoin
From: "MauMau"
I thought the same situation could happen as in
destroy_tablespace_directories(), but it doesn't seem to apply on second
thought. Revised patch attached, which is very simple based on compile
time
check.
Sorry, I was careless to leave an old comment. Please use this version.
Kyotaro HORIGUCHI writes:
> Unique indexes can sort the tuples in corresponding tables
> prefectly. So this query might can use index.
>> uniquetest=# create table t (a int, b int, c int, d text);
>> uniquetest=# create unique index i_t_pkey on t(a, b);
>> uniquetest=# insert into t
>> (select a
CommitTransaction() and AbortTransaction() both do much work, and large
portions of that work either should not or must not throw errors. An error
during either function will, as usual, siglongjmp() out. Ordinarily,
PostgresMain() will regain control and fire off a fresh AbortTransaction().
The c
On Thu, Oct 31, 2013 at 10:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund
>> wrote:
>>> On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
$PGDATA, the shared me
On 2013-10-31 10:29:17 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund
> > wrote:
> >> On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
> >>> Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
> >>> $PGDATA, the shared me
Robert Haas writes:
> On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund wrote:
>> On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
>>> Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
>>> $PGDATA, the shared memory segment is leaked until next reboot?
>> Our main shared
Robert Haas escribió:
> So, does that mean we're good to go?
Looks fine to me ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
From: "Andrew Dunstan"
Why are you making this a runtime check instead of a compile time check?
I thought the same situation could happen as in
destroy_tablespace_directories(), but it doesn't seem to apply on second
thought. Revised patch attached, which is very simple based on compile tim
On 10/31/2013 08:40 AM, MauMau wrote:
> Hello,
>
> I've found and fixed a bug that causes recovery (crash recovery, PITR)
> to fail. Please find attached the patch against HEAD.
>
>
> [Bug]
> To reproduce the problem, do the following on Windows:
>
> 1. pg_ctl start
> 2. CREATE TABLESPACE tbs LOCA
On 10/30/13, 12:43 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> At this point, I think we need to consider ossp-uuid as dead code.
>
> Yeah, but what shall we replace it with?
One possibility:
https://github.com/petere/pglibuuid
Not sure whether that has a chance of working on Windows.
--
Hi,
I'l like to add fallocate() system call to improve sequential read/write
peformance. fallocate() system call is different from posix_fallocate()
that is zero-fille algorithm to reserve continues disk space. fallocate()
is almost less overhead alogotithm to reserve continues disk space than
pos
From: "Robert Haas"
ISTM that the biggest problem is that we don't have a random number
generator which generates enough bits of randomness to implement
uuid_generate_v3. I think relatively few people would cry if we
didn't support uuid_generate_v1(), and the others all look simple
enough, prov
On 10/29/2013 04:15 PM, naman.iitb wrote:
> So is there a way to populate manually IndexStmt-->whereClause
Unless you have an _extremely_ compelling reason, you should probably
just use the SPI routines to execute a CREATE INDEX command.
--
Craig Ringer http://www.2ndQuadrant
On 2013-10-31 08:22:14 -0400, Robert Haas wrote:
> On Wed, Oct 30, 2013 at 5:32 PM, Tom Lane wrote:
> > "MauMau" writes:
> > Note the lack of enthusiasm for taking on maintainership of the OSSP
> > code. Pushing it into core would mean that we're buying into that
> > maintainership, hook line an
naman.iitb wrote:
> An example of partial index that i need is if my My table1 schema
> is (a int ,b int ,c int)
>
> index on c where a is null, b is null and c is not null
Your question is not very clear, but perhaps you are looking for
something like this:
CREATE INDEX index1 ON table1 (c)
Hello,
I've found and fixed a bug that causes recovery (crash recovery, PITR) to
fail. Please find attached the patch against HEAD.
[Bug]
To reproduce the problem, do the following on Windows:
1. pg_ctl start
2. CREATE TABLESPACE tbs LOCATION 'some_tblspc_path';
3. pg_ctl stop -mi
4. pg_ctl
On Wed, Oct 30, 2013 at 5:32 PM, Tom Lane wrote:
> "MauMau" writes:
>> From: "Tom Lane"
>>> Yeah, but what shall we replace it with? And can we preserve the
>>> API contrib/uuid-ossp offers? (Maybe we shouldn't even try, but
>>> just deprecate that module and start fresh.)
>
>> Would it be wel
On Thu, Oct 31, 2013 at 1:44 AM, Asif Naeem wrote:
> On Thu, Oct 31, 2013 at 10:17 AM, Amit Kapila
> wrote:
>>
>> On Tue, Oct 29, 2013 at 12:46 PM, Naoya Anzai
>> wrote:
>> > Hi Sandeep
>> >
>> >> I think, you should change the subject line to "Unquoted service path
>> >> containing space is vu
On Thu, Oct 31, 2013 at 5:50 AM, Andres Freund wrote:
> On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
>> Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
>> $PGDATA, the shared memory segment is leaked until next reboot? I find that
>> unacceptable. There are many s
On Thu, Oct 31, 2013 at 7:54 PM, Etsuro Fujita
wrote:
> Hi,
>
> I think that lossy-heap-block information for a bitmap heap scan, not just
> "Rows
> Removed by Index Recheck" information, would also be a clue used to tune
> work_mem for better performance especially when the bitmap heap scan uses
On 2013-10-29 02:29:03 +0100, Andres Freund wrote:
> 3. valgrind gets floating point computations for
> exp(larger_negative_double) wrong and returns the wrong error message:
>
> regression=# SELECT exp(-808.3::float8);
> ERROR: value out of range: overflow
>
> exp sets errno=ERANGE and returns
Scan on demo_idx (cost=0.00..2690.09 rows=105766 width=0)
(actual time=22.821..22.821 rows=100047 loops=1)
Index Cond: ((col2 >= 0.01::double precision) AND (col2 <= 0.02::double
precision))
Total runtime: 1129.334 ms
(7 rows)
Comments welcome.
Thanks,
Best regards,
Etsuro Fujit
Hello, This is the last episode of the 'dance with indices'?
series.
Unique indexes can sort the tuples in corresponding tables
prefectly. So this query might can use index.
> uniquetest=# create table t (a int, b int, c int, d text);
> uniquetest=# create unique index i_t_pkey on t(a, b);
> uni
Hello, This patch might be too complicated (and seems somewhat ad
hoc) for the gain, but more index usage for this kind of
operation should be worth doing.
Currently, PostgreSQL ignores from the very first the availablity
of indexes for UNION. Sorting and SeqScan is choosed as follows,
* EX.1
> u
Hi,
I create pgbench patch that adding accurate option in benchmark, and submit
it in CF3.
It is simple option to get more accurate benchmark result and to avoid miss
benchmark result in pgbench.
Logic of this option is under following.
1. execute cluster command to sort records.
2. execute c
Hi,
On 2013-10-31 11:33:28 +0200, Heikki Linnakangas wrote:
> Wait, that sounds horrible. If you kill -9 the server, and then rm -rf
> $PGDATA, the shared memory segment is leaked until next reboot? I find that
> unacceptable. There are many scenarios where you never restart postmaster
> after a c
On 30.10.2013 18:52, Robert Haas wrote:
Here's a short summary of what I posted back in August: at system
startup time, the postmaster creates one dynamic shared segment,
called the control segment. That segment sticks around for the
lifetime of the server and records the identity of any *other*
Gavin Flower-2 wrote
> How about being able to mark indexes:
> 'MEMORY ONLY' to make them not go to disk
> and
> 'PERSISTENT | TRANSIENT' to mark if they should be recreated on
> machine bootup?
I would love that. But:
1) I'd like to make some tests with a "memory drive", and confirm t
Jeff Janes wrote
> True, but that is also true of indexes created in bulk. It all has to
> reach disk eventually--
> [...]
> If the checkpoint interval is as long as the partitioning period, then
> hopefully the active index buffers get re-dirtied while protected in
> shared_buffers, and only get
62 matches
Mail list logo
