On Thu, Sep 19, 2013 at 2:25 PM, samthakur74 wrote:
>>I got the segmentation fault when I tested the case where the
>> least-executed
>>query statistics is discarded, i.e., when I executed different queries more
>> than
>>pg_stat_statements.max times. I guess that the patch might have a bug.
> Tha
On Wed, Sep 18, 2013 at 9:54 PM, Pavel Stehule wrote:
> Hello
>
> thank you,
>
> I have no comments
>
Thanks.
Assigned it to committer.
>
> Regards
>
> Pavel
>
> --
Jeevan B Chalke
>I got the segmentation fault when I tested the case where the
least-executed
>query statistics is discarded, i.e., when I executed different queries
more than
>pg_stat_statements.max times. I guess that the patch might have a bug.
Thanks, will try to fix it.
>pg_stat_statements--1.1.sql should be
On Tue, Sep 17, 2013 at 11:31 PM, Andres Freund wrote:
> On 2013-09-17 09:45:28 -0400, Peter Eisentraut wrote:
>> On 9/15/13 11:30 AM, Andres Freund wrote:
>> > On 2013-09-15 11:20:20 -0400, Peter Eisentraut wrote:
>> >> On Sat, 2013-09-14 at 22:49 +0200, Andres Freund wrote:
>> >>> Attached you c
On Wed, Sep 18, 2013 at 2:21 PM, mohsen soodkhah mohammadi
wrote:
> hi
> I want that find where did a new tuple data construct in postgresql code
> when query is update.
> I find that ExecModiryTable is an upper function for do it. but I want to
> find exact place that create the data of one row o
Dimitri Fontaine wrote:
> Kevin Grittner writes:
>> You are arguing that we should provide lesser support for numeric
>> columns (and who knows how many other types) in materialized views
>> than we do in streaming replication, pg_dump,
>> suppress_redundant_updates_trigger(), and other places?
On Thu, Sep 19, 2013 at 11:48 AM, Sawada Masahiko wrote:
> I attached the patch which I have modified.
Thanks for updating the patch!
Here are the review comments:
I got the compiler warning:
syncrep.c:112: warning: unused variable 'i'
How does synchronous_transfer work with synchronous_c
On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao wrote:
> On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko
> wrote:
>> On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao wrote:
>>> I set up synchronous replication with synchronous_transfer = all, and then
>>> I ran
>>> pgbench -i and executed CHECKPOI
I'm not sure how many of you have been tracking this but courtesy of
lwn.net I have learned that it seems that the OOM killer behavior in
Linux 3.12 will be significantly different. And by description, it
sounds like an improvement. I thought some people reading -hackers
might be interested.
Bas
On Wed, Sep 18, 2013 at 12:55 PM, Jeff Janes
> wrote:
> On Mon, Sep 16, 2013 at 6:59 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com 'hlinnakan...@vmware.com');>> wrote:
>
>>
>> Here's a rebased version of the patch, including the above-mentioned
>> fixes. Nothing else new.
>
>
> I've applied
Misa Simic wrote
> I guess that rule can be achieved with triigers on TableA and TableC - but
> the same is true for FK (and FK constraint is more effective then trigger
> -
> that is why I wonder would it be useful/achievable to create that kind of
> constraint)
>
> Thoughts, ideas?
You create a
On 09/19/2013 12:55 AM, Dimitri Fontaine wrote:
>> We have, as a community, gone to a fair amount of trouble to make
>> > the concept of equality pluggable and allow multiple types of
>> > equality per type. To me it seems the perfect tool to solve this
>> > problem. Why the fuss?
> Because I do
Kevin Grittner writes:
> You are arguing that we should provide lesser support for numeric
> columns (and who knows how many other types) in materialized views
> than we do in streaming replication, pg_dump,
> suppress_redundant_updates_trigger(), and other places? Why?
Because you're saying tha
From: "Tom Lane"
Another point to keep in mind is that UTF16 is not really any easier
to deal with than UTF8, unless you write code that fails to support
characters outside the basic multilingual plane. Which is a restriction
I don't believe we'd accept. But without that restriction, you're st
From: "Robert Haas"
On Mon, Sep 16, 2013 at 8:49 AM, MauMau wrote:
2. NCHAR/NVARCHAR columns can be used in non-UTF-8 databases and always
contain Unicode data.
...
3. Store strings in UTF-16 encoding in NCHAR/NVARCHAR columns.
Fixed-width encoding may allow faster string manipulation as des
On Tue, Sep 17, 2013 at 05:54:04PM -0300, Alvaro Herrera wrote:
> Robert Haas escribi?:
>
> > Personally, I'm not particularly in favor of these kinds of changes.
> > The changes we made last time broke a lot of extensions - including
> > some proprietary EDB ones that I had to go fix. I think a
The following code is in the ProcSleep at proc.c:1138.
GetBlockingAutoVacuumPgproc() should presumably always return a vacuum
pgproc entry since the deadlock state says it's blocked by autovacuum.
But I'm not really familiar enough with this codepath to know whether
there's not a race condition her
On 09/18/2013 07:53 PM, Stephen Frost wrote:
>
> I'm really curious about your thoughts on unique indexes then. Should
> two numerics which are the same value but different byte
> representations be allowed in a unique index?
You could have multiple btree opclasses defined which would enforce
diffe
On 09/18/2013 05:54 PM, Kevin Grittner wrote:
> ...
> I think the hardest part will be documenting the difference between
> the row value constructor semantics (which are all that is
> currently documented) and the record equality semantics (used for
> sorting and building indexes). In a green fie
On 09/18/2013 06:05 PM, Stephen Frost wrote:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> Right. Not only would the per-type solution make materialized views
>> maintenance broken by default, requiring per-type work to make it
>> work reasonably, with silent failures for any type you didn't kn
On 09/18/2013 09:41 PM, Kevin Grittner wrote:
> Dimitri Fontaine wrote:
>> Kevin Grittner writes:
>>> change, but if '1.4' was stored in a column copied into a matview
>>> and they later updated the source to '1.40' the increase in
>>> accuracy would not flow to the matview. That would be a bug,
On 09/18/2013 09:19 PM, Dimitri Fontaine wrote:
> Kevin Grittner writes:
>> change, but if '1.4' was stored in a column copied into a matview
>> and they later updated the source to '1.40' the increase in
>> accuracy would not flow to the matview. That would be a bug, not a
>> feature.
> Maybe th
On 9/17/13 6:10 PM, Andres Freund wrote:
What if we maintained XID stats for ranges of pages in a separate
>fork? Call it the XidStats fork. Presumably the interesting pieces
>would be min(xmin) and max(xmax) for pages that aren't all visible. If
>we did that at a granularity of, say, 1MB worth o
On 9/14/13 11:55 PM, Pavel Stehule wrote:
2013/9/15 Marko Tiikkaja mailto:ma...@joh.to>>
On 2013-09-15 00:09, Pavel Stehule wrote:
this is a possibility for introduction a new hook and possibility
implement
asserions and similar task in generic form (as extension). it ca
On 9/16/13 10:14 AM, David Johnston wrote:
The "single" core aspect is interesting. Does the implementation have a
dedicated core to perform these calculations or must the same thread that
handles the relevant query perform this work as well? How much additional
impact/overhead does having to m
On 9/16/13 6:16 AM, Misa Simic wrote:
Hi hackers,
I just wonder how hard would be to implement something like "Not In FK
Constraint" or opposite to FK...
i.e:
FK ensures that value of FK column of inserted row exists in refferenced Table
NotInFK should ensure that value of NotInFK colum
On Mon, Sep 16, 2013 at 6:59 AM, Heikki Linnakangas wrote:
>
> Here's a rebased version of the patch, including the above-mentioned
> fixes. Nothing else new.
I've applied this to 0892ecbc015930d, the last commit to which it applies
cleanly.
When I test this by repeatedly incrementing a counte
Dimitri Fontaine wrote:
> Kevin Grittner writes:
>> change, but if '1.4' was stored in a column copied into a matview
>> and they later updated the source to '1.40' the increase in
>> accuracy would not flow to the matview. That would be a bug, not a
>> feature.
>
> Maybe the answer to that use
Kevin Grittner writes:
> change, but if '1.4' was stored in a column copied into a matview
> and they later updated the source to '1.40' the increase in
> accuracy would not flow to the matview. That would be a bug, not a
> feature.
Maybe the answer to that use case is to use the seg extension?
Kevin Grittner wrote:
>> If an update happens with a conditional of:
>>
>> where col1 = 'Abc'
>>
>> When col1 is 'ABC' using citext, should we still issue the
>> update?
>
> Absolutely not, because the update was requested in the case that
> the equality test was true.
Sorry, as if this thread w
Stephen Frost
> Kevin Grittner wrote:
>> Stephen Frost wrote:
>>
>>> If it's not actually *changing* (wrt its value), then I'm not
>>> at all impressed with the notion that it's going to get updated
>>> anyway.
>>
>> But PostgreSQL very specifically (and as far as I can tell
>> *intentionally*)
If you've got something that's not already on the current commitfest,
please put it on the next one.
Thanks!
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.
On 18.09.2013 16:16, Robert Haas wrote:
On Mon, Sep 16, 2013 at 8:49 AM, MauMau wrote:
2. NCHAR/NVARCHAR columns can be used in non-UTF-8 databases and always
contain Unicode data.
...
3. Store strings in UTF-16 encoding in NCHAR/NVARCHAR columns.
Fixed-width encoding may allow faster string
On 09/18/2013 05:53 PM, Andres Freund wrote:
> On 2013-09-18 11:50:23 -0400, Stephen Frost wrote:
>> For my 2c on this, while this can be useful for *us*, and maybe folks
>> hacking pretty close to PG, I can't get behind introducing this as an
>> '===' or some such operator. I've missed why this c
Stephen Frost wrote:
> I don't think that means we should change our definition of
> equality to generally be "are the bytes the same"- clearly that'd
> lead to incorrect behavior in the NUMERIC case.
Nobody is talking in any way, shape, or form about changing our
concept of what is "equal". We
Kevin,
On Wednesday, September 18, 2013, Kevin Grittner wrote:
> Stephen Frost > wrote:
>
> > If it's not actually *changing* (wrt its value), then I'm not at
> > all impressed with the notion that it's going to get updated
> > anyway.
>
> But PostgreSQL very specifically (and as far as I can tel
Stephen Frost wrote:
> If it's not actually *changing* (wrt its value), then I'm not at
> all impressed with the notion that it's going to get updated
> anyway.
But PostgreSQL very specifically (and as far as I can tell
*intentionally*) allows you to *change* a value and have it still
be conside
On Thu, Sep 19, 2013 at 2:41 AM, Fujii Masao wrote:
> On Wed, Sep 18, 2013 at 2:41 PM, Sameer Thakur wrote:
>You seem to have forgotten to include the pg_stat_statements--1.2.sql
>and pg_stat_statements--1.1--1.2.sql in the patch.
Sorry again. Please find updated patch attached.
>>
Hi Robert, Hi Amit,
Ok, first read through the patch.
On 2013-09-13 15:32:36 -0400, Robert Haas wrote:
> -AC_CHECK_FUNCS([cbrt dlopen fdatasync getifaddrs getpeerucred getrlimit
> mbstowcs_l memmove poll pstat readlink setproctitle setsid sigprocmask
> symlink sync_file_range towlower utime uti
On Wed, Sep 18, 2013 at 2:41 PM, Sameer Thakur wrote:
>>> >You seem to have forgotten to include the pg_stat_statements--1.2.sql
>>> >and pg_stat_statements--1.1--1.2.sql in the patch.
>>> Sorry again. Please find updated patch attached.
>
> I did not add pg_stat_statements--1.2.sql. I have added
On Wed, Sep 18, 2013 at 1:42 PM, Ian Lawrence Barwick wrote:
> Attached.
Committed. Thanks!
Regards,
--
Fujii Masao
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 18, 2013 at 2:06 AM, Andres Freund wrote:
> On 2013-09-17 23:12:24 -0700, Sergey Konoplev wrote:
>> How safe is it to use the technique described by the link below with
>> system catalog tables to remove bloat?
>> (in a couple of words it is about moving tuples to the beginning of
>> t
Robert Haas writes:
> On Mon, Sep 16, 2013 at 8:49 AM, MauMau wrote:
>> 2. NCHAR/NVARCHAR columns can be used in non-UTF-8 databases and always
>> contain Unicode data.
>> ...
>> 3. Store strings in UTF-16 encoding in NCHAR/NVARCHAR columns.
>> Fixed-width encoding may allow faster string manipul
* Steve Singer (st...@ssinger.info) wrote:
> The problem is that there are datatypes (citext, postgis,...) that
> have defined = to return true when comparing two values that are
> different not just stored differently.
If the definition of the type is that they're equal, then they're equal.
Certa
On 09/18/2013 11:39 AM, Stephen Frost wrote:
* Kevin Grittner (kgri...@ymail.com) wrote:
= and <> aren't listed above even though they do a byte-for-byte
comparison because, well, I guess because we have chosen to treat
two UTF8 strings which produce the same set of glyphs using
different bytes
On 2013-09-18 08:46:08 -0400, Robert Haas wrote:
> Here's another idea. At initdb time, create an empty directory called
> called pg_you_can_load_stuff_from_here (pick a better name) inside
> $PGDATA. Allow it to be replaced with a symlink. This would be
> similar to what we do today with pg_xlo
* Kevin Grittner (kgri...@ymail.com) wrote:
> = and <> aren't listed above even though they do a byte-for-byte
> comparison because, well, I guess because we have chosen to treat
> two UTF8 strings which produce the same set of glyphs using
> different bytes as unequal. :-/
I tend to side with An
* Merlin Moncure (mmonc...@gmail.com) wrote:
> Having matviews using SQL expressible features is a *good* thing.
Fine, then it should be implemented *using SQL*, which is based on
*values*, not on how the value is represented in bits and bytes.
> Having a user accessible operator is nice to have
Hello
thank you,
I have no comments
Regards
Pavel
2013/9/18 Jeevan Chalke
> Hi Pavel,
>
> I have reviewed your patch.
>
> Patch looks excellent and code changes match with similar constructs
> elsewhere. That's great.
>
> However, it was not applying with git apply command but able to apply
On Wed, Sep 18, 2013 at 10:59 AM, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
>> I think this really needs to have an obscure name. Like ==!!== or
>> somesuch (is equal very much, but doesn't actually test for equality ;))
>
> hah.
>
>> > What the heck is the use case fo
* Andres Freund (and...@2ndquadrant.com) wrote:
> I think this really needs to have an obscure name. Like ==!!== or
> somesuch (is equal very much, but doesn't actually test for equality ;))
hah.
> > What the heck is the use case for this being a user-oriented, SQL
> > operator..?
>
> The matera
* Kevin Grittner (kgri...@ymail.com) wrote:
> Right. Not only would the per-type solution make materialized views
> maintenance broken by default, requiring per-type work to make it
> work reasonably, with silent failures for any type you didn't know
> about, but "no user-visible differences" is a
Robert Haas wrote:
> Kevin Grittner wrote:
>> To have clean semantics, I think the operator should mean that the
>> stored format of the row is the same. Regarding the array null
>> bitmap example, I think it would be truly weird if the operator
>> said that the stored format was the same, but t
Stephen Frost wrote:
> making an SQL operator for 'are these really the same bytes' to
> deal with what is essentially implementation detail is _very_
> grotty.
We already have some such operators, although Andres argues that
comparing to that isn't fair because we at least know it is a
string o
Robert Haas writes:
> I think that would largely be rehashing previous discussions, in which
> it's already been established that we don't see eye to eye on this
> issue. But briefly, I think that replacing shared libraries ought to
Partly yes, but as I'm feeling that we are getting closer than
On 2013-09-18 11:50:23 -0400, Stephen Frost wrote:
> For my 2c on this, while this can be useful for *us*, and maybe folks
> hacking pretty close to PG, I can't get behind introducing this as an
> '===' or some such operator. I've missed why this can't be a simple
> function and why in the world w
On 2013-09-18 11:06:13 -0500, Merlin Moncure wrote:
> > Ugh. This feels like a pretty ugly hack to deal with that. I haven't
> > got any magical wand to address it, but making an SQL operator for 'are
> > these really the same bytes' to deal with what is essentially
> > implementation detail is _
* Robert Haas (robertmh...@gmail.com) wrote:
> Therefore, I see no harm in
> having an operator that tests for
> are-these-values-identical-for-all-purposes. If that's useful for
> RMVC, then there may be other legitimate uses for it as well.
>
> And once we decide that's OK, I think we ought to
> "dlight" == dlight writes:
dlight> So if I run function 1 with varible inside the query in
dlight> one session it's replan each time.
dlight> But if whant to teling postgres do not doing this, what shoud
dlight> i do?
dlight> We have more than 1 runs in one session with vari
On Tue, Sep 17, 2013 at 4:54 PM, Alvaro Herrera
wrote:
> Now, htup_details.h was a bit different than the case at hand because
> there's evidently lots of code that want to deal with the guts of
> tuples, but for scans you mainly want to start one, iterate and finish,
> but don't care much about t
On Wed, Sep 18, 2013 at 9:26 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> - consider on-disk extension as templates and move their module files
>>> somewhere private in $PGDATA and load the code from there
>>
>> I think this will be horrid mess of security vulnerabilities and upgra
On Tue, Sep 17, 2013 at 8:23 AM, Kevin Grittner wrote:
> To have clean semantics, I think the operator should mean that the
> stored format of the row is the same. Regarding the array null
> bitmap example, I think it would be truly weird if the operator
> said that the stored format was the same
Hello
2013/9/18 Marko Tiikkaja
> On 2013-09-16 21:24, Pavel Stehule wrote:
>
>> 2. a failed assert should to raise a exception, that should not be handled
>> by any exception handler - similar to ERRCODE_QUERY_CANCELED - see
>> exception_matches_conditions.
>>
>
> I'm not sure what I think abou
Hello
can you try this patch (commit)
https://github.com/postgres/postgres/commit/a5f11e24a4d1afb213c780812a3df14c04d7f845#diff-fc73a24ee7d0692c2a0c639870223d70?
Regards
Pavel
2013/9/18 dlight
> So if I run function 1 with varible inside the query in one session
> it's
> replan each time
--On 18. September 2013 15:19:27 +0200 Andres Freund
wrote:
Well, that will lead the user in the wrong direction, won't it? They
haven't disabled the constraint but the trigger. Especially as we
already have NOT VALID and might grow DISABLED for constraint
themselves...
Valid point. But
On 7/8/13 9:33 PM, James Sewell wrote:
> New patch attached. I've moved from using a boolean to an enum trivalue.
When ldapreferrals is set to something other than "0" or "1" exactly, it
just ignores the option. That's not good, I think. It should probably
be an error.
--
Sent via pgsql-hack
I have assigned myself as reviewer for this one.
The logic of pg_get_function_arg_default() looks good. I will reply with
any code-level comments later, but just a quick question before that:
What's the reason behind calling pg_has_role(proowner, 'USAGE') before
calling pg_get_function_arg_defaul
Hello
we found a strange slow hash join operations - and it looks so this behave
is related to underestimation. I found a Simon's proposal
http://www.postgresql.org/message-id/ca+u5nmj21sxchk6sg2oq7t0ztuaoebfhuprczfbbmmfezam...@mail.gmail.com
Is there any progress?
Regards
Pavel
-> Hash Joi
This is a review for patch
caaphdvpagtypzb2kwa0mmtksayg9+vashyjmjfatngxr1ad...@mail.gmail.com
The patch is readable, applies fine and builds without warnings.
It contains sufficient documentation.
It works as it should, no crashes or errors.
It is well written, in fact it improves the readabili
On Tue, Sep 17, 2013 at 5:04 PM, Alexander Korotkov wrote:
> On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth <
> and...@tao11.riddles.org.uk> wrote:
>
>> > "Alexander" == Alexander Korotkov writes:
>>
>> Alexander> 2) NaN coordinates should be processed in GiST index scan
>> Alexander> like
2013-09-18 14:27 keltezéssel, Andres Freund írta:
On 2013-09-18 14:23:19 +0200, Boszormenyi Zoltan wrote:
Hi,
I have experimented with cursors a little and found that the part about FOR
SHARE/FOR UPDATE in
http://www.postgresql.org/docs/9.2/interactive/sql-declare.html
i.e. the "sensitive cur
Robert Haas writes:
>> - consider on-disk extension as templates and move their module files
>> somewhere private in $PGDATA and load the code from there
>
> I think this will be horrid mess of security vulnerabilities and upgrade woes.
I think it's a solution to that horrid mess. Care to e
On 2013-09-16 16:59:28 +0300, Heikki Linnakangas wrote:
> Here's a rebased version of the patch, including the above-mentioned fixes.
> Nothing else new.
* We need some higherlevel description of the algorithm somewhere in the
source. I don't think I've understood the concept from the patch alon
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
>
>
> --On 18. September 2013 13:52:29 +0200 Andres Freund
> wrote:
>
> >If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually
> >re-enable the disabled triggers it's easy to miss internal triggers.
> >A \d+ tablename will not sho
On Mon, Sep 16, 2013 at 8:49 AM, MauMau wrote:
> 2. NCHAR/NVARCHAR columns can be used in non-UTF-8 databases and always
> contain Unicode data.
...
> 3. Store strings in UTF-16 encoding in NCHAR/NVARCHAR columns.
> Fixed-width encoding may allow faster string manipulation as described in
> Oracle
--On 18. September 2013 13:52:29 +0200 Andres Freund
wrote:
If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually
re-enable the disabled triggers it's easy to miss internal triggers.
A \d+ tablename will not show anything out of the ordinary for that
situation since we don't
On Tue, Sep 17, 2013 at 5:45 AM, Etsuro Fujita
wrote:
> I think the document in advanced.sgml should be corrected, though I might
> misunderstand the rules of usage. Attached is a patch.
I think you're right, because the existing text makes it sounds like
the operator is >=, but the query says >
On Tue, Sep 17, 2013 at 5:16 AM, Etsuro Fujita
wrote:
> I ran into a typo. Attached is a patch.
Committed, thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Sat, Sep 14, 2013 at 4:15 PM, Dimitri Fontaine
wrote:
> We can attack the problem in several ways:
>
> - have an initdb switch to tweak the library path per cluster,
I see no advantage to making this impossible to change after initdb time.
> - have a superuser-only GUC to tweak the librar
Andres Freund writes:
> So, how about displaying disabled internal triggers in psql?
+1
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
On Sun, Sep 15, 2013 at 10:51 AM, Peter Eisentraut wrote:
> On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote:
>> Peter Eisentraut writes:
>> > It shouldn't be in the commit fest if it has no patch.
>>
>> What should I do if my goal is to get community consensus on the best
>> way to solv
On 2013-09-18 14:23:19 +0200, Boszormenyi Zoltan wrote:
> Hi,
>
> I have experimented with cursors a little and found that the part about FOR
> SHARE/FOR UPDATE in
>
> http://www.postgresql.org/docs/9.2/interactive/sql-declare.html
>
> i.e. the "sensitive cursor" is not what actually happens. BT
Hi,
I have experimented with cursors a little and found that the part about FOR SHARE/FOR
UPDATE in
http://www.postgresql.org/docs/9.2/interactive/sql-declare.html
i.e. the "sensitive cursor" is not what actually happens. BTW, 9.3 has the same contents
for the same page.
"
If the cursor's
Hi,
If you do ALTER TABLE ... DISABLE TRIGGER ALL; and then individually
re-enable the disabled triggers it's easy to miss internal triggers.
A \d+ tablename will not show anything out of the ordinary for that
situation since we don't show internal triggers. But foreign key checks
won't work.
So,
So if I run function 1 with varible inside the query in one session it's
replan each time.
But if whant to teling postgres do not doing this, what shoud i do?
We have more than 1 runs in one session with varible inside sql. And
have big performance problem in 9.2 and 9.3.
Here is my t
On 14 May 2013 16:35, Peter Eisentraut wrote:
> Sometimes, the psql startup hangs when it cannot resolve or connect to a
> host. Intuitively, I would like to press Ctrl+C and correct the
> connection string or investigate. But that doesn't work because Ctrl+C
> is already bound to the query canc
On 2013-09-18 00:54:38 -0500, Peter Geoghegan wrote:
> > At some point we might to extend that logic to more cases, but that
> > should be separate discussion imo.
>
> This is essentially why I went and added a row locking component over
> your objections.
I didn't object to implementing row leve
Hi,
On 2013-09-17 23:12:24 -0700, Sergey Konoplev wrote:
> How safe is it to use the technique described by the link below with
> system catalog tables to remove bloat?
>
> (in a couple of words it is about moving tuples to the beginning of
> the table with a special way of updating)
>
> http://
On 2013-09-18 11:55:24 +0530, Amit Kapila wrote:
> > I think that ship has long since sailed. postgresql.conf has allowed
> > foo.bar style GUCs via custom_variable_classes for a long time, and
> > these days we don't even require that but allow them generally. Also,
> > SET, postgres -c, and SELE
hi
I want that find where did a new tuple data construct in postgresql code
when query is update.
I find that ExecModiryTable is an upper function for do it. but I want to
find exact place that create the data of one row of table.
can you help me?
On Tue, Sep 17, 2013 at 10:37 AM, Cédric Villemain
wrote:
>> Erm, isn't apt.postgresql.org supposed to ship the *official*
>> PostgreSQL versions? Given that this issue affects all distros, I
>> don't see why Ubuntu/Debian need to be patched separately.
> Well, the patches are applyed on the debi
On Tue, Sep 17, 2013 at 4:03 PM, Alvaro Herrera
wrote:
> Thom Brown wrote:
>
> Thanks for testing.
>
>> Thanks for the patch, but I seem to have immediately hit a snag:
>>
>> pgbench=# CREATE INDEX minmaxtest ON pgbench_accounts USING minmax (aid);
>> PANIC: invalid xlog record length 0
>
> Silly
92 matches
Mail list logo
