Hey folks,
It doesn't stop to bug me, that postgres will return 0 number of
affected rows, if table is triggered.
Now, question is - is this fixable, but no one cares, or is it some
sort of a design/implementation flaw and we just have to live with it.
--
Sent via pgsql-hackers mailing lis
"Alex Hunsaker" wrote:
> A few comments:
>
> Is there a reason you add sourceText to QueryDesc? AFAICT you can do
> ActivePortal->sourceText and it will always be populated correctly.
That's for nested statements (SQLs called in stored functions).
ActivePortal->sourceText shows text of only to
Tom Lane napsal(a):
Zdenek Kotala writes:
Another potential problem with toast setting is that reloption is toastable and
it could generates loops in detoasting pg_class tuples. For example toast chunk
size cannot be implement like reloption (or pg_class should use every time
default values).
2008/12/22 Tom Lane :
> "Hitoshi Harada" writes:
>> 2008/12/21 Tom Lane :
>>> Heikki Linnakangas writes:
WindowAgg?
>>>
>>> WindowAgg seems like a winner to me, because it draws a parallel to
>>> the regular Agg node type, which seems valid unless I've completely
>>> misunderstood what's hap
2008/12/22 Tom Lane :
> The window functions patch defines some API functions and macros for
> window functions. These are currently defined in executor/nodeWindow.h,
> but that seems to me like a fairly inappropriate location. The executor
> main body, which would be the normal consumer of that
On Sun, Dec 21, 2008 at 11:06:09PM -0500, Tom Lane wrote:
> David Fetter writes:
> > Given that the main (and only sane, IMHO) use for table inheritance is
> > in table partitioning, can we see about deprecating ONLY (in the table
> > inheritance sense) for the next couple of development cycles an
Hi,
On Wed, Dec 17, 2008 at 12:07 PM, Fujii Masao wrote:
>> No, we've been through that loop already a few months back:
>> Transaction-controlled robustness.
>>
>> It should be up to the client on the primary to decide how much waiting
>> they would like to perform in order to provide a guarantee
David Fetter writes:
> Given that the main (and only sane, IMHO) use for table inheritance is
> in table partitioning, can we see about deprecating ONLY (in the table
> inheritance sense) for the next couple of development cycles and then
> removing it?
No.
1. It's required by SQL standard.
2.
The window functions patch defines some API functions and macros for
window functions. These are currently defined in executor/nodeWindow.h,
but that seems to me like a fairly inappropriate location. The executor
main body, which would be the normal consumer of that include file, has
no interest
On Sun, Dec 21, 2008 at 10:09:54PM -0500, Jaime Casanova wrote:
> Hi,
>
> just out of curiosity, why TRUNCATE doesn't support ONLY?
>
> audit=# TRUNCATE only postgres_log;
> ERROR: syntax error at or near "only"
> LINE 1: TRUNCATE only postgres_log;
Given that the main (and only sane, IMHO) use
[Some performance testing.]
I ran this query 10x with this patch applied, and then 10x again with
enable_hashjoin_usestatmvcs set to false to disable the optimization:
select sum(1) from (select * from part, lineitem where p_partkey = l_partkey) x;
With the optimization enabled, the query took b
Hi,
just out of curiosity, why TRUNCATE doesn't support ONLY?
audit=# TRUNCATE only postgres_log;
ERROR: syntax error at or near "only"
LINE 1: TRUNCATE only postgres_log;
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
AsesorÃa y desarrollo de sistemas
Guayaquil - Ecuador
Hi, I have a comment about the generic-reloptions patch.
Alvaro Herrera wrote:
> Here's a patch for improving the general reloptions mechanism. What
> this patch does is add a table-based option parser. This allows adding
> new options very easily, and stops the business of having to pass the
On Tue, 2008-12-02 at 12:12 +0200, Heikki Linnakangas wrote:
> CREATE TABLE foo (bar tsvector);
> INSERT INTO foo SELECT to_tsvector('foo' || a) FROM generate_series(1,
> 20) a;
> CREATE INDEX foogin ON foo USING gin (bar);
>
> The CREATE INDEX step takes about 40 seconds on my laptop, which
Hello Emmanuel,
Emmanuel Cecchet wrote:
> I am happy to see that Postgres-R is alive again. The paper was written
> in 07 (and published in 08, the review process is longer than a
> CommitFest ;-)) and at the time of the writing there was no version of
> Postgres-R available, hence the 'obsolete'
On Mon, Dec 15, 2008 at 11:27 AM, Tom Lane wrote:
> I wrote:
>> But I don't see this sorting behavior with glibc on Linux (Fedora 9 to
>> be exact, testing LC_COLLATE=es_ES.utf8).
>
doh! i'm seeing this again in HEAD (and in 8.3.5) when executing make
installcheck on openSuse 11
when initdb'ing
Hi Markus,
I am happy to see that Postgres-R is alive again. The paper was written
in 07 (and published in 08, the review process is longer than a
CommitFest ;-)) and at the time of the writing there was no version of
Postgres-R available, hence the 'obsolete' mention referring to past
versio
Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
>> Heikki Linnakangas wrote:
>>> Gregory Stark wrote:
A vacuum being replayed -- even in a different database -- could trigger
the
error. Or with the btree split issue, a data load -- again even in a
different
database --
Hi,
Emmanuel Cecchet wrote:
> What the application is going to see is a failure when the postmaster it
> is connected to is going down. If this happen at commit time, I think
> that there is no guarantee for the application to know what happened:
> 1. failure occurred before the request reached po
Hi,
Simon Riggs wrote:
> The second way can be done by taking a snapshot on the primary, with an
> associated LSN, then using that snapshot on the standby. That is
> somewhat complex, but possible. I see the requirement for getting the
> same answer on multiple nodes as a further extension of "tra
I wrote:
> I've been hacking on this and I have a grammar that pretty much works,
> but there's some bizarreness around UNBOUNDED. I'll post it later.
Here is a proof-of-concept grammar patch that allows frame_bound to use
a_expr instead of a hacked-up constant production (which, as I
complained
"Hitoshi Harada" writes:
> 2008/12/20 Tom Lane :
>> I've been studying the grammar for the windowing patch a bit. It seems
>> to me that the option for
>> got left out.
> I completely missed this issue. If the is
> allowed in , then does it mean this is possible?
> SELECT row_number() OVER w
"Hitoshi Harada" writes:
> 2008/12/21 Tom Lane :
>> Heikki Linnakangas writes:
>>> WindowAgg?
>>
>> WindowAgg seems like a winner to me, because it draws a parallel to
>> the regular Agg node type, which seems valid unless I've completely
>> misunderstood what's happening...
> I disagree with W
Zdenek Kotala writes:
> Another potential problem with toast setting is that reloption is toastable
> and
> it could generates loops in detoasting pg_class tuples. For example toast
> chunk
> size cannot be implement like reloption (or pg_class should use every time
> default values).
Nonsen
Hello,
the march 2008 commitfest added a patch[1] with extended information for
\l+. The may 2008 commitfest added a patch[2] which reformats the
permission output in \z. I like the new output in \z, but the \l+
output is still missing this feature. The attached patch solves this
problem.
Kind
Tom Lane wrote:
> Andrew Dunstan writes:
>> Also, because one of the Makefiles involved (src/foreign/Makefile)
>> doesn't follow one of our standard patterns.
>
> Is there a really good reason why it doesn't?
> (eg, why "FDW" and not "SUBDIRS"?)
If you put them in SUBDIRS, don't get they get li
Tom Lane wrote:
> KaiGai Kohei writes:
>> Tom Lane wrote:
>>> This seems like a pretty bad idea that will eventually bite you in an
>>> uncomfortable place. Lying about what datatype a field is is just not
>>> safe.
>
>> Is it also correct for system attributes?
>> I don't think the format on st
> - Todo item
> * Documentation updates.
> The "sepostgresql-docs-8.4devel-3-r1324.patch" is not uptodate,
> because higher priority should be given to provide the patch
> set for reviewers. So, I'll update the src/doc/* from now.
The documentation patch is updated, as follows:
- htt
Alvaro Herrera napsal(a):
ALTER TABLE foo SET (toast.autovacuum_enabled = false);
+1
Do not forget on toast index as well.
ALTER TABLE foo SET (toast_idx.fillfactor = 50);
Another potential problem with toast setting is that reloption is toastable and
it could generates loops in detoasting
> "Alvaro" == Alvaro Herrera writes:
Alvaro> Is errdetail not printed when verbosity = terse?
No, it's not.
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> "Tom" == Tom Lane writes:
>> I propose that this behaviour be changed such that 'terse' is
>> ignored for all log messages of FATAL or PANIC severity.
>> [ on the strength of a single example ]
Tom> This seems like using a blunderbuss where a rifle is called for.
Maybe so.
Tom> Ther
Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Gregory Stark wrote:
A vacuum being replayed -- even in a different database -- could trigger the
error. Or with the btree split issue, a data load -- again even in a different
database -- would be quite likely cause your SELECT to be killed.
Hmm,
32 matches
Mail list logo
