Alvaro Herrera writes:
> Andres Freund wrote:
>> Unfortunately it won't help in this specific case (no support for UNION,
>> just UNION ALL), but I thought it might be interesting to reference
>> https://medium.com/@uwdb/introducing-cosette-527898504bd6
>> here.
>
> Interesting. I thought about a
Hi,
testing master as of 7c981590c2, sqlsmith just triggered the following
assertion:
TRAP: FailedAssertion("!(!const Node*)(node))->type) == T_SubLink))", File:
"prepunion.c", Line: 2231)
I can reproduce it on a vanilla regression database with the following
query:
--8<---cut
Michael Paquier writes:
> On Fri, Oct 6, 2017 at 9:19 PM, tushar wrote:
>> ERROR: recovery is not in progress
>
> Perhaps there is a way to blacklist some functions depending on the
> server context. This question may be better asked directly where the
> project is maintained then: https://githu
Michael Paquier writes:
> I am attaching a patch that addresses the bugs for the spin lock sections.
> [2. text/x-diff; walreceiver-spin-calls.patch]
I haven't seen a spinlock PANIC since testing with the patch applied.
They occured five times with the same amount of testing done earlier.
regard
Tom Lane writes:
> Presumably somebody could dig into the libc source code and prove or
> disprove this, though it would sure help to know exactly what platform
> and version Andreas is testing on.
This is the code in glibc-2.24 around the crash site:
,[ glibc-2.24/elf/dl-load.c:442 ]
|
Hi,
doing low-memory testing with REL_10_STABLE at 1f19550a87 also produced
a couple of parallel worker core dumps with the backtrace below.
Although most of the backtrace is inside the dynamic linker, it looks
like it was passed a pointer to gone-away shared memory.
regards,
Andreas
Core was ge
Hi,
low-memory testing with REL_10_STABLE at 1f19550a87 produced the
following PANIC:
stuck spinlock detected at pg_stat_get_wal_receiver, walreceiver.c:1397
I was about to wrap the pstrdup()s with a PG_TRY block, but I can't find
a spinlock being released in a PG_CATCH block anywhere, so ma
Tom Lane writes:
> I wonder if Andreas would be interested in trying the randomly-timed-
> SIGTERM thing with sqlsmith.
So far, most of the core dumps generated are Jeevan's assertion failing
with backtraces through SearchCatCacheList. The rest is failing this
assertion:
TRAP: FailedAssertio
Tom Lane writes:
> I wonder if Andreas would be interested in trying the randomly-timed-
> SIGTERM thing with sqlsmith.
Will do. Won't miss this chance to try out discostu's extension
pg_rage_terminator[1] :-)
regards,
Andreas
Footnotes:
[1] https://github.com/disco-stu/pg_rage_terminator
Tom Lane writes:
> I made the attached quick-hack patch, and found that check-world
> passes just fine with it. That's not complete proof that we have
> no other bugs of this ilk, but it definitely supports the idea
> that we don't really need to add the overhead. I'll just put this
> in the arc
Hi,
I see the above ERROR logged a lot when testing master at eef8c0069e
with a postgres_fdw around. Below is a recipe to reproduce it on top of
the regression DB.
regards,
Andreas
create extension postgres_fdw;
create server myself foreign data wrapper postgres_fdw;
create schema fdw_postgres;
Hi,
testing master at f0e44021df with a loopback postgres_fdw installed, I
see lots of crashes on queries joining foreign tables with various
expressions. Below is a reduced recipe for the regression database and
a backtrace.
regards,
Andreas
--8<---cut here---start-
Andreas Seltenreich writes:
>>> TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*)
>>> (&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397)
> I got about one TRAP per hour when testing on 20 nodes with one postgres
> and 5 s
Thomas Munro writes:
> Based on feedback on another thread about how to make reviewers' and
> committers' jobs easier, here is a format-patch version with a short
> description as raw material for a commit message, in case that is
> helpful.
+1
It's quite convenient. Otherwise I have to be crea
Ashutosh Sharma writes:
>> TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*)
>> (&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397)
> Thanks for reporting this problem. Could you please let me know on for
> how long did you run sqlsmith to get this crash.
I got about one TRAP per hour w
Hi,
today's testing with master as of d253b0f6e3 yielded two clusters that
stopped processing queries. Symptoms:
regression=> select application_name, state, wait_event, wait_event_type,
count(1), min(pid)
from pg_stat_activity group by 1,2,3,4;
application_name | state |
Hi,
testing with master as of cf366e97ff, sqlsmith occasionally triggers the
following assertion:
TRAP: FailedAssertion("!(LWLockHeldByMe(((LWLock*)
(&(bufHdr)->content_lock", File: "bufmgr.c", Line: 3397)
Backtraces always look like the one below. It is reproducible on a
cluster once it h
Tom Lane writes:
> Thanks for reviewing --- I'll do something with that test case and
> push it.
sqlsmith doesn't seem to like 215b43cdc:
select 1 from information_schema.usage_privileges
where information_schema._pg_keysequal(
(select null::smallint[]),
'{16,25,23}');
-- TRAP: FailedAsse
Amit Kapila writes:
> Can you please try with the patch posted on hash index thread [1] to
> see if you can reproduce any of these problems?
>
> [1] -
> https://www.postgresql.org/message-id/CAA4eK1Kf6tOY0oVz_SEdngiNFkeXrA3xUSDPPORQvsWVPdKqnA%40mail.gmail.com
I'm no longer seeing the failed asse
Thomas Munro writes:
> [2. text/x-diff; fix-dsa-tranche-registration.patch]
Fuzzing with the patch applied hasn't triggered the crash so far. It
did happen 5 times with the same amount of fuzzing before patching.
regards,
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Andreas Seltenreich writes:
> Thomas Munro writes:
>
>> It is safe, as long as the segment remains mapped. Each backend that
>> attaches calls LWLockRegisterTranche giving it the address of the name
>> in its virtual address space.
>
> Hmok, I was under the impressi
Thomas Munro writes:
> On Wed, Dec 28, 2016 at 11:38 AM, Andreas Seltenreich
> wrote:
>> Thomas Munro writes:
>>
>>> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro
>>> wrote:
>>>> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
>>&g
Thomas Munro writes:
> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro
> wrote:
>> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
>> wrote:
>>> testing master as of fe591f8bf6 produced a crash reading
>>> pg_stat_activity (backtrace below). Diggi
Hi,
testing master as of fe591f8bf6 produced a crash reading
pg_stat_activity (backtrace below). Digging around with with gdb
revealed that pgstat_get_wait_event() returned an invalid pointer for a
classId PG_WAIT_LWLOCK.
I think the culprit is dsa.c passing a pointer to memory that goes away
on
Andreas Seltenreich writes:
> Amit Kapila writes:
>
>> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich
>> wrote:
>>> Amit Kapila writes:
>>>
>>>> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch]
>>> Ok, I'll do testi
Hi,
the following query crashes master as of 4212cb7.
select ts_rewrite(
tsquery_phrase(
tsquery $$'sanct' & 'peter'$$,
tsquery $$'5' <-> '6'$$,
42),
tsquery $$'5' <-> '6'$$,
plainto_tsquery('I') );
Backtrace below.
regards,
A
Amit Kapila writes:
> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich
> wrote:
>> Amit Kapila writes:
>>
>>> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch]
>> Ok, I'll do testing with the patch applied.
Good news: the assertion hasn't f
rt=0x23d1ad0) at postmaster.c:3945
#32 ServerLoop () at postmaster.c:1701
#33 0x00698ed9 in PostmasterMain (argc=argc@entry=4,
argv=argv@entry=0x23a05c0) at postmaster.c:1309
#34 0x0046ebbd in main (argc=4, argv=0x23a05c0) at main.c:228
>From be80954688c406122b560161192cc1d2e64
Amit Kapila writes:
> How should I connect to this database? If I use the user fdw
> mentioned in pg_hba.conf (changed authentication method to trust in
> pg_hba.conf), it says the user doesn't exist. Can you create a user
> in the database which I can use?
There is also a superuser "postgres"
Hi,
the new hash index code on 11003eb failed an assertion yesterday:
TRAP: FailedAssertion("!(bucket == obucket)", File: "hashpage.c", Line:
1037)
Statement was
update public.hash_i4_heap set seqno = public.hash_i4_heap.random;
It can be reproduced with the data directory (Debian str
Hi,
the query below triggers an assertion in TS_phrase_execute. Testing was
done on master at dbdfd11.
regards,
Andreas
-- TRAP: FailedAssertion("!(curitem->qoperator.oper == 4)", File:
"tsvector_op.c", Line: 1432)
select 'moscow' @@
ts_rewrite('moscow', 'moscow',
ts_rewrite(
Hi,
just caught another InitPlan below Gather with the recent patches in
(master as of 4cc6a3f). Recipe below.
regards,
andreas
set max_parallel_workers_per_gather = 2;
set min_parallel_relation_size = 0;
set parallel_setup_cost = 0;
set parallel_tuple_cost = 0;
explain select 1 from
public
Hi,
Ashutosh Sharma writes:
>> the following query appears to reliably crash parallel workers on master
>> as of 0832f2d.
> As suggested, I have tried to reproduce this issue on *0832f2d* commit but
> could not reproduce it.
as Tom pointed out earlier, I had secretly set parallel_setup_cost and
Hi,
the query below triggers a parallel worker assertion for me when run on
the regression database of master as of 0832f2d. The plan sports a
couple of InitPlan nodes below Gather.
regards,
Andreas
Gather (cost=1.64..84.29 rows=128 width=4)
Workers Planned: 1
Single Copy: true
-> L
Hi,
the following query appears to reliably crash parallel workers on master
as of 0832f2d.
--8<---cut here---start->8---
set max_parallel_workers_per_gather to 2;
set force_parallel_mode to 1;
select subq.context from pg_settings,
lateral (select context
Michael Paquier writes:
> [2. text/plain; fix-guc-string-eval.patch]
I'm afraid taking care of the length computation is not sufficient.
ISTM like it'll still try to serialize the NULL pointer later on in
serialize_variable:
,[ guc.c:9108 ]
| case PGC_STRING:
| {
| struct config_st
Hi,
sqlsmith just made a GUC that tricks the serialization code into
dereferencing a nullpointer. Here's a recipe:
--8<---cut here---start->8---
set min_parallel_relation_size to 0;
set max_parallel_workers_per_gather to 2;
set force_parallel_mode to on;
begin
foo');
The attached patch adds a CHECK_FOR_INTERRUPTS to make it cancellable.
regards,
Andreas
>From d9910a96c9bd73c16e29ecaa0577945d5e1c091c Mon Sep 17 00:00:00 2001
From: Andreas Seltenreich
Date: Sun, 30 Oct 2016 03:25:55 +0100
Subject: [PATCH] Add CHECK_FOR_INTERRUPTS in tsquery_rewrite lo
Tom Lane writes:
>> This is due to an integer overflow in bitshiftright()/bitshiftleft()
>> leading to them recursively calling each other. Patch attached.
>
> Seems sane, though I wonder if it'd be better to use -INT_MAX rather
> than -VARBITMAXLEN.
I am undecided between those two. -INT_MAX m
Mon Sep 17 00:00:00 2001
From: Andreas Seltenreich
Date: Fri, 14 Oct 2016 20:52:52 +0200
Subject: [PATCH] Fix possible infinite recursion on bitshift.
bitshiftright() and bitshiftleft() would recursively call each other
infinitely when the user passed a MIN_INT for the shift amount due to
an inte
Hi,
updating master from be7f7ee..39b691f, the following assertion is
triggered frequently by sqlsmith:
TRAP: BadArgument("!(((context) != ((void *)0) && (const
Node*)((context)))->type) == T_AllocSetContext", File: "mcxt.c", Line: 1010)
Digging in the coredumps, it looks like set_var_f
Hi,
sqlsmith just triggered a crash in pg_get_viewdef_name_ext(). Looks
like commit 976b24fb4 failed to update this caller of
pg_get_viewdef_worker(). Backtrace below. Patch attached.
regards,
Andreas
Program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 strlen () at ../sys
Michael Paquier writes:
> Andreas, with the patch attached is the assertion still triggered?
> [2. text/x-diff; base-backup-crash-v2.patch]
I didn't observe the crashes since applying this patch. There should
have been about five by the amount of fuzzing done.
regards
Andreas
--
Sent via pgs
Hi,
since updating master from c93d873..fc509cd, I see crashes in
GetOldestSnapshot() on update/delete returning statements.
I reduced the triggering statements down to this:
update clstr_tst set d = d returning d;
Backtrace below.
regards,
Andreas
Program received signal SIGSEGV, Segment
Hi,
the following statement triggers an assertion in tsearch:
select ts_delete(array_to_tsvector('{smith,smith,smith}'::text[]),
'{smith,smith}'::text[]);
-- TRAP: FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line:
511)
regards,
Andreas
--
Sent via pgsql-hackers mailing
Hi,
testing with sqlsmith shows that the following assertion doesn't hold:
FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line:
10200)
The triggering statements always contain a call to pg_start_backup with
the third argument 'true', i.e. it's trying to start an exlus
I wrote:
> Sounds like some fuzz testing with nan/infinity is in order.
related fallout: close_ps returns a NULL pointer with NaNs around:
select close_ps('(nan,nan)', '(nan,nan),(nan,nan)');
-- TRAP: FailedAssertion("!(result != ((void *)0))", File: "geo_ops.c", Line:
2860)
regards,
Andreas
Andres Freund writes:
> On 2016-07-14 23:03:10 +0200, Andreas Seltenreich wrote:
>> That's the plan, yes. I'm sorry there's no publishable code yet on the
>> the postgres side of things. Using libFirm[1], the plan is to.
>
> Why libfirm?
- It has a more mode
Andres Freund writes:
> The problem is that the previous form has a lot of ad-hoc analysis
> strewn in. The interesting part is getting rid of all that. That's what
> the new ExecInitExpr2() does. The target form can be both evaluated more
> efficiently in the dispatch manner in the patch, and qui
Andres Freund writes:
> Having expression evaluation and slot deforming as a series of simple
> sequential steps, instead of complex recursive calls, would also make it
> fairly straightforward to optionally just-in-time compile those.
I don't think that JIT becomes easier by this change. Constr
Tom Lane writes:
> Dilip Kumar writes:
>> So I think changing the view definition and calling this function on
>> indexrelid will remove the error. So I think
>> correct fix is to change view definition, as I proposed in above patch.
[...]
> We've dealt with similar issues in places like pg_relat
Tom Lane writes:
> More generally, this example makes me fearful that NaN coordinates in
> geometric values are likely to cause all sorts of issues. It's too late
> to disallow them, probably, but I wonder how can we identify other bugs
> of this ilk.
Sounds like some fuzz testing with nan/infin
Updating master from f8c5855..1bdae16, sqlsmith triggers "failed to
generate plan" errors again. Below is the smallest query logged so far.
regards,
Andreas
-- ERROR: plan should not reference subplan's variable
set force_parallel_mode = 'on';
set max_parallel_workers_per_gather = '1';
explain
Amit Kapila writes:
> On Fri, Jul 1, 2016 at 9:38 AM, Thomas Munro
> wrote:
>> Or maybe just like this?
>>
>> - snapshot->subxip = snapshot->xip + serialized_snapshot->xcnt;
>> + snapshot->subxip = ((TransactionId *) (snapshot + 1)) +
>> + seriali
Running sqlsmith on a streaming slave (master as of f8c5855) is
inconspicuous as long as the master is idle. As soon as I start it on
the master as well, the standby frequently crashes in RestoreSnapshot.
It doesn't seem to be specific to the queries, as they don't trigger a
crash when re-run.
Ba
Just had a parallel worker of a memory-starved instance of sqlsmith
crash. plpgsql_extra_checks_check_hook forgot to check the result of
its malloc call here:
Core was generated by `postgres: bgworker: parallel worker for PID 5905
'.
Program terminated with signal SIGSEGV, Seg
Amit Kapila writes:
> Right, so I have moved "Failed assertion in parallel worker
> (ExecInitSubPlan)" item to CLOSE_WAIT state as I don't think there is any
> known pending issue in that item. I have moved it to CLOSE_WAIT state
> because we have derived our queries to reproduce the problem base
Digging through the sqlsmith logging db, I noticed the following errors:
ERROR: cannot update SecondarySnapshot during a parallel operation
ERROR: cannot assign XIDs during a parallel operation
Queries raising the first one always contain calls to currtid() or
currtid2(). Queries raisi
Amit Kapila writes:
> I have moved it to CLOSE_WAIT state because we have derived our
> queries to reproduce the problem based on original report[1]. If next
> run of sqlsmith doesn't show any problem in this context then we will
> move it to resolved.
I don't have access to my testing horse pow
Creating some foreign tables via postgres_fdw in the regression db of
master as of de33af8, sqlsmith triggers the following assertion:
TRAP: FailedAssertion("!(const Node*)(var))->type) == T_Var))", File:
"deparse.c", Line: 1116)
gdb says var is holding a T_PlaceHolderVar instead. In a
Alvaro Herrera writes:
> If you can re-run sqlsmith and see if you can find different bugs, I'd
> appreciate it.
[...]
> [2. text/x-diff; brincrash-2.patch]
BRIN is inconspicuous since applying this patch. All coredumps I see
now are either due to the parallel worker shutdown issue or acl.c's
te
Tom Lane writes:
> Andreas Seltenreich writes:
>> Peter Geoghegan writes:
>>> It's surprising that SQL Smith didn't catch something with such simple
>>> steps to reproduce.
>
>> I removed distinct relatively early because it causes a large part
Peter Geoghegan writes:
> On Wed, May 25, 2016 at 7:12 PM, Andres Freund wrote:
>>
>> =# CREATE TABLE twocol(col01 int, col02 int);
>> =# SELECT DISTINCT col01, col02, col01 FROM twocol ;
>> ERROR: XX000: ORDER/GROUP BY expression not found in targetlist
>> LOCATION: get_sortgroupref_tle, tlist
I wrote:
> Re-fuzzing now with your patch applied.
This so far yielded three BRIN core dumps on different machines with the
same backtraces. Crash recovery fails in these cases.
I've put the data directory here (before recovery):
http://ansel.ydns.eu/~andreas/brincrash2-spidew.tar.xz (9.1M
I wrote:
> Alvaro Herrera writes:
>> How long does it take for you to reproduce this panic in the unpatched
>> code?
>
> I could probably speed it up by creating lots of additional BRIN indexes
> in the regression database, and by compiling a sqlsmith that generates
> update statements only.
This
Alvaro Herrera writes:
> How long does it take for you to reproduce this panic in the unpatched
> code?
Very long, I'm afraid. I only observed it once, and according to the
logging database, about 4e9 random queries were generated since testing
with 9.5 code.
I could probably speed it up by cre
Amit Kapila writes:
> On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich
> wrote:
>> plan6 corresponds to this query:
>>
> Are you sure that the core dumps you are seeing are due to plan6?
Each of the plans sent was harvested from a controlling process when the
above as
Amit Kapila writes:
> Earlier problems were due to the reason that some unsafe/restricted
> expressions were pushed below Gather node as part of target list whereas in
> the plan6, it seems some unsafe node is pushed below Gather node. It will
> be helpful if you can share the offending query?
pl
I wrote:
>> There's another class of parallel worker core dumps when testing master
>> with sqlsmith. In these cases, the following assertion fails for all
>> workers simulataneously:
>>
>> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File:
>> "shm_mq.c", Line: 386)
>
> I no longe
I wrote:
> There's another class of parallel worker core dumps when testing master
> with sqlsmith. In these cases, the following assertion fails for all
> workers simulataneously:
>
> TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File:
> "shm_mq.c", Line: 386)
I no longer observ
Amit Kapila writes:
> avoid_restricted_clause_below_gather_v1.patch
> prohibit_parallel_clause_below_rel_v1.patch
I didn't observe any parallel worker related coredumps since applying
these. The same amount of testing done before applying them yielded
about a dozend.
Dilip Kumar writes:
> So n
There was one instance of this PANIC when testing with the regression db
of master at 50e5315.
,
| WARNING: specified item offset is too large
| PANIC: failed to add BRIN tuple
| server closed the connection unexpectedly
`
It is reproducible with the query below on this instance only.
There's another class of parallel worker core dumps when testing master
with sqlsmith. In these cases, the following assertion fails for all
workers simulataneously:
TRAP: FailedAssertion("!(mqh->mqh_partial_bytes <= nbytes)", File: "shm_mq.c",
Line: 386)
The backtraces of the controlling proce
Konstantin Knizhnik writes:
> Latest information from ISP RAS guys: them have made good progress
> since February: them have rewritten most of methods of Scan, Aggregate
> and Join to LLVM API.
Is their work available somewhere? I'm experimenting in that area as
well, although I'm using libFirm
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich
>> wrote:
>> > I don't see these crashes anymore in c1543a8. By the amount of fuzzing
>> > done it should have happened a dozen times, so it's highly
> Amit Kapila writes:
>> Sounds good. So can we assume that you will try to get us the new report
>> with more information?
I don't see these crashes anymore in c1543a8. By the amount of fuzzing
done it should have happened a dozen times, so it's highly likely
something in 23b09e15..c1543a8 fixe
Hi,
when fuzz testing master as of c1543a8, parallel workers trigger the
following assertion in ExecInitSubPlan every couple hours.
TRAP: FailedAssertion("!(list != ((List *) ((void *)0)))", File: "list.c",
Line: 390)
Sample backtraces of a worker and leader below, plan of leader attached.
Amit Kapila writes:
> On Fri, Apr 29, 2016 at 7:15 PM, Tom Lane wrote:
>> but it might be worth copying over the full query from the parent
>> side.
>
> That would amount to couple of extra cycles considering we need to do it
> for each worker, but OTOH it might be a useful debugging information
Amit Kapila writes:
> On Sat, Apr 30, 2016 at 5:58 AM, Andreas Seltenreich
> wrote:
>> This sounds like it should work to capture more context when the
>> Assertion fails the next time.
>
> Sounds good. So can we assume that you will try to get us the new report
>
Simon Riggs writes:
> It's good that the input is fuzzed, but there needs to be a way to re-run
> identical fuzzing or a way to backtrack to find what broke. Not much point
> finding bugs we can't identify later.
sqlsmith is deterministic and allows re-generating a sequence of random
queries with
Alvaro Herrera writes:
> Amit Kapila wrote:
>> It will be helpful if you can find the offending query or plan
>> corresponding to it?
>
> So I suppose the PID of the process starting the workers should be in
> the stack somewhere.
Ja, it's right on the top, but long gone by now…
> With that one s
Hi,
tonight's sqlsmith run yielded another core dump:
TRAP: FailedAssertion("!(MyProc->lockGroupLeader == ((void *)0))", File:
"proc.c", Line: 1787)
I couldn't identifiy a query for it though: debug_query_string is empty.
Additionally, the offending query was not reported in the error context
a
Hi,
the following query against the regression database crashes master as of
23b09e15.
select 1 from depth0 inner join depth1 on (depth0.c = depth1.c)
where depth0.c @@ depth1.c limit 1;
regards,
Andreas
Program terminated with signal SIGSEGV, Segmentation fault.
#0 create_projection_
5 Mon Sep 17 00:00:00 2001
From: Andreas Seltenreich
Date: Sun, 17 Jan 2016 11:51:53 +0100
Subject: [PATCH] Improve spinlock inline assembly for x86.
Remove the LOCK prefix from the XCHG instruction. Locking is implicit
with XCHG and the prefix wastes a byte. Also remove the "cc" regis
patch in?
Thanks,
Andreas
>From 2711471d48c2e58809c2f4617d36352c5903bbd9 Mon Sep 17 00:00:00 2001
From: Andreas Seltenreich
Date: Sun, 3 Jan 2016 19:05:06 +0100
Subject: [PATCH] Add STRICT to some regression test C functions.
These functions readily crash when passing NULL input values.
Bruce Momjian writes:
> On Thu, Apr 16, 2015 at 11:29:07PM -0700, Jeff Janes wrote:
>> Of course after sending that it became obvious. The C function is not
>> getting
>> called because the SQL function is marked as being strict, yet is called with
>> NULL arguments.
>>
>> Trivial patch attache
Tom Lane writes:
> Andreas Seltenreich writes:
>> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
>> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
>
> Can you show us the definition of the index that's causing this,
&g
Peter Geoghegan writes:
> Can you do this?:
>
> (gdb) p debug_query_string
output below. Since sqlsmith ist no longer restricted to read-only
statements, the chances for reproduction are low :-/.
select
pg_catalog.pg_stat_get_buf_written_backend() as c0,
subq_1.c0 as c1,
subq_1.c0 as c2,
I do see two assertions in spgtextproc.c fail on occasion when testing
with sqlsmith:
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424)
TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564)
I can't reproduce it reliably but looking at the coredumps, the failing
part of the e
David Fetter writes:
> On Mon, Dec 14, 2015 at 03:06:18PM +0900, Michael Paquier wrote:
>> On Sun, Dec 13, 2015 at 10:14 AM, Andreas Seltenreich wrote:
>> > https://github.com/anse1/sqlsmith
>>
>> I am in awe regarding this stuff, which has caught many bugs
&g
Greg Stark writes:
> On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich
> wrote:
> When you hit the timeout is this implemented in your fuzzer or using
> statement_timeout? If the former, can you add a statement_timeout of
> just short of the timeout in the fuzzer and find
Greg Stark writes:
> There may be other errors that would be surprising for Tom or Robert. What
> I did with the string argument fuzzer was printed counts for each sqlstate
> for the errors and watched for errors that only occurred occasionally or
> didn't make sense to me.
>
> Also, do you have
Peter Geoghegan writes:
> On Sun, Dec 6, 2015 at 9:52 AM, Andreas Seltenreich
> wrote:
>> I've added new grammar rules to sqlsmith and improved some older ones.
>
> Could you possibly teach sqlsmith about INSERT ... ON CONFLICT DO
> UPDATE/IGNORE? I think that
Tom Lane writes:
> [2. transitive-lateral-fixes-2.patch ]
> [2. remove-lateraljoininfo-2.patch ]
They seem to have fixed the issue for good now. No errors have been
logged for 2e8 queries since applying the first patch. (The second one
was applied later and didn't get as much exposure.) I guess
Tom Lane writes:
> Merlin Moncure writes:
>> Aside from the functional issues, could your changes result in
>> performance regressions?
[...]
> It's a little bit harder to gauge the impact on planner speed. The
> transitive closure calculation could be expensive in a query with many
> lateral re
Tom Lane writes:
> [2. transitive-lateral-fixes-1.patch]
I was about to write that sqlsmith likes the patch, but after more than
10^8 ok queries the attached ones were generated.
regards,
Andreas
post-patch-errors.sql
Description: application/sql
--
Sent via pgsql-hackers mailing list (pgsq
I wrote:
> Tom Lane writes:
>> Andreas Seltenreich writes:
>>> I've added new grammar rules to sqlsmith and improved some older ones.
>>> This was rewarded with a return of "failed to generate plan" errors.
>>
>> I believe I've dealt wi
Tom Lane writes:
> Andreas Seltenreich writes:
>> I've added new grammar rules to sqlsmith and improved some older ones.
>> This was rewarded with a return of "failed to generate plan" errors.
>
> I believe I've dealt with these cases now. Thanks fo
Hi,
I've added new grammar rules to sqlsmith and improved some older ones.
This was rewarded with a return of "failed to generate plan" errors.
The failing queries all contain a lateral subquery. The shortest of the
failing queries are below. They were run against the regression db of
master as
Alvaro Herrera writes:
> Jim Nasby wrote:
>> Do we officially not support anything > -O2? If so it'd be nice if configure
>> threw at least a warning (if not an error that you had to explicitly
>> over-ride).
>
> Keep in mind this is Sun OS C -- not one of the most popular compilers
> in the world
1 - 100 of 131 matches
Mail list logo
