Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
2) data type is unknown
Unfortunately, in low function is no clue what data type is really
stored in a chunks.
Do we need to know? We haven't changed the on-disk format of any data
types between 8.3 and 8.4, have we?
Yeah, there is no cha
On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Hot Standby patch, including all major planned features.
>
>
While experimenting with the patch, I noticed that sometimes the archiver
process indefinitely waits for WALInsertLock. I haven't spent much time
debugging that, b
On Sat, Nov 1, 2008 at 10:02 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> Hot Standby patch, including all major planned features.
>
>
>
I wonder if we should refactor lazy_scan_heap() so that *all* the real work
of collecting information about dead tuples happens only in
heap_page_prune(). Frankl
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <[EMAIL PROTECTED]> writes:
> On Thu, 2008-11-20 at 08:51 +0900, ITAGAKI Takahiro wrote:
>> HEAD is failed to be built on win32 mingw.
>> It requires manual 'mkdir man7' or so.
>>
>> Are there any changes in build process?
> It is probably because of this commit
Zdenek Kotala wrote:
2) data type is unknown
Unfortunately, in low function is no clue what data type is really
stored in a chunks.
Do we need to know? We haven't changed the on-disk format of any data
types between 8.3 and 8.4, have we?
The other idea that was suggested earlier is to reto
On Thu, 2008-11-20 at 08:51 +0900, ITAGAKI Takahiro wrote:
> HEAD is failed to be built on win32 mingw.
> It requires manual 'mkdir man7' or so.
>
> Are there any changes in build process?
It is probably because of this commit:
http://archives.postgresql.org/pgsql-committers/2008-11/msg00169.php
"Dann Corbit" <[EMAIL PROTECTED]> writes:
>> I think the idea that there IS a magic number is the problem.
>>
>> No amount of testing is ever going to refute the argument that, under
>> some other workload, a different value might better.
>>
>> But that doesn't amount to a reason to leave it the
On Mon, Nov 17, 2008 at 9:01 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> It is, in a later version. Apologies if you're reviewing the wrong one.
>
>
The most recent version I can find is v9, but I remember you mentioned v10
somewhere else.
Can you please confirm if v9 is the latest version and
KaiGai Kohei wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> KaiGai Kohei <[EMAIL PROTECTED]> writes:
> >>> I'll try your approash in first, as follows:
> >> This seems a vast amount of uglification to avoid adding an argument to
> >> CreateTemplateTupleDesc. We do that kind of thing all th
Bruce Momjian wrote:
Tom Lane wrote:
KaiGai Kohei <[EMAIL PROTECTED]> writes:
I'll try your approash in first, as follows:
This seems a vast amount of uglification to avoid adding an argument to
CreateTemplateTupleDesc. We do that kind of thing all the time --- it
is a simple and reliable cha
Magnus Hagander wrote:
> >> Not sure I care enough to dive into what it would actually mean. My
> >> guess is that it's very uncommon to use db_user_namespace in any of
> >> these scenarios (in fact I think it's very uncommon to use it at all,
> >> but even more uncommon in these cases)
> >
> > Th
> So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the
> T-SQL code to Postgres and got this. Thought others might find it amusing.
>
> WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
> SELECT IX, IY, X::float, Y::float, X::float, Y::float, 0
> F
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
> [EMAIL PROTECTED] On Behalf Of Robert Haas
> Sent: Wednesday, November 19, 2008 5:05 PM
> To: Bruce Momjian
> Cc: Mark Wong; Tom Lane; Heikki Linnakangas; Gregory Stark; Josh
> Berkus; Greg Smith; pgsql-hackers@postgres
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
> > I'll try your approash in first, as follows:
>
> This seems a vast amount of uglification to avoid adding an argument to
> CreateTemplateTupleDesc. We do that kind of thing all the time --- it
> is a simple and reliable change to make
> Yes, please test something. I am tired if us saying we need to increase
> default_statistics_target, but because we don't know the magic number,
> we do nothing release after release.
I think the idea that there IS a magic number is the problem.
No amount of testing is ever going to refute the
Mark Wong wrote:
> On Thu, Nov 13, 2008 at 11:53 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> >> A lot of people have suggested raising our default_statistics target,
> >> and it has been rejected because there's some O(n^2) behavior in the
> >> plann
Hello,
HEAD is failed to be built on win32 mingw.
It requires manual 'mkdir man7' or so.
Are there any changes in build process?
Or am I missing something required to build?
$ make
/bin/sh.exe: man7/.timestamp: No such file or directory
$ mkdir doc/man7<- HERE
$ make
(succeeded
Gregory Stark wrote:
> So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the
> T-SQL code to Postgres and got this. Thought others might find it amusing.
>
> WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
> SELECT IX, IY, X::float, Y::float, X::float, Y::float,
On 2008-11-19, at 21:53, Gregory Stark wrote:
So based on Graeme Job's T-SQL hack over at thedailywtf.com I
adapted the
T-SQL code to Postgres and got this. Thought others might find it
amusing.
hohoho, nice. That's even better than mine "with recursive" PI
generator :)
--
Sent vi
I wrote:
> All,
>
> This is my first patch review for PostgreSQL. I did submit a patch last
> commit fest (Boyer-Moore) so I feel I should review one this commit fest.
> I'm quite new to PostgreSQL so please don't rely on me totally. I'll do my
> best. Heikki is also reviewing this patch which make
So based on Graeme Job's T-SQL hack over at thedailywtf.com I adapted the
T-SQL code to Postgres and got this. Thought others might find it amusing.
WITH RECURSIVE Z(IX, IY, CX, CY, X, Y, I) AS (
SELECT IX, IY, X::float, Y::float, X::float, Y::float, 0
FROM (select
We are now in discussion about toast table upgrading. I try to collect ideas and
figure out how it should work and where are problems.
Overview:
-
A few weeks ago we made a decision to use convert on read. We already made a
decision how to solve problem with overflow data after conversi
Russell Smith wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >
> >> Bruce Momjian wrote:
> >>
> >>> This is not something we would typically backpatch because of the danger
> >>> of introducing some unexpected change in libpq. We can provide a patch
> >>> to anyo
Alex Hunsaker wrote:
> On Mon, Nov 17, 2008 at 05:31, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
>> Magnus Hagander escribió:
>>> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
My only concern is there is no way to specify the USER_CERT_FILE for
libpq. So if for ex
Hi there,
we got no comments on our proposal about changing GIN interface to
support multicolumn feature of GIN, see
http://archives.postgresql.org/message-id/[EMAIL PROTECTED]
for details, so here are some numbers demonstrating benefits and some
issues. Any help and feedback are welcome.
We
On Nov 19, 2008, at 9:12 AM, Josh Berkus wrote:
Folks,
Since it's too late to look at this for 8.4, can the following go on
the TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES ( ( column
express
"Rushabh Lathia" <[EMAIL PROTECTED]> writes:
> Simple select give wrong result when it uses the Bitmap Heap Scan path.
It's generally appropriate to mention which PG version you're working
with when you report a bug.
> postgres=# explain select proname from pg_proc where proname like 'my_pro1';
>
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Ibrar Ahmed" <[EMAIL PROTECTED]> writes:
>> It works fine on my machine
> Hm, a fresh checkout doesn't crash for me either any more.
It looks like a bug I fixed a week or so back.
regards, tom lane
--
Sent via pgsql-hackers m
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Fixed, but my gcc didn't emit such message.
That's not actually too surprising. gcc's "uninitialized variable"
analysis is per-function, which means that its scope can change
depending on how much inlining the compiler chooses to do.
So you can see diff
"Ibrar Ahmed" <[EMAIL PROTECTED]> writes:
> Hi,
>
> It works fine on my machine
Hm, a fresh checkout doesn't crash for me either any more.
Hopefully it didn't just hide the problem because I stupidly just trashed the
install that was exhibiting the problem.
--
Gregory Stark
EnterpriseDB
Folks,
Since it's too late to look at this for 8.4, can the following go on the
TODO list?
Referential Integrity
[] Allow creation of FKs targeting unique expression indexes on the
referenced table. Syntax: REFERENCES ( ( column expression ) )
Reason: current FK rules do not allow creati
Hi,
It works fine on my machine
[EMAIL PROTECTED]:/usr/local/pgsql/bin$ ./psql postgres
psql (8.4devel)
Type "help" for help.
postgres=# SELECT res, * FROM (
SELECT
'foo'||i AS test, i AS res
FROM (VALUES (1)) AS x(i)
U
On Mon, Nov 17, 2008 at 03:04, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Alex Hunsaker wrote:
>> On Sat, Nov 15, 2008 at 17:39, Tom Lane <[EMAIL PROTECTED]> wrote:
>>> 2. Root cert file present but we fail to load it: FATAL is probably okay
>>> here, but not with that hint message.
>>
>> Err, I
On Mon, Nov 17, 2008 at 05:31, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> Magnus Hagander escribió:
>> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>
>>> My only concern is there is no way to specify the USER_CERT_FILE for
>>> libpq. So if for example I have two users that
On Mon, Nov 17, 2008 at 01:01, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> On 16 nov 2008, at 01.00, "Alex Hunsaker" <[EMAIL PROTECTED]> wrote:
>> Would cncert be a better auth_method name? As later we might have
>> different types of ssl client cert authentication??
>
> If/when I'd rather still c
Hi Heikki,
I will try to make more tests.
I still quite did not get what the big deal was if an ON COMMIT DELETE
ROWS temp table was created inside a transaction.
Why the new checks you are doing in lock.c would not work with dropped
temp tables? Could it be possible to drop the lock as soon as
I haven't looked into what's causing it yet but...
postgres=# SELECT res, * FROM (
SELECT 'foo'||i AS test, i AS res
FROM (VALUES (1)) AS x(i)
UNION ALL
SELECT 'foo'||i, i
FROM (VALUES (2)) AS x(i)
) AS x;
server closed the connection unexpe
Heikki Linnakangas wrote:
> Rethink the way FSM truncation works. Instead of WAL-logging FSM
> truncations in FSM code, call FreeSpaceMapTruncateRel from smgr_redo. To
> make that cleaner from modularity point of view, move the WAL-logging one
> level up to RelationTruncate, and move RelationTrunc
Analysis:
While debugging bitmap heap scan (BitmapHeapNext function) found that first
we perform the underlying index scan and then iterate over bitmap. Now while
iterating, we execute ExecQual only if tbmres->recheck is true. And for the
query tbmres->recheck is false.
But from the que
Simple select give wrong result when it uses the Bitmap Heap Scan path.
postgres=# CREATE OR REPLACE FUNCTION my_exec_im_test_func(i integer)
RETURNS integer AS $$
BEGIN
RETURN i + 1;
END;
$$ LANGUAGE plpgsql;
CREATE FUNCTION
postgres=# set enable_seqscan=off;
SET
Fixed, but my gcc didn't emit such message.
The patch mentioned in the subject leaves this compiler warning:
tsvector_op.c: In function ‘insertStatEntry’:
tsvector_op.c:815: warning: ‘res’ may be used uninitialized in this
function
--
Teodor Sigaev E-mail: [
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
>> Bruce Momjian wrote:
>>
>>> This is not something we would typically backpatch because of the danger
>>> of introducing some unexpected change in libpq. We can provide a patch
>>> to anyone who needs it, or if the community
The patch mentioned in the subject leaves this compiler warning:
tsvector_op.c: In function ‘insertStatEntry’:
tsvector_op.c:815: warning: ‘res’ may be used uninitialized in this function
I took a quick look but it is not immediately obvious whether the
compiler might actually have a point here.
43 matches
Mail list logo
