Thinking about SQL assertions (check constraints that are independent of
one particular table), do you think it would be reasonable to implement
those on top of constraint triggers? On creation you'd hook up a
trigger to each of the affected tables. And the trigger function runs
the respective ch
On Tue, Aug 10, 2010 at 9:30 AM, Robert Haas wrote:
> It appears to me that RecordTransactionCommit() only needs to WAL-log
> shared invalidation messages when wal_level is hot_standby, but I
> don't see a guard to prevent it from doing it in all cases.
Perhaps right. During not hot standby, ther
Andres Freund wrote:
The most prohibitively expensive part is the AtEOXact_Buffers check of running
through all buffers and checking their pin count. And it makes $app's
regression tests take thrice their time...
Have you tried reducing shared_buffers from the default the system found
by p
There's an interesting buildfarm failure here:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecat&dt=2010-08-10%2023:46:10
It appears to me that this was caused by the concurrent run of another
buildfarm animal on the same physical machine, namely:
http://buildfarm.postgresql.org/cgi-bi
On Tue, Aug 10, 2010 at 11:00 PM, Tom Lane wrote:
> Fujii Masao writes:
>> Is it worth allowing pg_restore to accept multiple -t
>> switches as well as pg_dump?
>
> It's on the TODO list already, no?
Thanks! I found it on the list and understood there are other many
restrictions in pg_restore's
Florian Pflug wrote:
Attached is an updated version (v4).
I've attached a v5. No real code changes from Florian's version, just
some wording/style fixes and rework on the documentation. The user side
is now consistent about calling these statement latencies for example,
even though the
On Wed, Aug 11, 2010 at 12:14 PM, Greg Smith wrote:
> Boxuan Zhai wrote:
>
>> I just found that no Assert() works in my codes. I think it is because the
>> assertion is no enabled. How to enable assertion. To define
>> USE_ASSERT_CHECKING somewhere?
>>
>
> When you run "configure" before "make",
Boxuan Zhai wrote:
I just found that no Assert() works in my codes. I think it is because
the assertion is no enabled. How to enable assertion. To define
USE_ASSERT_CHECKING somewhere?
When you run "configure" before "make", use "--enable-cassert". The
normal trio for working on the PostgreS
On Tue, Aug 10, 2010 at 10:29 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 10/08/10 12:08, Boxuan Zhai wrote:
>
>> Thanks for your feedback. I fixed all the above waring bugs. Find the new
>> patch in attachement.
>>
>
> Thanks.
>
> I'm getting an assertion failure wit
Robert Haas writes:
> I spent some time cleaning this up tonight. I think that the \e and
> \ef portions are now ready to commit, but I am not quite happy with
> the \sf stuff yet, so I've broken that out into a separate patch,
> which is also attached.
> Barring objections, I'll commit the \e a
On Mon, Aug 9, 2010 at 7:40 AM, Pavel Stehule wrote:
> updated patch attached
I spent some time cleaning this up tonight. I think that the \e and
\ef portions are now ready to commit, but I am not quite happy with
the \sf stuff yet, so I've broken that out into a separate patch,
which is also at
On 11/08/10 14:42, Mark Kirkwood wrote:
On 10/08/10 19:46, vamsi krishna wrote:
Hello all
I want to measure the execution time spent running an SQL select
query after the plan generation.
So precisely I want to put my start timer before createQueryDesc() or
ExecutorStart() and end timer after
On 10/08/10 19:46, vamsi krishna wrote:
Hello all
I want to measure the execution time spent running an SQL select query
after the plan generation.
So precisely I want to put my start timer before createQueryDesc() or
ExecutorStart() and end timer after freeQueryDesc() or ExecutorEnd().
Right n
Gordon Shannon writes:
> - Because my table has no indexes, lazy_scan_heap calls lazy_vacuum_page
> directly for each block, and reports the variable tups_vacuumed ("removed
> 200 row versions in 2 pages"). However, tups_vacuumed is computed without
> counting the 100 LP_DEAD tuples, because per
Rod Taylor writes:
> Agreed with it being an interesting choice of settings. Nearly all of
> the data is 7-bit ASCII and what isn't seems to be a mix of UTF8,
> LATIN1, and LATIN15.
> I'm pretty sure it interpreted en_US to be LATIN1. There haven't been
> any noticeable changes in sorting order t
On 10 August 2010 19:48, David E. Wheeler wrote:
> On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
>
>> I, personally, would expect an empty array output given an empty
>> input, and a null output for a null input.
>
> +1
Agreed. After all, the result isn't indeterminate - it's an empty
array. So
On Tue, Aug 10, 2010 at 13:49, Tom Lane wrote:
> Rod Taylor writes:
>> Does anybody have experience on the cost, if any, of making this change?
>
>> Pg 8.3:
>> Encoding: SQL_ASCII
>> LC_COLLATE: en_US
>> LC_CTYPE: en_US
>
>> Pg 8.4:
>> Encoding: SQL_ASCII
>> Collation: en_US.UTF-8
>> Ctype: en_US
Mike Fowler writes:
> On 06/08/10 17:50, Pavel Stehule wrote:
>> attached updated patch with regression test
> Bravely ignoring the quotation/varidic/
> conversations, I've taken a look at the patch as is. Thanks to Tom's
> input I can now correctly drive the function. I can also report that
>
2010/8/10 Tom Lane :
> Brendan Jurd writes:
>>> I have attached v4 of the patch against HEAD, and also an incremental
>>> patch showing just my changes against v3.
>>>
>>> I'll mark this as ready for committer.
>
> Applied, with the discussed changes and some code editing.
>
>
Brendan Jurd writes:
>> I have attached v4 of the patch against HEAD, and also an incremental
>> patch showing just my changes against v3.
>>
>> I'll mark this as ready for committer.
Applied, with the discussed changes and some code editing.
regards, tom lane
--
Sent
After much code reading, testing, and using the extremely handy pageinspect
contrib to look at pages, here's what I believe is happening. I am not
attempting to describe every possible scenario, only this one test path.
Following my short test scenario above...
- Inserted rows get line pointers
Robert Haas wrote:
> On Tue, Aug 10, 2010 at 2:43 PM, Kevin Grittner
>> While we're on the topic of CF app enhancements, I often wished
>> that the date of the last change to the "Reviewers" column would
>> show underneath the name(s) where the value was not empty and the
>> date was later than
On Tue, Aug 10, 2010 at 2:43 PM, Kevin Grittner
wrote:
> Very nice. I was going to ask to have "Ready for Committer" split
> out to its own section, but with this filtering, it's probably not
> worth the bother. This change will be very nice for CF managers.
Glad you like.
> While we're on the
On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
> I, personally, would expect an empty array output given an empty
> input, and a null output for a null input.
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.post
On 10 August 2010 19:41, Tom Lane wrote:
> Looking through Pavel's string_to_array patch, I notice that the new
> version of string_to_array returns an empty (zero-element) array when
> the input string is of zero length, whereas the traditional version
> returned NULL instead. The patch fails to
Robert Haas wrote:
> While I was at it, I implemented a feature I've been wanting for a
> while: I made the "Status Summary" line at the top of the
> CommitFest page have links to filter by status.
Very nice. I was going to ask to have "Ready for Committer" split
out to its own section, but w
Looking through Pavel's string_to_array patch, I notice that the new
version of string_to_array returns an empty (zero-element) array when
the input string is of zero length, whereas the traditional version
returned NULL instead. The patch fails to emulate the old behavior
exactly, but rather than
Tom Lane wrote:
> Hm, looks like you went for a one-week timeout?
> That'll be an improvement for me, I expect, but maybe not for
> other people. Should it be longer?
The longer the setting, the more convenient for me, but I have a
hard time getting work up over logging in once per week. :-)
Robert Haas writes:
> On Tue, Aug 10, 2010 at 1:22 PM, Tom Lane wrote:
>> Anyway, maybe setting a normal expires date will make it work better.
> Done.
[ logs in again ... ] Hm, looks like you went for a one-week timeout?
That'll be an improvement for me, I expect, but maybe not for other
peop
On Tue, Aug 10, 2010 at 1:22 PM, Tom Lane wrote:
> Thom Brown writes:
>> On 10 August 2010 16:26, Robert Haas wrote:
>>> I don't see how that's possible, unless your browser is eating cookies
>>> for breakfast. There's no code anywhere in the application to (a)
>>> remove cookies from the datab
Rod Taylor writes:
> Does anybody have experience on the cost, if any, of making this change?
> Pg 8.3:
> Encoding: SQL_ASCII
> LC_COLLATE: en_US
> LC_CTYPE: en_US
> Pg 8.4:
> Encoding: SQL_ASCII
> Collation: en_US.UTF-8
> Ctype: en_US.UTF-8
Well, *both* of those settings collections are fundam
"Bozena Potempa" writes:
> I have a test table with varchar(40) column. After executing the following
> query:
> select substr(fc,1,2) from test
> PQftype returns for the result column PG_TYPE_TEXT and PQfsize returns -1.
> Is it the expected behaviour?
Yes. substr() returns text. But even if
Alvaro Herrera writes:
> Excerpts from Joseph Adams's message of mar ago 10 04:03:43 -0400 2010:
>> An overview, along with my thoughts, of the utility functions:
>>
>> FN_EXTRA, FN_EXTRA_ALLOC, FN_MCXT macros
>> * Useful-ometer: ()o
>>
>> TypeInfo structure and getTypeInfo f
We recently upgraded from 8.3 to 8.4 and have seen a performance
degredation which we are trying to explain and I have been asked to
get a second opinion on the cost of going from LATIN1 to UTF8
(Collation and CType) where the encoding remained SQL_ASCII..
Does anybody have experience on the cost,
Thom Brown writes:
> On 10 August 2010 16:26, Robert Haas wrote:
>> I don't see how that's possible, unless your browser is eating cookies
>> for breakfast. There's no code anywhere in the application to (a)
>> remove cookies from the database or (b) refuse to use cookies that are
>> in the data
Hi,
I have a test table with varchar(40) column. After executing the following
query:
select substr(fc,1,2) from test
PQftype returns for the result column PG_TYPE_TEXT and PQfsize returns -1.
Is it the expected behaviour? The most suprising for me is PQfsize.
Tested on PostgreSQL 8.4, 32-bit W
On Aug 10, 2010, at 8:23 AM, Stephen Frost wrote:
> * Peter Eisentraut (pete...@gmx.net) wrote:
>> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
>>> Some IP addresses have several host names, including in reverse
>>> lookup; how is that handled?
>>
>> This is not possible, or at least
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> It's hardly nonsense to have multiple names on a machine. While we
> usually avoid having multiple reverse lookup names, we have many
> in-house web applications and we neither want users to access them
> by IP address or have to worry about
* Aidan Van Dyk (ai...@highrise.ca) wrote:
> The PTR query is a means to get the "hostname" to check against, so you
> d'nt have to pre-cache all thos possible results of all the hostnames.
> Pre-caching all the hostnames in pg_hba.conf is madness. How long do
> you cache them for? or do send out
On 10 August 2010 16:26, Robert Haas wrote:
> On Tue, Aug 10, 2010 at 11:22 AM, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Tom Lane wrote:
$SUBJECT seems to be less than 12 hours, which is annoyingly
short. I don't see a good reason why I should have to log in
again every m
Excerpts from Joseph Adams's message of mar ago 10 04:03:43 -0400 2010:
> An overview, along with my thoughts, of the utility functions:
>
> FN_EXTRA, FN_EXTRA_ALLOC, FN_MCXT macros
> * Useful-ometer: ()o
>
> TypeInfo structure and getTypeInfo function
> * Useful-ometer: ()
On Tue, Aug 10, 2010 at 11:22 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> $SUBJECT seems to be less than 12 hours, which is annoyingly
>>> short. I don't see a good reason why I should have to log in
>>> again every morning. I could see expiring the cookie in a week o
* Peter Eisentraut (pete...@gmx.net) wrote:
> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
> > Some IP addresses have several host names, including in reverse
> > lookup; how is that handled?
>
> This is not possible, or at least the C library APIs don't expose it.
> Compare the getnam
On Aug 6, 2010, at 11:08 PM, Peter Eisentraut wrote:
> On ons, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
>> patch against HEAD is attached and validated against a lot of
>> previously wrong and correct hyphenated isbn.
>
> I think this module could use a regression test.
i'll take a look at th
"Kevin Grittner" writes:
> Tom Lane wrote:
>> $SUBJECT seems to be less than 12 hours, which is annoyingly
>> short. I don't see a good reason why I should have to log in
>> again every morning. I could see expiring the cookie in a week or
>> so, or tying it to a particular IP address, but this
Peter Eisentraut writes:
> On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
>> I was about to complain about that same thing. ISTM the logic ought
>> to be that you do a forward DNS lookup on the name presented in
>> pg_hba.conf, and if any of the returned IP addresses match the
>> connection's
Robert Haas wrote:
> it just sets a cookie that lasts
> for the lifetime of your browser session.
Ah, that's probably the difference -- I don't close the browser
window with the CF app. I just lock my workstation.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Robert Haas writes:
> On Tue, Aug 10, 2010 at 10:48 AM, Tom Lane wrote:
>> $SUBJECT seems to be less than 12 hours, which is annoyingly short.
>> I don't see a good reason why I should have to log in again every
>> morning. I could see expiring the cookie in a week or so, or tying
>> it to a par
Tom Lane wrote:
> $SUBJECT seems to be less than 12 hours, which is annoyingly
> short. I don't see a good reason why I should have to log in
> again every morning. I could see expiring the cookie in a week or
> so, or tying it to a particular IP address, but this is just
> getting in the way.
On Tue, Aug 10, 2010 at 10:48 AM, Tom Lane wrote:
> $SUBJECT seems to be less than 12 hours, which is annoyingly short.
> I don't see a good reason why I should have to log in again every
> morning. I could see expiring the cookie in a week or so, or tying
> it to a particular IP address, but thi
Peter Eisentraut writes:
> On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:
>> Why can't a forward lookup which matches the requesting IP be considered
>> sufficient?
> For one thing, because people might like to add wildcard support. So I
> might be able to say
> host all all appserv
On tis, 2010-08-10 at 10:39 -0400, Tom Lane wrote:
> I was about to complain about that same thing. ISTM the logic ought
> to be that you do a forward DNS lookup on the name presented in
> pg_hba.conf, and if any of the returned IP addresses match the
> connection's remote IP address, then you hav
* Tom Lane [100810 10:39]:
> I was about to complain about that same thing. ISTM the logic ought
> to be that you do a forward DNS lookup on the name presented in
> pg_hba.conf, and if any of the returned IP addresses match the
> connection's remote IP address, then you have a match. This busin
$SUBJECT seems to be less than 12 hours, which is annoyingly short.
I don't see a good reason why I should have to log in again every
morning. I could see expiring the cookie in a week or so, or tying
it to a particular IP address, but this is just getting in the way.
rega
"Kevin Grittner" writes:
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which matches the requesting IP be cons
On tis, 2010-08-10 at 09:18 -0500, Kevin Grittner wrote:
> Without the logic to ensure that the hostname matches the reverse
> lookup, this might be useful for us. With that logic it is useless
> for us. I'm wondering how much you gain by having it in there. Why
> can't a forward lookup which ma
On tis, 2010-08-10 at 10:11 -0400, Robert Haas wrote:
> These days, I think it's more common the other way around: one IP
> address, and many host names.
Yes, that setup is very common, but it's actually only an illusion that
DNS creates. The actual machine still has only one host name and some
I
On 10/08/10 12:08, Boxuan Zhai wrote:
Thanks for your feedback. I fixed all the above waring bugs. Find the new
patch in attachement.
Thanks.
I'm getting an assertion failure with this statement:
CREATE TABLE foo (id int4);
MERGE into foo t
USING (select id FROM generate_series(1,5) id) AS s
Hi,
The explanation of trace_recovery_messages in the document
is inconsistent with the definition of it in guc.c.
In the document,
* trace_recovery_messages is categorized into DEVELOPER_OPTIONS
* The default is WARNING
* Parameter should be set in the postgresql.conf only
But, in guc.c
* tra
Peter Eisentraut wrote:
> Yeah, you can configure all kinds of nonsense and sometimes even
> get away with it, but the basic assumption throughout is that a
> system has one host name and between 1 and many IP addresses.
It's hardly nonsense to have multiple names on a machine. While we
usual
On 10/08/10 12:38, Boxuan Zhai wrote:
The difficult way is to generate the plans for children table in planner, as
the other commands like UPDATE and DELETE. However, because the structure of
MERGE plan is much more complex than the ordinary ModifyTable plans, this
job may not as simple as we exp
On Tue, Aug 10, 2010 at 10:05 AM, Peter Eisentraut wrote:
> On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:
>> http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records
>
> Yeah, you can configure all kinds of nonsense and sometimes even get
> away with it, but the basic as
On tis, 2010-08-10 at 07:32 -0500, Kevin Grittner wrote:
> http://en.wikipedia.org/wiki/Reverse_DNS_lookup#Multiple_pointer_records
Yeah, you can configure all kinds of nonsense and sometimes even get
away with it, but the basic assumption throughout is that a system has
one host name and between
On tis, 2010-08-10 at 17:38 +0800, Boxuan Zhai wrote:
> I am not sure if inheritance of MERGE is needed by postgres.
Yes, it is.
> PS: for my investigation on the inheritance actions, I find that
> although the children tables are modified by the UPDATE or DELETE
> commands on their ancestor tabl
Fujii Masao writes:
> Is it worth allowing pg_restore to accept multiple -t
> switches as well as pg_dump?
It's on the TODO list already, no?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
On Tue, Aug 10, 2010 at 3:46 AM, vamsi krishna
wrote:
> I want to measure the execution time spent running an SQL select query after
> the plan generation.
>
> So precisely I want to put my start timer before createQueryDesc() or
> ExecutorStart() and end timer after freeQueryDesc() or ExecutorEnd
Peter Eisentraut wrote:
> On mån, 2010-08-09 at 13:56 -0500, Kevin Grittner wrote:
>> Peter Eisentraut wrote:
>>> is reverse looked up, which results in a host name.
>>
>> Some IP addresses have several host names, including in reverse
>> lookup; how is that handled?
>
> This is not possible,
On Tue, August 10, 2010 13:18, David Fetter wrote:
> On Tue, Aug 10, 2010 at 05:13:22PM +0900, Fujii Masao wrote:
>>
>> Is it worth allowing pg_restore to accept multiple -t
>> switches as well as pg_dump?
>>
>> $ pg_restore -t tbl1 -t tbl2 db.dump
>>
>> Regards,
>
> Yes. :)
>
> What other func
On Tue, Aug 10, 2010 at 05:13:22PM +0900, Fujii Masao wrote:
> Hi,
>
> pg_dump allows us to select multiple target tables by using
> multiple -t switches, but pg_restore does not. So, when
> restoring multiple tables, we have to run pg_restore more
> than once as follows. This is a pain to me.
>
Hi,
These days I am considering what else can be done for MERGE, And, I
find inheritance tables in postgres is not supported by our MERGE command
yet.
Currently, MERGE command is only able to handle the target table itself, and
its children tables are not involved in the process.
I am not sure if
On Tue, Aug 10, 2010 at 1:35 AM, Euler Taveira de Oliveira <
eu...@timbira.com> wrote:
> What do you mean by complex queries? You can always use the SET command.
> Sadly
> it doesn't work when you have different thresholds within distinct
> subqueries.
> (In pg_similarity I use this approach to s
Hi,
pg_dump allows us to select multiple target tables by using
multiple -t switches, but pg_restore does not. So, when
restoring multiple tables, we have to run pg_restore more
than once as follows. This is a pain to me.
$ pg_restore -t tbl1 db.dump
$ pg_restore -t tbl2 db.dump
Is it wo
Daniel Oliveira wrote:
There is a way to acess a index inside a c function without using a
sql statement ?
Yes, if you know the oid of the index you want to scan, you can use
functions from backend/access/index/indexam.c.
regards,
Yeb Havinga
--
Sent via pgsql-hackers mailing list (pgsql-hac
Hello all
I want to measure the execution time spent running an SQL select query after
the plan generation.
So precisely I want to put my start timer before createQueryDesc() or
ExecutorStart() and end timer after freeQueryDesc() or ExecutorEnd().
Right now I did so in "spi.c", "explain.c", "pqu
74 matches
Mail list logo
