Re: [HACKERS] Discussion on missing optimizations

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

[HACKERS] [sqlsmith] Failed assertion in adjust_appendrel_attrs_mutator

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

Re: [HACKERS] parallel worker (PID ) exited with exit code 1

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

Re: [HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

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.

Re: [HACKERS] [sqlsmith] crash in RestoreLibraryState during low-memory testing

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 ] |

[HACKERS] [sqlsmith] crash in RestoreLibraryState during low-memory testing

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

[HACKERS] [sqlsmith] stuck spinlock in pg_stat_get_wal_receiver after OOM

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

Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling

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:

Re: [HACKERS] Server crash (FailedAssertion) due to catcache refcount mis-handling

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

Re: [HACKERS] [sqlsmith] Planner crash on foreign table join

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

[HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...

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

[HACKERS] [sqlsmith] Planner crash on foreign table join

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

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] [sqlsmith] Unpinning error in parallel worker

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

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

[HACKERS] [sqlsmith] Unpinning error in parallel worker

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 |

[HACKERS] [sqlsmith] Failed assertion in _hash_kill_items/MarkBufferDirtyHint

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

Re: [HACKERS] Improving RLS planning

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:

Re: [HACKERS] [sqlsmith] Short reads in hash indexes

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

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

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

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

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

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Thomas Munro writes: > On Wed, Dec 28, 2016 at 11:38 AM, Andreas Seltenreich > <seltenre...@gmx.de> wrote: >> Thomas Munro writes: >> >>> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro >>> <thomas.mu...@enterprisedb.com> wrote: >>>> On

Re: [HACKERS] [sqlsmith] Crash reading pg_stat_activity

Thomas Munro writes: > On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich <seltenre...@gmx.de> >> wrote: >>> testing master as of fe591f8bf6 produced a crash

[HACKERS] [sqlsmith] Crash reading pg_stat_activity

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

Re: [HACKERS] [sqlsmith] Short reads in hash indexes

Andreas Seltenreich writes: > Amit Kapila writes: > >> On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich <seltenre...@gmx.de> >> wrote: >>> Amit Kapila writes: >>> >>>> [2. text/x-diff; fix_hash_bucketsplit_sqlsmith_v1.patch] >>

[HACKERS] [sqlsmith] Crash in tsquery_rewrite/QTNBinary

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,

