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 :
> Trent Shipley writes:
>
> > On Friday 2007-12-14 16:22, Tom Lane wrote:
> >> Neil Conway writes:
> >> > By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
> >> > to drop (and log) rows that contain malformed data. That is, rows with
2014-12-26 11:41 GMT+01:00 Pavel Stehule :
>
>
> 2014-12-25 22:23 GMT+01:00 Alex Shulgin :
>
>> Trent Shipley writes:
>>
>> > On Friday 2007-12-14 16:22, Tom Lane wrote:
>> >> Neil Conway writes:
>> >> > By modifying COPY: COPY IGNORE ERRORS or some such would instruct
>> COPY
>> >> > to drop (a
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 cu
On 24 December 2014 at 16:04, Andreas Karlsson 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 that.
>>
>
>
>Heikki Linnakangas 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 looking that that was w
"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 inconvenient when usin
Alvaro Herrera 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 course move it to a
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 betw
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 inclu
Kevin Grittner 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 current behavior.
On December 26, 2014 4:50:33 PM CET, Bruce Momjian 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 impleme
Tom Lane wrote:
> Alvaro Herrera 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.
>
>
Alvaro Herrera 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 trigger when the DROP
Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera 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 timing harder to hit. Another
>> proces
On Fri, Dec 26, 2014 at 04:52:58PM +0100, Andres Freund wrote:
> On December 26, 2014 4:50:33 PM CET, Bruce Momjian 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 i
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Alvaro Herrera 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 timing har
On December 26, 2014 6:05:34 PM CET, Bruce Momjian 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
>wrote:
>> >On Thu, Dec 25, 2014 at 11:57:29AM +0530, Abhijit Menon-Sen wrote:
>> >> Hi.
>> >>
>> >> Here's a proposed p
Tom Lane wrote:
> Kevin Grittner 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 depends entirely on whether you c
Kevin Grittner writes:
> Tom Lane 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 created the problem.
Just for start
On December 26, 2014 6:10:51 PM CET, Alvaro Herrera
wrote:
>Tom Lane wrote:
>> Alvaro Herrera writes:
>> > Tom Lane wrote:
>> >> Alvaro Herrera writes:
>> >>> Hm, maybe we can drop the event trigger explicitely first, then
>wait a
>> >>> little bit, then drop the remaining objects with DROP CAS
Andres Freund 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 without this test alt
Tom Lane wrote:
> Andres Freund 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 long wanted to
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
Alvaro Herrera 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 without all the
> san
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
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
Tom Lane 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
check for a duplica
Thanks for suggestions.
Patch updated.
Mon, 22 Dec 2014 12:07:06 +0900 от Michael Paquier :
>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 reword the documentatio
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 pg
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 s
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 wit
On Fri, Dec 26, 2014 at 7:23 AM, 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?
This independent
Alvaro Herrera 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 PGSTAT_RETRY_DELAY
> instead
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
wor
On Fri, Dec 19, 2014 at 5:32 PM, Peter Geoghegan 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 opclass th
On Fri, Dec 26, 2014 at 12:38 PM, Kevin Grittner wrote:
> Tom Lane 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
38 matches
Mail list logo
