Hi all,
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)
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 it
with patch -p1 with some offsets. make and make install was smooth too.
Regression suite
On Tue, Sep 17, 2013 at 4:03 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
On Tue, Sep 17, 2013 at 10:37 AM, Cédric Villemain
ced...@2ndquadrant.com 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
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 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 SELECT
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)
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 level
On 14 May 2013 16:35, Peter Eisentraut pete...@gmx.net 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
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
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,
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
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. BTW, 9.3
On Sun, Sep 15, 2013 at 10:51 AM, Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net 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
Andres Freund and...@2ndquadrant.com 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
On Sat, Sep 14, 2013 at 4:15 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
On Tue, Sep 17, 2013 at 5:16 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
On Tue, Sep 17, 2013 at 5:45 AM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp 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
--On 18. September 2013 13:52:29 +0200 Andres Freund
and...@2ndquadrant.com 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
On Mon, Sep 16, 2013 at 8:49 AM, MauMau maumau...@gmail.com 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
On 2013-09-18 15:15:55 +0200, Bernd Helmle wrote:
--On 18. September 2013 13:52:29 +0200 Andres Freund
and...@2ndquadrant.com 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
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 alone
Robert Haas robertmh...@gmail.com 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
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
On Tue, Sep 17, 2013 at 5:04 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Mon, Sep 16, 2013 at 4:13 PM, Andrew Gierth
and...@tao11.riddles.org.uk wrote:
Alexander == Alexander Korotkov aekorot...@gmail.com writes:
Alexander 2) NaN coordinates should be processed in GiST index
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
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
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
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-hackers
--On 18. September 2013 15:19:27 +0200 Andres Freund
and...@2ndquadrant.com 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
Hello
can you try this patch (commit)
https://github.com/postgres/postgres/commit/a5f11e24a4d1afb213c780812a3df14c04d7f845#diff-fc73a24ee7d0692c2a0c639870223d70?
Regards
Pavel
2013/9/18 dlight avinf...@gmail.com
So if I run function 1 with varible inside the query in one session
it's
Hello
2013/9/18 Marko Tiikkaja ma...@joh.to
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
On Tue, Sep 17, 2013 at 8:23 AM, Kevin Grittner kgri...@ymail.com 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
On Wed, Sep 18, 2013 at 9:26 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Sep 17, 2013 at 4:54 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
dlight == dlight avinf...@gmail.com 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
* 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
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 _very_
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 we
Stephen Frost sfr...@snowman.net 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
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com wrote:
Kevin Grittner kgri...@ymail.com 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
* 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
On Wed, Sep 18, 2013 at 10:59 AM, Stephen Frost sfr...@snowman.net 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
* 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 materalized
Hello
thank you,
I have no comments
Regards
Pavel
2013/9/18 Jeevan Chalke jeevan.cha...@enterprisedb.com
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
* 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
* 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 Andres
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_xlog.
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
* 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.
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 16, 2013 at 8:49 AM, MauMau maumau...@gmail.com 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
On Wed, Sep 18, 2013 at 2:06 AM, Andres Freund and...@2ndquadrant.com 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
On Wed, Sep 18, 2013 at 1:42 PM, Ian Lawrence Barwick barw...@gmail.com 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:41 PM, Sameer Thakur samthaku...@gmail.com 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
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
On Thu, Sep 19, 2013 at 2:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 18, 2013 at 2:41 PM, Sameer Thakur samthaku...@gmail.com 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
Stephen Frost sfr...@snowman.net 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
Kevin,
On Wednesday, September 18, 2013, Kevin Grittner wrote:
Stephen Frost sfr...@snowman.net javascript:; 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
Stephen Frost sfr...@snowman.net 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
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 can't
On 18.09.2013 16:16, Robert Haas wrote:
On Mon, Sep 16, 2013 at 8:49 AM, MauMaumaumau...@gmail.com 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
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 da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal:
Stephen Frost sfr...@snowman.net
Kevin Grittner wrote:
Stephen Frost sfr...@snowman.net 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
Kevin Grittner kgri...@ymail.com 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
Kevin Grittner kgri...@ymail.com 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
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kgri...@ymail.com 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.
On Mon, Sep 16, 2013 at 6:59 AM, Heikki Linnakangas hlinnakan...@vmware.com
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
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 column
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
On 9/14/13 11:55 PM, Pavel Stehule wrote:
2013/9/15 Marko Tiikkaja ma...@joh.to 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
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 of
On 09/18/2013 09:19 PM, Dimitri Fontaine wrote:
Kevin Grittner kgri...@ymail.com 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.
On 09/18/2013 09:41 PM, Kevin Grittner wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kgri...@ymail.com 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
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 know
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 field I
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
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
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 lot of
From: Robert Haas robertmh...@gmail.com
On Mon, Sep 16, 2013 at 8:49 AM, MauMau maumau...@gmail.com 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
From: Tom Lane t...@sss.pgh.pa.us
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
Kevin Grittner kgri...@ymail.com 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
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 don't
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 Wed, Sep 18, 2013 at 12:55 PM, Jeff Janes
jeff.ja...@gmail.comjavascript:_e({}, 'cvml',
'jeff.ja...@gmail.com');
wrote:
On Mon, Sep 16, 2013 at 6:59 AM, Heikki Linnakangas
hlinnakan...@vmware.com javascript:_e({}, 'cvml',
'hlinnakan...@vmware.com'); wrote:
Here's a rebased version of
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.
On Wed, Sep 18, 2013 at 11:45 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 18, 2013 at 10:35 AM, Sawada Masahiko sawada.m...@gmail.com
wrote:
On Tue, Sep 17, 2013 at 9:52 PM, Fujii Masao masao.fu...@gmail.com wrote:
I set up synchronous replication with synchronous_transfer = all,
On Thu, Sep 19, 2013 at 11:48 AM, Sawada Masahiko sawada.m...@gmail.com 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
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kgri...@ymail.com 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,
On Wed, Sep 18, 2013 at 2:21 PM, mohsen soodkhah mohammadi
mohsensoodk...@gmail.com 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
On Tue, Sep 17, 2013 at 11:31 PM, Andres Freund and...@2ndquadrant.com 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:
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
92 matches
Mail list logo