Short reads in hash indexes (was: [HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts)

Amit Kapila writes: > On Sat, Dec 3, 2016 at 3:44 PM, Andreas Seltenreich <seltenre...@gmx.de> > 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

[HACKERS] [sqlsmith] Crash in gather_readnext

ostmaster.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 be80954688c406122b560161192cc1d2e64e3757 Mon Sep 17 00:00:00 2001 From: Andreas Seltenreich <se

Re: [HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts

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"

[HACKERS] [sqlsmith] Failed assertion in _hash_splitbucket_guts

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

[HACKERS] [sqlsmith] Failed assertion in TS_phrase_execute

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',

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

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

Re: [HACKERS] [sqlsmith] Parallel worker crash on seqscan

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

[HACKERS] [sqlsmith] Failed assertion in parallel worker in ExecInitSubPlan

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 ->

[HACKERS] [sqlsmith] Parallel worker crash on seqscan

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

Re: [HACKERS] [sqlsmith] Crash on GUC serialization

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

[HACKERS] [sqlsmith] Crash on GUC serialization

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;

[HACKERS] [sqlsmith] Missing CHECK_FOR_INTERRUPTS in tsquery_rewrite

tch adds a CHECK_FOR_INTERRUPTS to make it cancellable. regards, Andreas >From d9910a96c9bd73c16e29ecaa0577945d5e1c091c Mon Sep 17 00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> Date: Sun, 30 Oct 2016 03:25:55 +0100 Subject: [PATCH] Add CHECK_FOR_INTERRUPTS in tsquery_rewrite loop. T

Re: [HACKERS] [sqlsmith] Infinite recursion in bitshift

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

[HACKERS] [sqlsmith] Infinite recursion in bitshift

00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> 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 s

[HACKERS] [sqlsmith] Failed assertion in numeric aggregate

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

[HACKERS] [sqlsmith] Crash in pg_get_viewdef_name_ext()

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

Re: [HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

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

[HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

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,

[HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

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

[HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

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

Re: [HACKERS] GiST index build versus NaN coordinates

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

Re: [HACKERS] Improving executor performance

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 modern IR than LLVM

Re: [HACKERS] Improving executor performance

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

Re: [HACKERS] Improving executor performance

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.

Re: [HACKERS] Issue in pg_catalog.pg_indexes view definition

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

Re: [HACKERS] GiST index build versus NaN coordinates

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

[HACKERS] [sqlsmith] ERROR: plan should not reference subplan's variable

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';

Re: [HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

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)) + >>

[HACKERS] [sqlsmith] crashes in RestoreSnapshot on hot standby

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.

[HACKERS] [sqlsmith] OOM crash in plpgsql_extra_checks_check_hook

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,

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

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

[HACKERS] Should pg_export_snapshot() and currtid() be tagged parallel-unsafe?

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

Re: [HACKERS] [COMMITTERS] pgsql: Don't generate parallel paths for rels with parallel-restricted

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

[HACKERS] [sqlsmith] Failed assertion in postgres_fdw/deparse.c:1116

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

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

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

Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist

Tom Lane writes: > Andreas Seltenreich <seltenre...@gmx.de> 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 cau

Re: [HACKERS] ORDER/GROUP BY expression not found in targetlist

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:

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

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

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

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

Re: [HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

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

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

Amit Kapila writes: > On Mon, May 23, 2016 at 4:48 PM, Andreas Seltenreich <seltenre...@gmx.de> > 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 control

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

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?

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

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

Re: [HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

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

Re: [HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

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

[HACKERS] [sqlsmith] PANIC: failed to add BRIN tuple

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.

[HACKERS] [sqlsmith] Failed assertions on parallel worker shutdown

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

[HACKERS] Just-in-time compiling things (was: asynchronous and vectorized execution)

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

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Alvaro Herrera writes: > Robert Haas wrote: >> On Thu, May 5, 2016 at 4:11 PM, Andreas Seltenreich <seltenre...@gmx.de> >> wrote: >> > I don't see these crashes anymore in c1543a8. By the amount of fuzzing >> > done it should have happened a dozen time

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

> 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

[HACKERS] [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)

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.

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

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

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

Amit Kapila writes: > On Sat, Apr 30, 2016 at 5:58 AM, Andreas Seltenreich <seltenre...@gmx.de> > 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

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

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

Re: [HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

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

[HACKERS] [sqlsmith] Failed assertion in BecomeLockGroupLeader

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

[HACKERS] [sqlsmith] Crash in apply_projection_to_path

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

[HACKERS] [PATCH] Improve spinlock inline assembly for x86.

Sep 17 00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> 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

[HACKERS] [PATCH] Add STRICT to some regression test C functions.

this patch in? Thanks, Andreas >From 2711471d48c2e58809c2f4617d36352c5903bbd9 Mon Sep 17 00:00:00 2001 From: Andreas Seltenreich <seltenre...@gmx.de> 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 N

Re: [HACKERS] pg_upgrade in 9.5 broken for adminpack

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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

Tom Lane writes: > Andreas Seltenreich <seltenre...@gmx.de> writes: >> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 424) >> TRAP: FailedAssertion([...], File: "spgtextproc.c", Line: 564) > > Can you show us the definition of th

[HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

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

Re: [HACKERS] [sqlsmith] Failing assertions in spgtextproc.c

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,

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

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 bu

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

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

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Greg Stark writes: > On Sat, Dec 12, 2015 at 8:30 PM, Andreas Seltenreich <seltenre...@gmx.de> > 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 i

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

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

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Peter Geoghegan writes: > On Sun, Dec 6, 2015 at 9:52 AM, Andreas Seltenreich <seltenre...@gmx.de> > 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/IGNO

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

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

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

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

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

I wrote: > Tom Lane writes: >> Andreas Seltenreich <seltenre...@gmx.de> 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. >> >

Re: [HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

Tom Lane writes: > Andreas Seltenreich <seltenre...@gmx.de> 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.

[HACKERS] [sqlsmith] Failed to generate plan on lateral subqueries

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

Re: [HACKERS] 9.3.9 and pg_multixact corruption

[ adding Bjorn Munch to Cc ] Jim Nasby writes: > On 9/20/15 9:23 AM, Christoph Berg wrote: >> a short update here: the customer updated the compiler to a newer >> version, is now compiling using -O2 instead of -O3, and the code >> generated now looks sane, so this turned out to be a compiler

  1   2   >