Teodor's patch could use some more comments. The STOP_SCAN/MATCH_SCAN/CONT_SCAN
macros are a good idea, but they probably should go into
src/include/access/gin.h so that they can be used in all compare_partial
implementations.
STOP_SCAN/MATCH_SCAN/CONT_SCAN macros are moved to gin's header, and
2014-12-25 22:23 GMT+01:00 Alex Shulgin a...@commandprompt.com:
Trent Shipley trent_ship...@qwest.net writes:
On Friday 2007-12-14 16:22, Tom Lane wrote:
Neil Conway ne...@samurai.com writes:
By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
to drop (and log) rows
2014-12-26 11:41 GMT+01:00 Pavel Stehule pavel.steh...@gmail.com:
2014-12-25 22:23 GMT+01:00 Alex Shulgin a...@commandprompt.com:
Trent Shipley trent_ship...@qwest.net writes:
On Friday 2007-12-14 16:22, Tom Lane wrote:
Neil Conway ne...@samurai.com writes:
By modifying COPY: COPY
On Wed, Dec 24, 2014 at 6:48 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
All,
I want to revive this thread and continue to move these new role
attributes forward.
In summary, the ultimate goal is to include new role attributes for common
operations which currently
On 24 December 2014 at 16:04, Andreas Karlsson andr...@proxel.se wrote:
On 12/16/2014 11:04 AM, David Rowley wrote: These are some very promising
performance increases.
I've done a quick pass of reading the patch. I currently don't have a
system with a 128bit int type, but I'm working on
Heikki Linnakangas hlinnakangas(at)vmware(dot)com writes:
I would suggest just adding the information to the Sort Key line. As
long as you don't print the modifiers when they are defaults (ASC and
NULLS LAST), we could print the information even in non-VERBOSE mode.
+1. I had assumed without
nikita.y.vol...@mail.ru nikita.y.vol...@mail.ru wrote:
Executing concurrent transactions inserting the same value of a
unique key fails with the duplicate key error under code
23505 instead of any of transaction conflict errors with a
40*** code.
This is true, and can certainly be
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Still, I don't think this is a reasonable test design. We have
absolutely no idea what behaviors are being triggered in the other
tests, except that they are unrelated to what those tests think they
are testing.
I can of
On 2014-12-26 17:23, Kevin Grittner wrote:
Are there any objections to generating a write conflict instead of
a duplicate key error if the duplicate key was added by a
concurrent transaction? Only for transactions at isolation level
REPEATABLE READ or higher?
Is it possible to distinguish
On Thu, Dec 25, 2014 at 11:57:29AM +0530, Abhijit Menon-Sen wrote:
Hi.
Here's a proposed patch to use CPUID at startup to determine if the
SSE4.2 CRC instructions are available, to use them instead of the
slice-by-8 implementation (posted earlier).
A few notes:
1. GCC has included
Kevin Grittner kgri...@ymail.com writes:
Are there any objections to generating a write conflict instead of
a duplicate key error if the duplicate key was added by a
concurrent transaction?
Yes. This will deliver a less meaningful error code, *and* break
existing code that is expecting the
On December 26, 2014 4:50:33 PM CET, Bruce Momjian br...@momjian.us wrote:
On Thu, Dec 25, 2014 at 11:57:29AM +0530, Abhijit Menon-Sen wrote:
Hi.
Here's a proposed patch to use CPUID at startup to determine if the
SSE4.2 CRC instructions are available, to use them instead of the
slice-by-8
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Still, I don't think this is a reasonable test design. We have
absolutely no idea what behaviors are being triggered in the other
tests, except that they are unrelated to what those tests think they
are
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
I've not proven this rigorously, but it seems obvious in hindsight:
what's happening is that when the object_address test drops everything
with DROP CASCADE, other processes are sometimes just starting to execute
the event
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
I've not proven this rigorously, but it seems obvious in hindsight:
what's happening is that when the object_address test drops everything
with DROP CASCADE, other processes are sometimes just starting to
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Hm, maybe we can drop the event trigger explicitely first, then wait a
little bit, then drop the remaining objects with DROP CASCADE?
As I said, that's no fix; it just makes the
On Fri, Dec 26, 2014 at 04:52:58PM +0100, Andres Freund wrote:
On December 26, 2014 4:50:33 PM CET, Bruce Momjian br...@momjian.us wrote:
On Thu, Dec 25, 2014 at 11:57:29AM +0530, Abhijit Menon-Sen wrote:
Hi.
Here's a proposed patch to use CPUID at startup to determine if the
SSE4.2 CRC
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Hm, maybe we can drop the event trigger explicitely first, then wait a
little bit, then drop the remaining objects with DROP CASCADE?
As I said, that's no
On December 26, 2014 6:05:34 PM CET, Bruce Momjian br...@momjian.us wrote:
On Fri, Dec 26, 2014 at 04:52:58PM +0100, Andres Freund wrote:
On December 26, 2014 4:50:33 PM CET, Bruce Momjian br...@momjian.us
wrote:
On Thu, Dec 25, 2014 at 11:57:29AM +0530, Abhijit Menon-Sen wrote:
Hi.
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Are there any objections to generating a write conflict instead
of a duplicate key error if the duplicate key was added by a
concurrent transaction?
Yes. This will deliver a less meaningful error code,
That
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Yes. This will deliver a less meaningful error code,
That depends entirely on whether you care more about whether the
problem was created by a concurrent transaction or exactly how that
concurrent transaction
On December 26, 2014 6:10:51 PM CET, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Hm, maybe we can drop the event trigger explicitely first, then
wait a
Andres Freund and...@2ndquadrant.com writes:
Can't we just move the test to run without parallelism? Its quite quick, so I
don't it'd have noticeable consequences timewise.
That just leaves the door open for somebody to add more tests parallel to
it in future.
TBH, I think we could have done
Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Can't we just move the test to run without parallelism? Its quite quick, so
I don't it'd have noticeable consequences timewise.
That just leaves the door open for somebody to add more tests parallel to
it in future.
I've been
Andres Freund wrote:
This sounds like a huge project -- it's not like event triggers are the
only objects in the system where this is an issue, is it? I'm sure
there is value in fixing it, but I have enough other projects.
Can't we just move the test to run without parallelism? Its quite
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
TBH, I think we could have done without this test altogether; but if we're
going to have it, a minimum expectation is that it not be hazardous to
other tests around it.
The number of assertion failures in get_object_address
On Fri, Dec 26, 2014 at 04:52:58PM +0100, Andres Freund wrote:
Uh, what if the system is compiled on a different CPU that it
is
run on? Seems we would need a run-time CPU test.
That's the cpuid thing mentioned above.
Is this something that could potentially change the data stored on disk?
At 2014-12-26 13:11:43 -0500, br...@momjian.us wrote:
Is this something that could potentially change the data stored on
disk? Does pg_upgrade need to check for changes in this area? Is the
detection exposed by pg_controldata? Could this affect running the
data directory on a different CPU?
Tom Lane t...@sss.pgh.pa.us wrote:
Just for starters, a 40XXX error report will fail to provide the
duplicated key's value. This will be a functional regression,
Not if, as is normally the case, the transaction is retried from
the beginning on a serialization failure. Either the code will
Thanks for suggestions.
Patch updated.
Mon, 22 Dec 2014 12:07:06 +0900 от Michael Paquier michael.paqu...@gmail.com:
On Tue, Nov 4, 2014 at 6:25 AM, Alexey Vasiliev leopard...@inbox.ru wrote:
Added new patch.
Seems useful to me to be able to tune this interval of time.
I would simply
On Fri, Dec 26, 2014 at 11:52:41PM +0530, Abhijit Menon-Sen wrote:
At 2014-12-26 13:11:43 -0500, br...@momjian.us wrote:
Is this something that could potentially change the data stored on
disk? Does pg_upgrade need to check for changes in this area? Is the
detection exposed by
At 2014-12-26 13:48:40 -0500, br...@momjian.us wrote:
I assume you are only linking into Heikki's new code and will not
change the places that use the old CRC method on disk --- just
checking.
Correct. The legacy CRC computation code used by ltree etc. is
completely unaffected by both my sets
I'll repost my (OP) case, for the references to it to make more sense to
the others.
Having the following table:
CREATE TABLE song_artist (
song_id INT8 NOT NULL,
artist_id INT8 NOT NULL,
PRIMARY KEY (song_id, artist_id)
);
Even trying to protect from this with a
On Fri, Dec 26, 2014 at 7:23 AM, Kevin Grittner kgri...@ymail.com wrote:
Are there any objections to generating a write conflict instead of
a duplicate key error if the duplicate key was added by a
concurrent transaction? Only for transactions at isolation level
REPEATABLE READ or higher?
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Tom Lane wrote:
Yeah, I've been getting more annoyed by that too lately. I keep wondering
though whether there's an actual bug underneath that behavior that we're
failing to see.
I think the first thing to do is reconsider usage of
Tom Lane wrote:
The argument that autovac workers need fresher stats than anything else
seems pretty dubious to start with. Why shouldn't we simplify that down
to they use PGSTAT_STAT_INTERVAL like everybody else?
The point of wanting fresher stats than that, eons ago, was to avoid a
worker
On Fri, Dec 19, 2014 at 5:32 PM, Peter Geoghegan p...@heroku.com wrote:
Most people would list the columns, but if there is a really bizarre
constraint, with non-default opclasses, or an exclusion constraint, it's
probably been given a name that you could use.
What I find curious about the
On Fri, Dec 26, 2014 at 12:38 PM, Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Just for starters, a 40XXX error report will fail to provide the
duplicated key's value. This will be a functional regression,
Not if, as is normally the case, the transaction is
38 matches
Mail list logo
