In pg_config.h:405 this is defined:
/* Define to 1 if you have the strings.h header file. */ #define
HAVE_STRINGS_H 1
However, Visual Studio 2005 does not include this file. For a
workaround I simply added it but that's a bit of hack.
Ah, so even though you are using MSVC,
Tom Lane wrote:
If we did this then RI checks would no longer be subvertible by rules
or user triggers.
Stephan Szabo writes:
I don't think that it'd really help because it's the actions that are
generally subvertible not the checks and since those are looking at the
potentially not indexed
Tom Lane wrote:
Not sure if we should try to do anything about this --- if the file is
not there, it isn't going to help a lot for pg_config to print out where
it should have been, so really there's not much functionality loss
involved here.
A check if the GetShortPathName produces an empty
Hi all!
while playing on a new box i noticed that postgresql does not seem to be
able to cope with very large settings for maintenance_work_mem.
For a test I created a single table with 5 integer columns containing
about 1,8B rows 8(about 300M distinct values in the column I want to index):
Ühel kenal päeval, N, 2006-03-02 kell 22:15, kirjutas Bruce Momjian:
Is there still interst in this idea for TODO?
Just to voice my support - Yes, I think that being able to set lower
thresolds for TOAST is very useful in several cases.
Also getting rid of toast index and start using ctids
On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
Also getting rid of toast index and start using ctids directly would be
a big bonus.
When using direct ctids we could use either ctid chains or some sort of
skiplist for access to N-th TOAST chunk.
I suppose this would mean that
On Sat, Mar 04, 2006 at 01:16:55AM -0500, Tom Lane wrote:
What's bugging me about it is that the proposed syntax wedges a bunch
of index-access-method-specific parameters into what ought to be an
access-method-agnostic syntax; and furthermore does it by adding more
grammar keywords, something
Stefan Kaltenbrunner wrote:
Hi all!
while playing on a new box i noticed that postgresql does not seem to be
able to cope with very large settings for maintenance_work_mem.
For a test I created a single table with 5 integer columns containing
about 1,8B rows 8(about 300M distinct values
On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
forgot to mention that this is 8.1.3 compiled from source. Further
testing shows that not only CREATE INDEX has some issue with large
maintenance_work_mem settings :
what does it show:
cat /proc/sys/kernel/shmmax
?
depesz
hubert depesz lubaczewski wrote:
On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
forgot to mention that this is 8.1.3 compiled from source. Further
testing shows that not only CREATE INDEX has some issue with large
maintenance_work_mem settings :
what does it show:
cat
Stefan Kaltenbrunner wrote:
hubert depesz lubaczewski wrote:
On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
forgot to mention that this is 8.1.3 compiled from source. Further
testing shows that not only CREATE INDEX has some issue with large
maintenance_work_mem settings :
what
Michael Paesold [EMAIL PROTECTED] writes:
B (id) references A (id), with ON DELETE CASCADE
Usually deleting a row from A will cause all referencing rows in B to be
deleted, too. Nevertheless B has a BEFORE DELETE trigger check_delete that
checks if a row of B may be deleted or not. I.e. it
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
Also getting rid of toast index and start using ctids directly would be
a big bonus.
When using direct ctids we could use either ctid chains or some sort of
skiplist for access to
Tom Lane writes:
Michael Paesold [EMAIL PROTECTED] writes:
Will this trigger still be called, so it can abort the delete?
We'd certainly still call triggers and check row-level constraints,
and any error would abort the whole statement (leaving A unmodified).
The case that I think we'd
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Mar 04, 2006 at 01:16:55AM -0500, Tom Lane wrote:
What's bugging me about it is that the proposed syntax wedges a bunch
of index-access-method-specific parameters into what ought to be an
access-method-agnostic syntax; and furthermore
Michael Glaesemann [EMAIL PROTECTED] writes:
Just to check, are you referring to constraint triggers here?
No, I don't wish to remove constraint triggers. I would like to see
them become a better-documented, better-supported feature, which might
require some changes ... I don't recall why we
Stefan Kaltenbrunner wrote:
hubert depesz lubaczewski wrote:
On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
forgot to mention that this is 8.1.3 compiled from source. Further
testing shows that not only CREATE INDEX has some issue with large
maintenance_work_mem settings :
what
Stefan Kaltenbrunner wrote:
foo=# set maintenance_work_mem to 200;
SET
foo=# VACUUM ANALYZE verbose;
INFO: vacuuming information_schema.sql_features
ERROR: invalid memory alloc request size 204798
Just an FYI, I reported a similar problem on my 8.0.0 database a few
weeks ago. I
Michael Paesold wrote:
Stefan Kaltenbrunner wrote:
hubert depesz lubaczewski wrote:
On 3/4/06, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote:
forgot to mention that this is 8.1.3 compiled from source. Further
testing shows that not only CREATE INDEX has some issue with large
Magnus Hagander wrote:
In pg_config.h:405 this is defined:
/* Define to 1 if you have the strings.h header file. */ #define
HAVE_STRINGS_H 1
However, Visual Studio 2005 does not include this file. For a
workaround I simply added it but that's a bit of hack.
Ah, so
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
not that I think it is related to the problem at all. It looks like I'm
hitting the MaxAllocSize Limit in src/include/utils/memutils.h.
just tried to increase this limit to 4GB (from the default 1GB) and this
seems to help a fair bit.
s/help a
Um, is WIN32_CLIENT_ONLY really defined when you're
building a backend
extension? That seems wrong.
Well, it is defined:
#if defined(_MSC_VER) || defined(__BORLANDC__)
#define WIN32_CLIENT_ONLY
#endif
Oops. I obviously forgot all about that :-)
The whole
Magnus Hagander [EMAIL PROTECTED] writes:
The problem here is that the backend is built with mingw but the
extension with msvc.
I don't think that it's very reasonable to expect that to work.
The two compilers very likely have different rules for struct
packing, to take just the first gotcha.
Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
not that I think it is related to the problem at all. It looks like I'm
hitting the MaxAllocSize Limit in src/include/utils/memutils.h.
just tried to increase this limit to 4GB (from the default 1GB) and this
seems to help a
Has anyone else been finding the recent behavior of CVS-tip psql
to be a disimprovement? I've gotten sufficiently annoyed with it
that I'm ready to propose reverting this patch:
2006-02-11 16:55 momjian
* src/bin/psql/: help.c, input.c, input.h, mainloop.c, prompt.c,
Tom Lane [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] writes:
The problem here is that the backend is built with mingw but the
extension with msvc.
I don't think that it's very reasonable to expect that to work.
The two compilers very likely have different rules for
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
Tom Lane wrote:
The sorting code probably needs a defense to keep it from trying to
exceed MaxAllocSize for the SortObject array; AFAIR there is no such
consideration there now, but it's easily added. I'm not sure where your
VACUUM failure is
Greg Stark [EMAIL PROTECTED] writes:
Well that sort of stuff is supposed to be covered by the ABI. Consider that if
it didn't then you wouldn't be able to use any of the standard libraries
without recompiling them for each compiler since a number of standard library
APIs depend on structs like
Hi everyone,
Thanks for the feedback. The reason for building extensions with MSVC
on windows is to get access to the Micrsoft debugging tools since as
far as I can see MingW/GDB cannot debug dynamically loaded dlls on the
Windows platform (or at least I haven't succeeded at doing it).
On Sat, Mar 04, 2006 at 12:08:25PM -0500, Tom Lane wrote:
Comments?
I generally do not use psql in this manner, because I've found it
to be annoying before the change. After the change, from what you
describe, I too would find it annoying still.
For me, I prefer the interactive behaviour of
Adding a new partition is fairly simple, particularly if you don't care
about writing RULEs to direct data into it and can rely on a bulk loader
to figure that part out.
Removing a partition, on the other hand, is currently impossible to do
without blocking selects against the table as a whole.
Ühel kenal päeval, L, 2006-03-04 kell 10:31, kirjutas Tom Lane:
Martijn van Oosterhout kleptog@svana.org writes:
On Sat, Mar 04, 2006 at 12:15:46PM +0200, Hannu Krosing wrote:
Also getting rid of toast index and start using ctids directly would be
a big bonus.
When using direct ctids we
Tom Lane wrote:
At a minimum this code has to be fixed to understand the difference
between backslash commands and SQL lines, and not combine them in
history entries; otherwise we should revert it. I'm leaning to revert
since I haven't actually seen a case where pulling back multiple lines
Ühel kenal päeval, L, 2006-03-04 kell 13:16, kirjutas Rod Taylor:
Adding a new partition is fairly simple, particularly if you don't care
about writing RULEs to direct data into it and can rely on a bulk loader
to figure that part out.
Removing a partition, on the other hand, is currently
While playing around with large work_mem(or in that case a bit insane)
and maintenance_work_mem settings I noticed that EXPLAIN behaves quite
weird:
foo=# set work_mem to 20;
SET
Time: 0.187 ms
foo=# explain select count(*) from testtable2 group by a;
QUERY
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
forgot to mention that this is 8.1.3 compiled from source.
See the discussion starting here:
http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php
I was following this thread - and it was partly a reason why I'm playing
with
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
it looks like that postgresql is actually allocating the memory for the
hashtable of the HashAggregate which is a bit unexpected for a plain
EXPLAIN.
Not really. EXPLAIN runs plan setup (ExecutorStart).
regards, tom lane
Michael Paesold wrote:
When you edit a multiline function in zsh, you can easily press Control-C,
then type man zsh, return, and press up to continue editing the
function as it was left when you pressed Control-C.
Not sure about zsh's Ctrl-C, but in bash I press Esc-# and a # is
prepended
Alvaro Herrera wrote:
Michael Paesold wrote:
When you edit a multiline function in zsh, you can easily press
Control-C,
then type man zsh, return, and press up to continue editing the
function as it was left when you pressed Control-C.
Not sure about zsh's Ctrl-C, but in bash I press
Hello list,
I would like to be able to send the HeapTuple returned
by ExecFetchSlotTuple() over the network (socket) to
another postmaster process that's waiting for it. I
don't need to decode it, just send bytes.
My question, and I am not a DB expert, I just deal
with raw data. What other
No. Here is the offending SP:
CREATE OR REPLACE FUNCTION update_my_cache() RETURNS void AS '
BEGIN
TRUNCATE TABLE my_cache_table;
INSERT INTO my_cache_table SELECT * FROM
get_my_stuff_to_fill_cache_table();
RETURN;
END
' LANGUAGE plpgsql;
I've checked the SP
TRUNCATE is another command that takes an access exclusive lock.
The whole SP takes about 10 seconds to run total. The TRUNCATE command
only takes less than a second. However, the access exclusive lock is
held throughout the entire SP, not just during the execution of the
TRUNCATE command.
First of all, thank you very much. I changed TRUNCATE to DELETE FROM
and my problem as been fixed.
Is there any way to override that behavior? I know you can explicitly
lock tables, can you explicitly unlock tables?
Just to be clear, once I run a TRUNCATE command inside an SP, that
table that it
Mon Nsi wrote:
Hi,
My question, and I am not a DB expert, I just deal
with raw data. What other information do I need to
include from struct HeapTupleData in order for that
data to make sense on the other end (to rebuild a
HeapTuple from it).
I understand that:
data_address =
Tom Lane wrote:
Has anyone else been finding the recent behavior of CVS-tip psql
to be a disimprovement?
Another minor issue is that \s doesn't show copy-pastable things.
For example:
alvherre=# select 1
alvherre-# union all
alvherre-# select 2;
?column?
--
1
2
(2
Alvaro Herrera [EMAIL PROTECTED] writes:
Michael Paesold wrote:
When you edit a multiline function in zsh, you can easily press Control-C,
then type man zsh, return, and press up to continue editing the
function as it was left when you pressed Control-C.
Not sure about zsh's Ctrl-C, but in
Folks,
I was just building something and noticing the peculiar structure we've
given to arguments to trigger procedures. Instead of declaring them
normally, we pass them through the variables TG_NARGS and TG_ARGV[]. This
is inconsistent with the entire rest of Postgres, as well as making it
Josh Berkus said:
Folks,
I was just building something and noticing the peculiar structure we've
given to arguments to trigger procedures. Instead of declaring them
normally, we pass them through the variables TG_NARGS and TG_ARGV[].
This is inconsistent with the entire rest of Postgres,
Andrew,
It does have the advantage that you can call a single trigger function
with variable argument types/numbers. Fixing it would involve an
unknown amount of legacy breakage.
Yes ... I don't see a good way to maintain legacy compatibility.
Triggers seem like the least useful place to
Jim C. Nasby wrote:
... how many pages per bit ...
Are we trying to set up a complex solution to a problem
that'll be mostly moot once partitioning is easier and
partitioned tables are common?
In many cases I can think of the bulk of the data would be in
old partitions that are practically
Josh Berkus josh@agliodbs.com writes:
Triggers seem like the least useful place to have variable-argument
functions, though. And it is inconsistent with how we use functions
everywhere else, as well as in violation of the SQL03 standard on CREATE
FUNCTION (don't know what the standard
On Sat, 4 Mar 2006, Tom Lane wrote:
Has anyone else been finding the recent behavior of CVS-tip psql
to be a disimprovement? I've gotten sufficiently annoyed with it
that I'm ready to propose reverting this patch:
2006-02-11 16:55 momjian
* src/bin/psql/: help.c, input.c,
Charlie Savage wrote:
Hi everyone,
Thanks for the feedback. The reason for building extensions with MSVC
on windows is to get access to the Micrsoft debugging tools since as far
as I can see MingW/GDB cannot debug dynamically loaded dlls on the
Windows platform (or at least I haven't
Just to clarify, is this the problem?
test= SELECT
test- \d
No relations found.
test- 1;
?column?
--
1
(1 row)
test= SELECT
\d
1;
Did not find any relation named 1.
I have been noticing that the copyright is wrong on many files (2005)...
Do we have a utility to update the copyright?
J
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Joshua D. Drake [EMAIL PROTECTED] writes:
I have been noticing that the copyright is wrong on many files (2005)...
Do we have a utility to update the copyright?
We update those strings at major releases.
regards, tom lane
---(end of
Sorry... deleted the post I am responding to too quickly...
The question was whether there was a program to bring the files up to date.
Why? The code was written, and copyrighted, at the time that it was
submitted. Unless the code has been completely re-written, the original
copyright date
57 matches
Mail list logo
