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
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 wants it
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:
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;
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 RelationTruncate
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
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
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
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 call it cert,
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 I want to use
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 was just trying
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)
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 reftable ( ( column expression ) )
Reason: current FK rules do not
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
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
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 mailing
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';
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 reftable ( ( column
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
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 example I have two
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 anyone who needs it, or if
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
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
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 makes me
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 via
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, 0
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
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
planner, and it
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
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.
-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@postgresql.org
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
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)
The documentation
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
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 the time --- it
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 point
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 way it is.
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
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
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:
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(). Frankly,
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, but
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
43 matches
Mail list logo
